Re: isl 0.26 C++17 issues when bootstrapping with GCC
This > On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: > > On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >> I suppose for bootstrapping we could disable ISL during stage1 since >> it enables an optional feature only. Other than that GCC only >> requires a C++11 compiler for building, so ISL breaks that constraint >> with requiring C++17. > > Note that it doesn't *require* it per sé; the tests that try it are > compiled if C++17 support was detected at all. The headers seem to just > have optional header-only `std::any`-using APIs if C++17 is around. > `isl` supporting a flag to disable the tests would also work, but that > doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at > some point in the future. Perhaps, in the short-term (i.e. before it requires C++ > 11) we can solve this by ensuring that we pass -std=c++11 to the configure stages as well as to the build. ISTM that configure is finding C++17-capability (because we do not, I think, force C++11 for the configure) and then the build takes it away by forcing -std=c++11. [ will try this out ] > In light of that, I feel that skipping it for bootstrap is probably the > right solution here. Alas, my skill with autotools is closer to the > caveman-with-club level rather than that of a surgeon. I am not sure we have an easy way to exclude a host module from stage1 only (but ICBW). Iain > > --Ben
Re: isl 0.26 C++17 issues when bootstrapping with GCC
> On 13 May 2024, at 16:05, Iain Sandoe via Gcc wrote: >> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: >> >> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>> I suppose for bootstrapping we could disable ISL during stage1 since >>> it enables an optional feature only. Other than that GCC only >>> requires a C++11 compiler for building, so ISL breaks that constraint >>> with requiring C++17. >> >> Note that it doesn't *require* it per sé; the tests that try it are >> compiled if C++17 support was detected at all. The headers seem to just >> have optional header-only `std::any`-using APIs if C++17 is around. >> `isl` supporting a flag to disable the tests would also work, but that >> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at >> some point in the future. > > Perhaps, in the short-term (i.e. before it requires C++ > 11) we can > solve this by ensuring that we pass -std=c++11 to the configure stages > as well as to the build. ISTM that configure is finding C++17-capability > (because we do not, I think, force C++11 for the configure) and then > the build takes it away by forcing -std=c++11. That was not right. We add std=c++11 to the compiler command. However,as noted (earlier in this thread) the isl configure has the idiom - does the compiler do c++17 with no options? - does the compiler do c++17 if we add -std=c++17? where the second one overrides our setting of std=c++11 in the compiler comand. (I think that this is a reasonably often used idiom in configures) However the isl configure _does_ still append CXXFLAGS, and so that if we add -std=c++11 to those, it re-asserts our intent. Maybe we should just add the -std=c++11 to CXXFLAGS instead of the compiler command? Iain >> In light of that, I feel that skipping it for bootstrap is probably the >> right solution here. Alas, my skill with autotools is closer to the >> caveman-with-club level rather than that of a surgeon. > > I am not sure we have an easy way to exclude a host module from > stage1 only (but ICBW). > > Iain > >> >> --Ben
[RFC] Draft Xtensa FDPIC ABI
Hello. This is a draft FDPIC ABI specification for the Xtensa architecture. Please send comments. I will be implementing the final ABI version in gcc and binutils. The Xtensa FDPIC ABI April 8, 2024 Version 1 Based on SH FDPIC ABI Version 1.0 by Joseph Myers. Based on FR-V FDPIC ABI Version 1.0a by Kevin Buettner, Alexandre Oliva and Richard Henderson. Introduction This document describes extensions to the existing Xtensa ELF ABI (as used on GNU/Linux) required to support the implementation of shared libraries on a system whose OS (and hardware) require that processes share a common address space. This document will also attempt to explore the motivations behind and the implications of these extensions. One of the primary goals in using shared libraries is to reduce the memory requirements of the overall system. Thus, if two processes use the same library, the hope is that at least some of the memory pages will be shared between the two processes resulting in an overall savings. To realize these savings, tools used to build a program and library must identify which sections may be shared and which must not be shared. The shared sections, when grouped together, are commonly referred to as the "text segment" whereas the non-shared (grouped) sections are commonly referred to as the "data segment". The text segment is read-only and is usually comprised of executable code and read-only data. The data segment must be writable and it is this fact which makes it non-sharable. Systems which utilize disjoint address spaces for its processes are free to group the text and data segments in such a way that they may always be loaded with fixed relative positions of the text and data segments. I.e, for a given load object, the offset from the start of the text segment to the start of the data segment is constant. This property greatly simplifies the design of the shared library machinery. The design of the shared library mechanism described in this document does not (and cannot) have this property. Due to the fact that all processes share a common address space, the text and data segments will be placed at arbitrary locations relative to each other and will therefore need a mechanism whereby executable code will always be able to find its corresponding data. One of the CPU's registers is typically dedicated to hold the base address of the data segment. This register will be called the "FDPIC register" in this document. Such a register is sometimes used in systems with disjoint address spaces too, but this is for efficiency rather than necessity. The fact that the locations of the text and data segments are at non-constant offsets with respect to each other also complicates function pointer representation. As noted above, executable code must be able to find its corresponding data segment. When making an indirect function call, it is therefore important that both the address of the function and the base address of the data segment are available. This means that a function pointer needs to represented as the address of a "function descriptor" which contains the address of the actual code to execute as well as the corresponding data (FDPIC register) address. FDPIC Register -- The FDPIC register is used as a base register for accessing the global offset table (GOT) and function descriptors. Since both code and data are relocatable, executable code may not contain any instruction sequences which directly encode a pointer's value. Instead, pointers to global data are indirectly referenced via the global offset table. At load time, pointers contained in the global offset table are relocated by the dynamic linker to point at the correct locations. This FDPIC ABI is defined as extension of the base call0 Xtensa ABI. Register a11 is used as the FDPIC register. Version of the FDPIC ABI based on windowed Xtensa ABI is not defined in this document revision. Upon entry to a function, the caller saved register a11 is the FDPIC register. As described above, it contains the GOT address for that function. a11 obtains its value in one of the following ways: 1) By being inherited from the calling function in the case of a direct call to a function within the same load module. 2) By being set from a function descriptor as part of a direct or an indirect call. The specifics associated with each of these cases are covered in greater detail in "Function Calls", below. A non-leaf function should save a11 either on the stack or in one of the callee-saved registers if it needs to use it later. After that there's no requirement to preserve the original a11 value, that register does not have any special meaning inside the function. Note that once a function has moved a11 to one of its callee saved registers, the function is then free to use that register as the FDPIC register for acc
Re: isl 0.26 C++17 issues when bootstrapping with GCC
On Mon, May 13, 2024 at 6:00 PM Iain Sandoe wrote: > > > > > On 13 May 2024, at 16:05, Iain Sandoe via Gcc wrote: > >> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: > >> > >> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: > >>> I suppose for bootstrapping we could disable ISL during stage1 since > >>> it enables an optional feature only. Other than that GCC only > >>> requires a C++11 compiler for building, so ISL breaks that constraint > >>> with requiring C++17. > >> > >> Note that it doesn't *require* it per sé; the tests that try it are > >> compiled if C++17 support was detected at all. The headers seem to just > >> have optional header-only `std::any`-using APIs if C++17 is around. > >> `isl` supporting a flag to disable the tests would also work, but that > >> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at > >> some point in the future. > > > > Perhaps, in the short-term (i.e. before it requires C++ > 11) we can > > solve this by ensuring that we pass -std=c++11 to the configure stages > > as well as to the build. ISTM that configure is finding C++17-capability > > (because we do not, I think, force C++11 for the configure) and then > > the build takes it away by forcing -std=c++11. > > That was not right. > We add std=c++11 to the compiler command. > > However,as noted (earlier in this thread) the isl configure has the idiom > - does the compiler do c++17 with no options? > - does the compiler do c++17 if we add -std=c++17? > > where the second one overrides our setting of std=c++11 in the compiler > comand. > > (I think that this is a reasonably often used idiom in configures) > > However the isl configure _does_ still append CXXFLAGS, and so that if > we add -std=c++11 to those, it re-asserts our intent. > > Maybe we should just add the -std=c++11 to CXXFLAGS instead of the > compiler command? I don't understand. If we set CXX to g++ -std=c++11 and ISL checks for -std=c++17 why does it then fail to add that to CXXFLAGS? > Iain > > >> In light of that, I feel that skipping it for bootstrap is probably the > >> right solution here. Alas, my skill with autotools is closer to the > >> caveman-with-club level rather than that of a surgeon. > > > > I am not sure we have an easy way to exclude a host module from > > stage1 only (but ICBW). > > > > Iain > > > >> > >> --Ben >
Re: isl 0.26 C++17 issues when bootstrapping with GCC
> On 13 May 2024, at 18:46, Richard Biener wrote: > > On Mon, May 13, 2024 at 6:00 PM Iain Sandoe wrote: >> >> >> >>> On 13 May 2024, at 16:05, Iain Sandoe via Gcc wrote: On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: > I suppose for bootstrapping we could disable ISL during stage1 since > it enables an optional feature only. Other than that GCC only > requires a C++11 compiler for building, so ISL breaks that constraint > with requiring C++17. Note that it doesn't *require* it per sé; the tests that try it are compiled if C++17 support was detected at all. The headers seem to just have optional header-only `std::any`-using APIs if C++17 is around. `isl` supporting a flag to disable the tests would also work, but that doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at some point in the future. >>> >>> Perhaps, in the short-term (i.e. before it requires C++ > 11) we can >>> solve this by ensuring that we pass -std=c++11 to the configure stages >>> as well as to the build. ISTM that configure is finding C++17-capability >>> (because we do not, I think, force C++11 for the configure) and then >>> the build takes it away by forcing -std=c++11. >> >> That was not right. >> We add std=c++11 to the compiler command. >> >> However,as noted (earlier in this thread) the isl configure has the idiom >> - does the compiler do c++17 with no options? >> - does the compiler do c++17 if we add -std=c++17? >> >> where the second one overrides our setting of std=c++11 in the compiler >> comand. >> >> (I think that this is a reasonably often used idiom in configures) >> >> However the isl configure _does_ still append CXXFLAGS, and so that if >> we add -std=c++11 to those, it re-asserts our intent. >> >> Maybe we should just add the -std=c++11 to CXXFLAGS instead of the >> compiler command? > > I don't understand. If we set CXX to g++ -std=c++11 and ISL checks > for -std=c++17 why does it then fail to add that to CXXFLAGS? This appears to be the underlying bug. — isl configure.ac does: AX_CXX_COMPILE_STDCXX_17([], [optional]) …. AM_CONDITIONAL(HAVE_CXX17, test "x$HAVE_CXX17" = "x1”) — and then Makefile.am adds the c++17-requirements: if HAVE_CXX17 noinst_PROGRAMS += isl_test_cpp17 isl_test_cpp17-checked TESTS += isl_test_cpp17 isl_test_cpp17-checked endif .. this mechanism does not seem to preserve the fact that an additional -std=c++17 was needed to get the CXX17 (and there is no mention of CXXFLAGS in Makefile.am) Not sure if it’s a bug in isl’s config - or a limitation of AX_CXX_COMPILE_STDCXX_17 itself. — assuming we file a bug and it gets agreed and fixed, we’ll still need either to skip broken versions or work around it (I have no specific preference - although I do build isl in-tree, so far 0.24 has been OK). Iain > >> Iain >> In light of that, I feel that skipping it for bootstrap is probably the right solution here. Alas, my skill with autotools is closer to the caveman-with-club level rather than that of a surgeon. >>> >>> I am not sure we have an easy way to exclude a host module from >>> stage1 only (but ICBW). >>> >>> Iain >>> --Ben
Re: isl 0.26 C++17 issues when bootstrapping with GCC
> On 13 May 2024, at 19:43, Iain Sandoe wrote: > > > >> On 13 May 2024, at 18:46, Richard Biener wrote: >> >> On Mon, May 13, 2024 at 6:00 PM Iain Sandoe wrote: >>> >>> >>> On 13 May 2024, at 16:05, Iain Sandoe via Gcc wrote: > On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: > > On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >> I suppose for bootstrapping we could disable ISL during stage1 since >> it enables an optional feature only. Other than that GCC only >> requires a C++11 compiler for building, so ISL breaks that constraint >> with requiring C++17. > > Note that it doesn't *require* it per sé; the tests that try it are > compiled if C++17 support was detected at all. The headers seem to just > have optional header-only `std::any`-using APIs if C++17 is around. > `isl` supporting a flag to disable the tests would also work, but that > doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at > some point in the future. Perhaps, in the short-term (i.e. before it requires C++ > 11) we can solve this by ensuring that we pass -std=c++11 to the configure stages as well as to the build. ISTM that configure is finding C++17-capability (because we do not, I think, force C++11 for the configure) and then the build takes it away by forcing -std=c++11. >>> >>> That was not right. >>> We add std=c++11 to the compiler command. >>> >>> However,as noted (earlier in this thread) the isl configure has the idiom >>> - does the compiler do c++17 with no options? >>> - does the compiler do c++17 if we add -std=c++17? >>> >>> where the second one overrides our setting of std=c++11 in the compiler >>> comand. >>> >>> (I think that this is a reasonably often used idiom in configures) >>> >>> However the isl configure _does_ still append CXXFLAGS, and so that if >>> we add -std=c++11 to those, it re-asserts our intent. >>> >>> Maybe we should just add the -std=c++11 to CXXFLAGS instead of the >>> compiler command? >> >> I don't understand. If we set CXX to g++ -std=c++11 and ISL checks >> for -std=c++17 why does it then fail to add that to CXXFLAGS? > > This appears to be the underlying bug. > > — isl configure.ac does: > > AX_CXX_COMPILE_STDCXX_17([], [optional]) > > …. > > AM_CONDITIONAL(HAVE_CXX17, test "x$HAVE_CXX17" = "x1”) > > — and then Makefile.am adds the c++17-requirements: > > if HAVE_CXX17 > noinst_PROGRAMS += isl_test_cpp17 isl_test_cpp17-checked > TESTS += isl_test_cpp17 isl_test_cpp17-checked > endif > > .. this mechanism does not seem to preserve the fact that an additional > -std=c++17 was needed to get the CXX17 (and there is no mention of > CXXFLAGS in Makefile.am) > > Not sure if it’s a bug in isl’s config - or a limitation of > AX_CXX_COMPILE_STDCXX_17 itself. > > — assuming we file a bug and it gets agreed and fixed, we’ll still need > either to skip broken versions or work around it (I have no specific > preference - although I do build isl in-tree, so far 0.24 has been OK) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115077
Re: FE C++ requirement
On Wed, 8 May 2024 21:40:44 +0200 Jakub Jelinek wrote: > Perhaps you don't link cobol1 with the correct make variables > as other FEs are linked? First, thank you for the careful answer. It allowed me to trace through the machinery. And I confirmed that it works, usually. The Make-lang.in for the cobol1 compiler was modelled on the one for fortran and, indeed, it's usually built statically linked to libstdc++: $ g++ -no-pie -g3 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables [...] -fno-common -DHAVE_CONFIG_H -no-pie -static-libstdc++ -static-libgcc attribs.o -o cobol1 [...] As we would expect, ldd(1) reports that output is not linked to libstdc+ +.so. Where things appear to go awry is when I try to take a shortcut: $ make -C build install where "build" is the top of the gcc build tree, where we'll eventually find build/gcc/cobol1. When done that way, cobol1 sometimes ends up dependent on libstdc++.so. I haven't tried to find out why that is, whether it's something we're doing, or something more general. It does seem like more gets built than needs to be when I do that. For now, at least I understand what the expected outcome is. The compiler should be statically linked to the C++ library. When it's not, something went wrong. --jkl
ZynqMP APU RAM Start
Hello,
the ZynqMP APU RAM start addresses are far away from 0x0:
cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- assert-uint32: null
- env-assign: null
- format-and-define: null
build-type: option
copyrights:
- Copyright (C) 2020 On-Line Applications Research (OAR)
default:
- enabled-by:
- aarch64/xilinx_zynqmp_lp64_a53
- aarch64/xilinx_zynqmp_ilp32_zu3eg
- aarch64/xilinx_zynqmp_lp64_cfc400x
- aarch64/xilinx_zynqmp_lp64_zu3eg
value: 0x1000
- enabled-by: true
value: 0x40018000
description: |
base address of memory area available to the BSP
enabled-by: true
format: '{:#010x}'
links: []
name: BSP_XILINX_ZYNQMP_RAM_BASE
type: build
What is the rationale for doing this? Any objections to change the start
address to 0x0?
What is the MMU page size used by the BSPs? Would it be possible to add
a NULL pointer protection page?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: ZynqMP APU RAM Start
On 14.05.24 08:03, Sebastian Huber wrote: Hello, the ZynqMP APU RAM start addresses are far away from 0x0: Sorry, I selected the wrong mailing list. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
