Re: [PATCH v2] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
>>> Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for >>> gcc-13, on arm-vx7r2. Ok to install? >> >> OK Thanks Jonathan! >> If there's any chance of getting the vxworks system headers fixed to >> work with GCC properly, that would be nice. That would be nice for sure. From the vendor end, that seems very unlikely, unfortunately: VxWorks, for a variety of targets, used to come with both gcc and llvm system toolchains, with active support for the two possibilities in system headers. Also Diab to some extent. Over the years, even if there are still bits around in some headers, active support for gnu toolchains was removed and I don't see that it will be reintroduced. Jakub suggested: > Fixincludes? > That seems like the standard way to workaround bugs in system headers on > proprietary targets. Indeed, although we'd really rather avoid relying on that as much/as long as we reasonably can due to a few specifities of common VxWorks setups. Since VxWorks 7, for a given base distrib for a target environment, different users or projects configure kernels specifically to include such or such feature, and this tailors the exposed set of system headers. Relying on fixincludes would require installing an instance of gcc for each such configuration, resinstalling (or re-mkheaders) every time a kernel configuration change takes place, on hosts where users might need to go through sysadmins for compiler updates. This would be, I'm afraid, a significant regression in usability. Olivier
Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__
> On 31 May 2024, at 17:52, Alexandre Oliva wrote: >> Does the vxworks toolchain need to support the PSTL headers? > > Maybe we can do without them. I really don't know. Olivier? I have no indication that we can not-support these. We are seeing many cases of C++/Ada combined codebases in a variety of VxWorks contexts so actual uses seem likely. >> If not, we could just ignore this file, so the local changes don't >> need to be re-applied when we import a new version of the header from >> upstream. > > That sounds desirable indeed. This change is supposed to spare us > (AdaCore) from precisely this sort of trouble, so it wouldn't be fair if > it made this very kind of trouble for our upstream. Of course, 100% agreed! Thanks a lot for help in looking into this! Olivier
Re: [PATCH] [vxworks] avoid mangling __STDC_VERSION_LIMITS_H__
> On 16 Apr 2024, at 05:27, Alexandre Oliva wrote:
>
>
> The mangling of the macro name that guards limits.h from reinclusion
> was mangling a c23-required macro as well. Make the edit pattern
> stricter.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install?
Ok, thanks Alex.
Olivier
> for gcc/ChangeLog
>
> * config/t-vxworks (vxw-glimits.h): Don't mangle c23-required
> __STDC_VERSION_LIMITS_H__ define.
> ---
> gcc/config/t-vxworks |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/t-vxworks b/gcc/config/t-vxworks
> index b89350c3c70f4..6063943e346e6 100644
> --- a/gcc/config/t-vxworks
> +++ b/gcc/config/t-vxworks
> @@ -57,7 +57,7 @@ T_GLIMITS_H = vxw-glimits.h
>
> vxw-glimits.h: $(srcdir)/glimits.h
> ID=`echo $(BASEVER_c) | sed -e 's/\./_/g'` && \
> - sed -e "s/_LIMITS_H__/_LIMITS_H__$${ID}_/" < $< > $@T
> + sed -e "s/_LIMITS_H___/_LIMITS_H__$${ID}_/" < $< > $@T
> mv $@T $@
>
> # Arrange to "provide" a tailored version of stdint-gcc.h
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
Re: [PATCH] Check for sysconf decl on vxworks
Good for me, thanks Alex!
> On 24 May 2023, at 07:08, Alexandre Oliva wrote:
>
>
> The sysconf function is only available in rtp mode on vxworks. In
> kernel mode, it is not even declared, but the feature test macro in
> the testsuite doesn't notice its absence because it's a link test, and
> vxworks kernel mode uses partial linking.
>
> This patch introduces an alternate test on vxworks targets to check
> for a declaration and for an often-used sysconf parameter.
>
> Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and x86-vx7r2
> with gcc-12.
>
>
> for gcc/testsuite/ChangeLog
>
> * lib/target-supports.exp (check_effective_target_sysconf):
> Check for declaration and _SC_PAGESIZE on vxworks.
> ---
> gcc/testsuite/lib/target-supports.exp | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index bd9f432e4a761..263ef35a2e4df 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -1146,6 +1146,17 @@ proc check_effective_target_mmap {} {
> # Return 1 if the target supports sysconf, 0 otherwise.
>
> proc check_effective_target_sysconf {} {
> +# VxWorks has sysconf in rtp mode only, but our way to test can't
> +# tell kernel mode doesn't, as we're doing partial links for
> +# kernel modules. We can tell by checking for a declaration, or
> +# for some sysconf parm, because configurations that don't offer
> +# sysconf don't have either.
> +if { [istarget *-*-vxworks*] } {
> + return [check_no_compiler_messages sysconfdecl assembly {
> + #include
> + int f() { return sysconf(_SC_PAGESIZE); }
> + }];
> +}
> return [check_function_available "sysconf"]
> }
>
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts. Ask me about
Re: [patch] configury support for VxWorks shared libraries
> On 10 Oct 2022, at 21:38, Jonathan Wakely wrote: > > On Mon, 10 Oct 2022 at 19:06, Olivier Hainque via Libstdc++ > wrote: >> >> Sorry, I forgot to cc libstdc++ on >> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html >> >> which includes a regen of libstdc++-v3/configure after an update >> libtool.m4. > > OK, Great :) > thanks for the heads up. You are very welcome. Thanks for your prompt feedback. Regards, Olivier
Re: [patch] configury support for VxWorks shared libraries
Sorry, I forgot to cc libstdc++ on https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html which includes a regen of libstdc++-v3/configure after an update libtool.m4. Not committed yet. With Kind Regards, Olivier > On 10 Oct 2022, at 19:05, Olivier Hainque wrote: > > Hello, > > This change introduces configury infrastructure allowing the > production of shared libraries for VxWorks, amenable to use with > non-static rtps (linked with "-non-static"). > > The ability to produce PIC code is not a given on all VxWorks > configurations, so activating this has to be explicitly requested > by configuring with --enable-shared > (https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602523.html). > > This requirement is then leveraged to factorize the configuration > processing in a mostly cpu independant manner, which makes maintenance > a lot easier. > > When activated, shared libs are built for the rtp mode only > (the only kind of entity for which they are supported by the > VxWorks environment), for code model != large at this stage as > large and PIC still don't play well together. > > We have been using this for about a year with gcc-11 based toolchains, > with support activated for aarch64, x86_64 and ppc64-vxworks7r2, and > not activated for the corresponding 32bit variants (arm, i686, ppc). > Aarch64 proved an interesting challenge with the gcc/gcc_eh split > for lse features. > > I obtained good test results with a gcc-12 based compiler for ppc64 > and could get a successful sanity check build with mainline for that > cpu as well. > > Will commit to mainline shortly. > > Cheers, > > Olivier > > 2022-10-09 Olivier Hainque > > gcc/ >* config.gcc (*vxworks*): Add t-slibgcc fragment >if enable_shared. > > libgcc/ >* config.host (*vxworks*): When enable_shared, add >libgcc and crtstuff "shared" fragments for rtp except >large code model. >(aarch64*-wrs-vxworks7*): Remove t-slibgcc-libgcc from >the list of fragments. > > toplevel/ >* libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker >and friends for rtp !large. Assume the linker has the required >abilities and set lt_cv_deplibs_check_method. > > > Then, regenerating configure scripts to reflect the libtool.m4 update. > > 2022-10-09 Olivier Hainque > > gcc/ >* configure: Regenerate. > > libatomic/ >* configure: Regenerate. > > libbacktrace/ >* configure: Regenerate. > > libcc1/ >* configure: Regenerate. > > libffi/ >* configure: Regenerate. > > libgfortran/ >* configure: Regenerate. > > libgomp/ >* configure: Regenerate. > > libitm/ >* configure: Regenerate. > > libobjc/ >* configure: Regenerate. > > liboffloadmic/ >* configure: Regenerate. > > liboffloadmic/ >* plugin/configure: Regenerate. > > libphobos/ >* configure: Regenerate. > > libquadmath/ >* configure: Regenerate. > > libsanitizer/ >* configure: Regenerate. > > libssp/ >* configure: Regenerate. > > libstdc++-v3/ >* configure: Regenerate. > > libvtv/ >* configure: Regenerate. > > lto-plugin/ >* configure: Regenerate. > > zlib/ >* configure: Regenerate. > > <0002-Generic-configury-support-for-shared-libs-on-VxWorks.patch> > >
[patch] configury support for VxWorks shared libraries
Hello, This change introduces configury infrastructure allowing the production of shared libraries for VxWorks, amenable to use with non-static rtps (linked with "-non-static"). The ability to produce PIC code is not a given on all VxWorks configurations, so activating this has to be explicitly requested by configuring with --enable-shared (https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602523.html). This requirement is then leveraged to factorize the configuration processing in a mostly cpu independant manner, which makes maintenance a lot easier. When activated, shared libs are built for the rtp mode only (the only kind of entity for which they are supported by the VxWorks environment), for code model != large at this stage as large and PIC still don't play well together. We have been using this for about a year with gcc-11 based toolchains, with support activated for aarch64, x86_64 and ppc64-vxworks7r2, and not activated for the corresponding 32bit variants (arm, i686, ppc). Aarch64 proved an interesting challenge with the gcc/gcc_eh split for lse features. I obtained good test results with a gcc-12 based compiler for ppc64 and could get a successful sanity check build with mainline for that cpu as well. Will commit to mainline shortly. Cheers, Olivier 2022-10-09 Olivier Hainque gcc/ * config.gcc (*vxworks*): Add t-slibgcc fragment if enable_shared. libgcc/ * config.host (*vxworks*): When enable_shared, add libgcc and crtstuff "shared" fragments for rtp except large code model. (aarch64*-wrs-vxworks7*): Remove t-slibgcc-libgcc from the list of fragments. toplevel/ * libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker and friends for rtp !large. Assume the linker has the required abilities and set lt_cv_deplibs_check_method. Then, regenerating configure scripts to reflect the libtool.m4 update. 2022-10-09 Olivier Hainque gcc/ * configure: Regenerate. libatomic/ * configure: Regenerate. libbacktrace/ * configure: Regenerate. libcc1/ * configure: Regenerate. libffi/ * configure: Regenerate. libgfortran/ * configure: Regenerate. libgomp/ * configure: Regenerate. libitm/ * configure: Regenerate. libobjc/ * configure: Regenerate. liboffloadmic/ * configure: Regenerate. liboffloadmic/ * plugin/configure: Regenerate. libphobos/ * configure: Regenerate. libquadmath/ * configure: Regenerate. libsanitizer/ * configure: Regenerate. libssp/ * configure: Regenerate. libstdc++-v3/ * configure: Regenerate. libvtv/ * configure: Regenerate. lto-plugin/ * configure: Regenerate. zlib/ * configure: Regenerate. 0002-Generic-configury-support-for-shared-libs-on-VxWorks.patch Description: Binary data
[patch] Tighten VXWORKS_LIBGCC_SPEC wrt libgcc_eh
Hello, VxWorks has a custom definition of LIBGCC_SPEC to accommodate the variety of "modules" a user can build (dkm, sharedlib (-shared), static rtp, or rtp depending on shared libs (-non-static)) This change reworks that spec to better support configurations with shared libraries enabled (patch coming) and document the variations. The change also prepares for a possible dual-eh (dwarf+sjlj) setup, which we (AdaCore) work on proposing. The impact on this patch is really minimal and there's no functional impact at all in the interim. The bulk of the change consists in the introduction of a couple of local macros that instantiate the link options needed to include libgcc_eh in the closure, with values depending on the configuration characteristics. A few comments are added to explain the general idea and each of the variations. Part of the changes consist in adding -lgcc after -lgcc_eh to accommodate configurations where libgcc_eh legitimately resort to libgcc functions on some targets, for example cas synchronisation routines on aarch64. We have been using this for a while in house for gcc-11 based toolchains targetting a range of vxworks7r2 configurations (arm, aarch64, ppc, ppc64, x86, x86_64, with shared libraries enabled for all the 64bit variants), as well as for vxworks6.9 on powerpc. I have verified that gcc-12 based toolchain for arm, ppc and ppc64 behave as expected and performed a sanity check build for powerpc64-vxworks7r2 on mainline. Will commit shortly. Cheers, Olivier 2022-10-09 Olivier Hainque * config/vxworks (VX_LGCC_EH_SO0, VX_LGCC_EH_SO1): New internal macros. (VXWORKS_LIBGCC_SPEC): Use them and document. 0001-Tigthen-the-addition-of-lgcc_eh-to-vxworks_libgcc_sp.patch Description: Binary data
[patch] specialize paths to version.h in _vxworks-versions.h
The _vxworks-versions.h runtime file helps us control the compilation of some library components depending on the OS version extracted out of a system header. The system header name is "version.h", and gcc has a "version.h" file of its own. gcc's version.h is now generated and the current #include from _vxworks-versions.h gets the gcc instance instead of the OS one, resulting in build failures from #if !defined(_WRS_VXWORKS_MAJOR) #error "_WRS_VXWORKS_MAJOR undefined" #endif This change introduces a twist in the way _vxworks-versions.h #includes version.h, using a relative path with components that will match in the OS include dirs only. The actual relative path is conditioned on _VSB_CONFIG_FILE to accommodate a change in the include dirs organisation between VxWorks 6 and 7. With this, our gcc-12 based builds now pass for both powerpc-vx6 and a few cpu families with vxworks7, and a a sanity check build with mainline also passes for ppc64-vxworks7. Will commit to mainline shortly, Cheers, Olivier 0001-Specialize-paths-to-version.h-in-_vxworks-versions.h.patch Description: Binary data
[patch] Downgrade DWARF_VERSION_DEFAULT to 3 for VxWorks >= 7
Hello, Using 4 as the DWARF_VERSION_DEFAULT value for VxWorks observably still hangs recent system debuggers on tbreak for some contructs, and downgrading to 3 improves the situation. Committing to mainline shortly. Cheers, Olivier 2022-03-06 Olivier Hainque gcc/ * config/vxworks.h (DWARF_VERSION_DEFAULT): Adjust from 4 to 3 for VxWorks >= 7. 0013-Downgrade-DWARF_VERSION_DEFAULT-to-3-for-VxWorks-7.patch Description: Binary data
Re: [PATCH] undef offsetof before defining it in stddef.h
> On 6 Oct 2022, at 14:17, Richard Biener wrote: >> >> Ok to commit? > > OK. Thanks!
Re: [PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)
> On 6 Oct 2022, at 14:15, Richard Biener wrote: > >> Is this ok to commit? > > I think this is reasonable, thus OK. Great, thanks Richard :-)
Re: [patch] Fix thinko in powerpc default specs for -mabi
Hi Segher,
> On 3 Oct 2022, at 18:13, Segher Boessenkool
> wrote:
>
> -mabi= does two separate things, unfortunately.
>
> First, you can use it to set the base ABI: elfv1, elfv2. But you can
> also use it to set ABI variants, ABI options: -mabi={no-,}altivec,
> -mabi={ieee,ibm}longdouble, -mabi=vec-{extabi,default}. Things in that
> latter category are completely orthogonal to anything else (except that
> some only make sense together with some base ABIs).
Ooh, I see. I understood there were abi related options internally
(this is quite visible throughout the code of course) but didn't click
on all the implications on the command -mabi line interface.
> Base ABI is not selectable for most, it is implied by your target
> triple. -mabi=elfv[12] only makes sense for targets that have either of
> the two by default.
Yes, I can see that now.
>> We have been using this for about a year now in gcc-11 based toolchains.
>> This helps our dejagnu testsuite runs for VxWorks on powerpc and
>> hasn't produced any ill side effect to date.
>
> So what exactly is this meant to do?
Biased by other ports, the presence of multiple -mabi switches
just seemed wrong on its own, so the first level motivation was
simply to address that. There might have been interactions with
another change in what we observed at the time.
I understand now that multiple -mabi on the command line is not
a problem per se, so:
> But it does not seem correct. -mabi=optionA should not override the
> -mabi=optionB set in --with-abi=, where A and B are independent, nor
> should it override the base ABI.
Agreed!
Thanks a lot for your constructive feedback, much appreciated.
With Kind Regards,
Olivier
Re: [patch] Fix thinko in powerpc default specs for -mabi
Hello, Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602143.html > 2022-09-14 Olivier Hainque > > * config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS): > Have any -mabi, not only -mabi=elfv*, override the --with-abi > configuration default. As an additional data point, the change gets the rs6000 definition in line with that of arm, mips and riscv. Thanks in advance! Best Regards, Olivier
[PATCH] undef offsetof before defining it in stddef.h
Hello, The attached patch is a proposal to #undef offsetof before the #define we do in ginclude/stddef.h, which prevents redefinition warnings from dg tests passing -Wsystem-headers on systems which provide a definition in system headers, such as VxWorks. We have been using this for a while with gcc-11 based toolchains for a wide range of configurations (linux and windows hosts, native and cross, bare board or VxWorks for a range of CPUs). This also passes build + sanity test with gcc-12 for powerpc64-vxworks7r2, then full bootstrap + regression testing for mainline on x86_64-linux. Ok to commit? Thanks in advance! With Kind Regards, Olivier 2022-09-30 Olivier Hainque gcc/ * ginclude/stddef.h: #undef offsetof before #define. 0003-undef-offsetof-before-defining-it-in-stddef.h.patch Description: Binary data
[PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)
Hello, This change is a proposal to introduce a target overridable macro to replace the hardcoded value used in common.opt to initialize dwarf_version. The main advantage compared to special code in a target override_options hook is that redefinitions by target config files are visible by both the compiler proper and by the driver, which might refer to dwarf_version in ASM_DEBUG_SPECs and friends. This is useful at least on VxWorks, where we usually need to default to dwarf 4 or even 2 to accommodate non-gdb debuggers provided by the environment, including for assembly sources used in libgcc for some ports (witnessed with lse.S on aarch64). We have been using this in a lot of gcc-11 based toolchains for various configurations for a while, cross and native. This is a noop for anything but VxWorks and helped cure crashes of target debuggers in VxWorks environments. Bootstrapped and regression tested for mainline on x86_64-linux. Is this ok to commit? Thanks in advance! Best Regards, Olivier 2022-09-30 Olivier Hainque gcc/ * defaults.h (DWARF_DEFAULT_VERSION): Define if not defined already. * common.opt (gdwarf-): Use it. * doc/tm.texi.in (DWARF_DEFAULT_VERSION): Document. * doc/tm.texi: Update accordingly. * config/vxworks.h (DWARF_DEFAULT_VERSION): Redefine. * config/vxworks.cc: Remove code setting dwarf_version, now handled by the DWARF_DEFAULT_VERSION redefinition. 0012-Introduce-DWARF_VERSION_DEFAULT-and-redefine-for-VxW.patch Description: Binary data
[patch] Prevent secondary warning from diagnostic tweak in gthr-vxworks.h
Within gthr-vxworks.h, we prevent C++ errors from missing declarations in some system headers by prepending their inclusion with a #pragma GCC diagnostic ignored "-Wstrict-prototypes" But Wstrict-prototypes is internally registered as valid for C/ObjC only, not C++, and this trick in turn triggers a Wpragma warning with -Wsystem-headers. This change just arranges to ignore the secondary warning locally. We have been using this for a while with gcc-11 based toolchains, where the only effect was the intended disappearance of a test failure observed on g++.dg/warn/Wstringop-overflow-6.C. Sanity checked with a build + basic testing with a gcc-12 compiler, then a mainline build for arm-vxworks7r2. Cheers Olivier 2021-02-03 Olivier Hainque * config/gthr-vxworks.h: Prevent Wpragma warning for the pragma diagnostics on Wstrict-prototypes. 0010-Prevent-secondary-warning-from-diagnostic-tweak-in-g.patch Description: Binary data
[patch] Refine INITFINI condition for vxworks crtstuff spec
Hello,
Working on the reintroduction of shared libraries support
(and of modules depending on shared libraries) exposed a few
test failures of simple c++ constructor tests on arm-vxworks7r2.
Investigation revealed that we were not linking the
crtstuff objects as needed from a compiler configured not to
have shared libs support, because of the ENABLE_SHARED_LIBGCC
guard in this piece of vxworks.h:
/* Setup the crtstuff begin/end we might need for dwarf EH registration
and/or INITFINI_ARRAY support for shared libs. */
#if (HAVE_INITFINI_ARRAY_SUPPORT && defined(ENABLE_SHARED_LIBGCC)) \
|| (DWARF2_UNWIND_INFO && !defined(CONFIG_SJLJ_EXCEPTIONS))
#define VX_CRTBEGIN_SPEC "%{!shared:vx_crtbegin.o%s;:vx_crtbeginS.o%s}"
crtstuff initfini array support is meant to be leveraged for
constructors regardless of whether the compiler also happens to be
configured with shared library support, so the guard on ENABLE_SHARED_LIBGCC
here is inappropriate.
This change just removes it, which cured the test c++ contructor
test failures we were observing and didn't produce adverse effect
on the rest of our builds/runs (gcc-11 based toolchains for vxowkrs7r2
on a variety of architectures).
Tested further with a gcc-12 build + basic test cycle on
both arm and ppc64 vxworks7r2, as well as ppc vxworks 6.9.
Will commit to mainline shortly.
Cheers,
Olivier
2022-09-30 Olivier Hainque
gcc/
* config/vxworks.h (VX_CRTBEGIN_SPEC, VX_CRTEND_SPEC): If
HAVE_INITFINI_ARRAY_SUPPORT, pick crtstuff objects regardless
of ENABLE_SHARED_LIBGCC.
0005-Refine-INITFINI-condition-for-vxworks-crtstuff-spec.patch
Description: Binary data
[patch] Adjust LIBGCC2_INCLUDES for VxWorks and augment comment
Hello, Investigating the reasons for libgcc build failures in a canadian context, orthogonally to the recent update of vxcrtstuff, exposed interesting differences in the way include search paths are managed between a regular Linux->VxWorks cross build and a canadian setup building a Windows->VxWorks toolchain in a Linux environment. This change augments the comment attached to LIBGCC2_INCLUDE in libgcc/config/t-vxworks to better describe the parameters at play. It also adjusts the addition of options for gcc/include and gcc/include-fixed to minimize the actual differences for libgcc in the two kinds of configurations. Will commit to mainline shortly. Cheers, Olivier 2022-03-06 Olivier Hainque libgcc/ * config/t-vxworks (LIBGCC2_INCLUDE): Augment comment. Move -I options for gcc/include and gcc/include-fixed at the end and make them -isystem. 0014-Adjust-LIBGCC2_INCLUDES-for-VxWorks-and-augment-comm.patch Description: Binary data
[patch] Improve comments and INITFINI macro use in vxcrtsutff.c
Hello, This change augments the comment attached to the use of auto-host.h in vxcrtstuff.c to better describe the reason for including it and for the associated series of #undef directives. It also augments the comment on dso_handle and removes a redundant guard on HAVE_INITFINI_ARRAY_SUPPORT for the shared version of the objects, nested within a section guarded on USE_INITFINI_ARRAY. We have been using this for a while in gcc-11 based production toolchains and I have performed a few build+test sanity checks with gcc-12 for powerpc64-vxworks7r2. This is supposedly a noop. Will commit to mainline shortly. Olivier 2022-03-06 Olivier Hainque libgcc/ * config/vxcrtstuff.c: Improve the comment attached to the use of auto-host.h and of __dso_handle. Remove redundant guard on HAVE_INITFINI_ARRAY_SUPPORT within a USE_INITFINI_ARRAY section. 0017-Improve-comments-and-INITFINI-macro-use-in-vxcrtsutf.patch Description: Binary data
[patch] Define a GCC_DRIVER_HOST_INITIALIZATION for VxWorks
Hello, This change prepares the ground prior to the reintroduction of shared libs support for VxWorks. On this platform, the use of shared libraries involves unusual steps compared to standard native systems and enforcing static links by default improves user experience. This change arranges for the driver to insert a '-static' option by default for this purpose. g++ makes choices depending on such options from its lang_specific_driver, so our default needs to be conveyed before that and specs aren't handled early enough. We then proceed by defining a GCC_DRIVER_HOST_INITIALIZATION macro for VxWorks, to insert a -static option in case the user hasn't provided any explicit indication on the command line of the kind of link desired. While a HOST macro doesn't seem appropriate to control a target OS driven behavior, this matches other uses and won't conflict as VxWorks is not supported on any of the other configurations using this macro, and we expect at least warnings if a not a plain failure if a build with conflicting definitions is attempted. We have been using this in gcc-11 based production compilers for a while. I have performed a couple of build+test cycles on gcc-12 for powerpc64-vxworks7r2 and powerpc-vxworks6.9, and did a sanity checking build of all-gcc for arm-wrs-vxworks7r2. Cheers, Olivier 2022-09-29 Marc Poulhies Olivier Hainque gcc/ * config/vxwkorks/vxwkorks-driver.cc: New. * config.gcc (*vxwkorks*): Add vxworks-driver.o in extra_gcc_objs. * config/t-vxworks: Add vxworks-driver.o. * config/vxworks.h (GCC_DRIVER_HOST_INITIALIZATION): New. 0016-Define-GCC_DRIVER_HOST_INITIALIZATION-for-VxWorks-ta.patch Description: Binary data
[patch] Arrange to --disable-shared by default for VxWorks
Hello, Preparing a set of changes to support shared libs for VxWorks (again), this patch makes sure that shared libraries for this family of targets are only built on explicit request, when configured with --enable-shared (by passing down --disable-shared to subdirs otherwise). This provides us with a robust way to guard the relevant pieces in other configure scripts and reduces the risks of accidentally breaking a platform not yet ready for it, should enable-shared be implicitly set without this change. We have been using this for a while now in gcc-11 based production toolchains with and without shared lib support (depending on the CPU). I have performed a couple of build + test checks with gcc-12 for powerpc64, then bootstrapped and regression tested on x86_64-linux. Committing to mainline shortly. Best Regards, Olivier 2022-09-29 Olivier Hainque * configure.ac (*vxworks*): If enable_shared is not set, set to "no" and add --disable-shared to target and host_configargs. * configure: Regenerate. 0008-Arrange-to-disable-shared-by-default-for-VxWorks.patch Description: Binary data
[patch] comment about HAVE_INITFINI_ARRAY_SUPPORT in vxworks.h
Hello, This change simply adds a comment in vxworks.h, describing our expectations wrt our use of HAVE_INITFINI_ARRAY_SUPPORT from this header. Committing to mainline shortly. Cheers, Olivier 2022-09-29 Olivier Hainque gcc/ * config/vxworks.h: Add comment on our use of HAVE_INITFINI_ARRAY_SUPPORT. 0006-Comment-about-HAVE_INITFINI_ARRAY_SUPPORT-in-vxworks.patch Description: Binary data
[patch] Robustify DWARF2_UNWIND_INFO handling in vx-common.h
Hello, This adjusts vx-common.h to #define DWARF2_UNWIND_INFO to 0 when ARM_UNWIND_INFO is set, preventing defaults.h from possibly setting DWARF2_UNWIND_INFO to 1 (as well) on its own afterwards if the macro isn't defined. We have been using this for a while in gcc-11 development toolchains for a variety of VxWorks targets, including arm and aarch64, and I have performed a couple of sanity check build for ppc64-vx7r2 and arm-vx7r2 with gcc-12. Committing to mainline where the patch applies as-is and where the close context (defaults.h defining DWARF2_UNWIND_INFO) hasn't changed. Cheers, Olivier 2022-03-10 Olivier Hainque gcc/ * config/vx-common.h (DWARF2_UNWIND_INFO): #define to 0 when ARM_UNWIND_INFO is set. 0015-Robustify-DWARF_UNWIND_INFO-handling-in-vx-common.h.patch Description: Binary data
[patch] Add an mcmodel=large multilib for aarch64-vxworks
Hello, This makes good sense in general anyway, and in particular with forthcoming support for shared shared libraries, which will work for mrtp alone but not yet for mrtp+mcmodel=large. We have been using this in gcc-11 based development toolchains for a while. Committing to mainline. Regards, Olivier 2022-03-20 Olivier Hainque gcc/ * config/aarch64/t-aarch64-vxworks: Request multilib variants for mcmodel=large. 0004-Add-an-mcmodel-large-multilib-for-aarch64-vxworks.patch Description: Binary data
[patch] Remove TARGET_FLOAT128_ENABLE_TYPE setting for VxWorks
Hello, We have, in vxworks.h: /* linux64.h enables this, not supported in vxWorks. */ #undef TARGET_FLOAT128_ENABLE_TYPE #define TARGET_FLOAT128_ENABLE_TYPE 0 We inherit linux64.h for a few reasons, but don't really support float128 for vxworks, so the setting made sense. Many tests rely on the linux default (1) though, so resetting is causing lots of failures on compilation tests that would pass otherwise. Not resetting lets users write code declaring floa128 objects but linking will typically fail at some point, so there's no real adverse effect. Bottom line is we don't have any particular incentive to alter the default, whatever the default, so better leave the parameter alone. Tested with internal testsuites for VxWorks and the dg testsuite on a variety of gcc-11 based compilers. Checked that the compiler still builds and passes a few internal testsuites with a gcc-12 compiler for ppc64-vx7r2. Committing to mainline. Olivier 2022-04-19 Olivier Hainque * config/vxworks.h (TARGET_FLOAT128_ENABLE_TYPE): Remove resetting to 0. 0002-Remove-TARGET_FLOAT128_ENABLE_TYPE-setting-for-VxWor.patch Description: Binary data
[patch] Fix thinko in powerpc default specs for -mabi
Hello,
For a powerpc compiler configured with --with-abi=elfv2, an explicit
-mabi option other than elfv1 fails to override the default.
For example, after
[...]/configure --enable-languages=c --target=powerpc-elf --with-abi=elfv2
make all-gcc
This command:
./gcc/xgcc -B./gcc/ t.c -mabi=ieeelongdouble -v
issues:
./gcc/cc1 [...] t.c -mabi=ieeelongdouble -mabi=elfv2
elfv2 overrides the user request here, which I think
is not as intended.
This is controlled by OPTION_DEFAULT_SPECS, where we have
{"abi", "%{!mabi=elfv*:-mabi=%(VALUE)}" },
>From https://gcc.gnu.org/pipermail/gcc-patches/2013-November/375042.html
I don't see an explicit reason to trigger only on elfv* . It just looks
like an oversight with a focus on elfv1 vs elfv2 at the time.
The attached patch is a proposal to correct this, simply removing the
"elfv" prefix from the spec and adding the corresponding description
to the block comment just above.
We have been using this for about a year now in gcc-11 based toolchains.
This helps our dejagnu testsuite runs for VxWorks on powerpc and
hasn't produced any ill side effect to date.
The patch also bootstraps and regtests fine on powerpc64-linux.
Is this OK to commit?
Thanks in advance!
With Kind Regards,
Olivier
2022-09-14 Olivier Hainque
* config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS):
Have any -mabi, not only -mabi=elfv*, override the --with-abi
configuration default.
commit 33933796b777591007c04448860e781ac17b9070
Author: Olivier Hainque
AuthorDate: Thu Apr 21 14:44:47 2022 +
Commit: Olivier Hainque
CommitDate: Thu Apr 21 14:47:37 2022 +
Fix thinko in --with-abi processing on powerpc
Make it so any -mabi overrides what --with-abi requests
as a default, not only -mabi=elfv*.
Part of V415-021 (-mabi overrides on powerpc)
Change-Id: I62763dee62bbbd7d446f2dd091017d0c7e719cab
diff --git a/gcc/config/rs6000/option-defaults.h b/gcc/config/rs6000/option-defaults.h
index 7ebd115755a..ecf246e6b2e 100644
--- a/gcc/config/rs6000/option-defaults.h
+++ b/gcc/config/rs6000/option-defaults.h
@@ -47,6 +47,7 @@
#endif
/* Support for a compile-time default CPU, et cetera. The rules are:
+ --with-abi is ignored if -mabi is specified.
--with-cpu is ignored if -mcpu is specified; likewise --with-cpu-32
and --with-cpu-64.
--with-tune is ignored if -mtune or -mcpu is specified; likewise
@@ -54,7 +55,7 @@
--with-float is ignored if -mhard-float or -msoft-float are
specified. */
#define OPTION_DEFAULT_SPECS \
- {"abi", "%{!mabi=elfv*:-mabi=%(VALUE)}" }, \
+ {"abi", "%{!mabi=*:-mabi=%(VALUE)}" }, \
{"tune", "%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}" }, \
{"tune_32", "%{" OPT_ARCH32 ":%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}}" }, \
{"tune_64", "%{" OPT_ARCH64 ":%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}}" }, \
Re: [PATCH] libstdc++: vxworks: remove stray include
Good for me, thanks Rasmus.
> On 4 Mar 2022, at 09:27, Rasmus Villemoes wrote:
>
> There doesn't seem to be any reason for this TU to include
> , and it causes errors when the resulting libstdc++ is used
> on our VxWorks 5.5 target - presumably because now libstdc++ itself
> contains an instance of std::ios_base::Init. Which should be mostly
> harmless, but apparently isn't, and from a QoI viewpoint should
> probably be avoided anyway.
> ---
> libstdc++-v3/config/locale/vxworks/ctype_members.cc | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libstdc++-v3/config/locale/vxworks/ctype_members.cc
> b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
> index 82569d075c6..d8ca551078d 100644
> --- a/libstdc++-v3/config/locale/vxworks/ctype_members.cc
> +++ b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
> @@ -33,7 +33,6 @@
> #include
> #include
> #include
> -#include
>
> namespace std _GLIBCXX_VISIBILITY(default)
> {
> --
> 2.31.1
>
Re: [PATCH] Add VxWorks fixincludes hack, open posix API
Hi Rasmus,
> On 17 Dec 2021, at 13:49, Rasmus Villemoes wrote:
>
> In the end, we ended up adding a two-argument overload for C++ only, as
> this is/was only relevant for getting libstdc++ (more specifically, the
> new filesystem abstraction stuff) to build. That is, we added
>
> +#if __GNUC__ > 6 && defined(__cplusplus)
> +extern "C++" {
> +extern int open (const char *name, int flags);
> +}
> +#endif
> +
>
> to fcntl.h, and added a trivial definition of that (which calls the
> tree-argument form with a 0 for mode) to the OS build. I guess it could
> also have been an inline.
I experimented with the inline track (patch attached) and we're
having good results with it. It builds and test results we get
are on par with those we had with the varargs approach.
Works better for you? Thanks again for raising the point.
Cheers,
Olivier
2021-01-10 Olivier Hainque
Rasmus Villemoes
* inclhack.def (vxworks_posix_open): New hack.
* tests/base/fcntl.h: Update.
* fixincl.x: Regenerate.
0003-Add-VxWorks-fixincludes-hack-open-posix-API.patch
Description: Binary data
Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants
Hi Rasmus, > On 17 Dec 2021, at 21:47, Olivier Hainque wrote: > >>> Don't you also need to add an fpclassify() macro? There's a >> >> We have a separate "fix" for a set of such functions indeed. > I probably can merge the two, actually. I'll do that. We have had pretty good results with the attached patch, which adds definitions of a few classification macros allowing the "checking for ISO C99 support in for C++98" bit to pass. Hope this would work for you as well, Cheers, Olivier 2021-01-10 Olivier Hainque * inclhack.def (vxworks_math_h_fp_c99): New hack. * tests/base/math.h: Update. * fixincl.x: Regenerate. 0001-Add-VxWorks-fixincludes-hack-C99-FP-classification.patch Description: Binary data
[PATCH] Add VxWorks fixincludes hack, #include sysLib.h in time.h
Hello, This change instates a new vxworks fixincludes hack to make sure there is a visible prototype of sysClkRateGet() when CLOCKS_PER_SEC is #defined to that in time.h for VxWorks < 7 (fixincludes not run otherwise). The function is provided by sysLib.h, so we arrange to #include this one at a spot which "works" for either kernel or rtp headers, as those we have for VxWorsk 6.9. This allowed us getting at least a first reasonable batch of libstdc++ test results. 2021-01-10 Olivier Hainque * inclhack.def (vxworks_time_h_syslib): New hack. * tests/base/time.h: Update. * fixincl.x: Regenerate. 0002-Add-VxWorks-fixincludes-hack-include-sysLib.h-in-tim.patch Description: Binary data
Re: [PATCH] Improve sequence logic in cxx_init_decl_processing
> On 10 Jan 2022, at 20:02, Jason Merrill wrote: > >> The attached patch just moves the reset above the test. > > OK. Great, thanks Jason! >> 2021-12-30 Olivier Hainque >> gcc/ >> * cp/decl.c (cxx_init_decl_processing): Move code possibly >> altering flag_weak before code testing it. >> Olivier
Re: [PATCH] Register --sysroot in the driver switches table
> On 10 Jan 2022, at 09:00, Richard Biener wrote: > > On Wed, Jan 5, 2022 at 6:58 PM Olivier Hainque via Gcc-patches > wrote: >> >> >> >>> On 5 Jan 2022, at 10:26, Olivier Hainque wrote: >>> >>> The change should also set "validated" true >>> when requesting to save --sysroot. >> >> The attached adjustment fixes the failure I could reproduce, >> bootstraps and regtests fine on x86_64-linux, and passes a build >> + a couple of in-house testsuites for one of our vxworks ports. >> >> Ok to commit? > > OK. Great, thanks Richard :)
[PATCH] Improve sequence logic in cxx_init_decl_processing
Hello, commit aa2c978400f3b3ca6e9f2d18598a379589e77ba0, introduced per https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545552.html makes references to __cxa_pure_virtual weak and this is causing issues on some VxWorks configurations, where weak symbols are only supported for one of the two major operating modes, and not on all versions. While trying to circumvent that, I noticed that the current code in cxx_init_decl_processing does something like: if (flag_weak) /* If no definition is available, resolve references to NULL. */ declare_weak (abort_fndecl); ... if (! supports_one_only ()) flag_weak = 0; The code possibly resetting flag_weak should presumlably execute before the test checking the flag, or we'd need a comment explaining why this surprising order is on purpose. The attached patch just moves the reset above the test. It bootstraps/regtests fine on x86_64-linux and allows better control on vxWorks. I'm not yet clear on some of the ramifications there (tigthening the definitions of SUPPORTS_ONE_ONLY and TARGET_SUPPORTS_WEAK yields lots of dg test failures) but that's another story. Ok to commit? Thanks in advance! 2021-12-30 Olivier Hainque gcc/ * cp/decl.c (cxx_init_decl_processing): Move code possibly altering flag_weak before code testing it. Olivier 0001-Improve-sequence-logic-in-cxx_init_decl_processing.patch Description: Binary data
Re: [PATCH] Register --sysroot in the driver switches table
> On 5 Jan 2022, at 10:26, Olivier Hainque wrote: > > The change should also set "validated" true > when requesting to save --sysroot. The attached adjustment fixes the failure I could reproduce, bootstraps and regtests fine on x86_64-linux, and passes a build + a couple of in-house testsuites for one of our vxworks ports. Ok to commit? Thanks in advance, Olivier 2022-01-05 Olivier Hainque * gcc.c (driver_handle_option): State --sysroot as validated. 0001-State-sysroot-option-as-validated-once-processed.patch Description: Binary data
Re: [PATCH] Register --sysroot in the driver switches table
Hi Martin, > On 5 Jan 2022, at 08:45, Martin Liška wrote: > > On 12/20/21 22:28, Olivier Hainque via Gcc-patches wrote: > I think the patch broke my cross-rx-gcc12 package, failing now with: > configure: error: in > `/home/abuild/rpmbuild/BUILD/gcc-12.0.0+git190624/obj-x86_64-suse-linux/rx-elf/libgcc': > xgcc: error: unrecognized command-line option '--sysroot=/usr/rx-elf/sys-root' > > The compiler is configured with: > > [ 21s] + ../configure --prefix=/usr --infodir=/usr/share/info > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > --enable-languages=c,c++ --enable-checking=release --disable-werror > --with-gxx-include-dir=/usr/include/c++/12 --enable-ssp --disable-libssp > --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin > --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' > --with-slibdir=/usr/rx-elf/sys-root/lib64 --with-system-zlib > --enable-libstdcxx-allocator=new --disable-libstdcxx-pch > --enable-version-specific-runtime-libs --with-gcc-major-version-only > --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-12 > --program-prefix=rx-elf- --target=rx-elf --disable-nls > --with-sysroot=/usr/rx-elf/sys-root --with-build-sysroot=/usr/rx-elf/sys-root > --with-build-time-tools=/usr/rx-elf/bin --with-newlib --disable-libsanitizer > --build=x86_64-suse-linux --host=x86_64-suse-linux > > Can you please take a look? Sure. Thanks for reporting the failure. Sorry for the breakage. The change should also set "validated" true when requesting to save --sysroot. I'm not sure why we don't see the problem with our vxworks setup - double checked again this morning, we do have successful builds passing --sysroot to the driver when configuring various libraries. Testing the patch further ...
Re: [PATCH] Register --sysroot in the driver switches table
> On 28 Dec 2021, at 17:38, Jeff Law wrote: >> gcc/ >> * gcc.c (driver_handle_option): do_save --sysroot. > OK. Thanks for the prompt review Jeff! I have another simple one coming :)
[PATCH] Register --sysroot in the driver switches table
Hello,
This change adjusts the processing of --sysroot to save the option in the
internal "switches" array, which lets self-specs test for it and provide a
default value possibly dependent on environment variables, as in
--with-specs=%{!-sysroot*:--sysroot=%:getenv("WIND_BASE" /target)}
This helps the use we have of self specs for VxWorks, and
was bootstrapped and regression tested on native 64bit linux.
Ok to commit ?
Thanks in advance,
With Kind Regards,
Olivier
>From 964829ee06ffe1bedcbab6a3b4c92c5d161aaaed Mon Sep 17 00:00:00 2001
From: Olivier Hainque
Date: Mon, 20 Dec 2021 17:47:24 +
Subject: [PATCH] Register --sysroot in the driver switches table
This change adjusts the processing of --sysroot to save the option in the
internal "switches" array, which lets self-specs test for it and provide a
default value possibly dependent on environment variables, as in
--with-specs=%{!-sysroot*:--sysroot=%:getenv("WIND_BASE" /target)}
2021-12-20 Olivier Hainque
gcc/
* gcc.c (driver_handle_option): do_save --sysroot.
---
gcc/gcc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index b75b50b87b2..beb37fe980e 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4488,7 +4488,9 @@ driver_handle_option (struct gcc_options *opts,
case OPT__sysroot_:
target_system_root = arg;
target_system_root_changed = 1;
- do_save = false;
+ /* Saving this option is useful to let self-specs decide to
+ provide a default one. */
+ do_save = true;
break;
case OPT_time_:
--
2.25.1
Re: [PATCH] Adjust VxWorks fixincludes hack for mkdir to work for C++
> On 20 Dec 2021, at 17:31, Jeff Law wrote: > > Given how vxworks specific these fixinc bits are, I think they reasonably > fall under maintainership of vxworks bits. > > So I think you can/should self-approve :-) Thanks Jeff, Rasmus has provided useful feedback on some of the hunks and I'm still looking into some of the issues. I'll proceed with those on which we're aligned, and on the other ones when we have converged on a resolution. Cheers, Olivier
Re: [PATCH] Leverage sysroot for VxWorks
Hi Rasmus,
> On 20 Dec 2021, at 12:40, Rasmus Villemoes wrote:
>
> On 10/12/2021 19.24, Olivier Hainque wrote:
>
>> For the toolchains we build, this is achieved with a few
>> configure options like:
>>
>> --with-sysroot
>> --with-build-sysroot=${WIND_BASE}/target
>
> So forward-porting our private patches up until
>
> 7bf710b5116 - libstdc++: Add support for '?' in linker script globs
>
> (i.e. the commit before this one) went without problems, with no changes
> required in our build scripts. Then when rebasing to this one, now known as
>
> f3f923e5139 - Leverage sysroot for VxWorks
>
> the build broke as expected because I'd been using somewhat different
> values of --with(-build)-sysroot. However, changing those configure
> options as indicated above again produced a working toolchain, so this
> is all good.
Great !
>> --with-specs=%{!sysroot=*:--sysroot=%:getenv(WIND_BASE /target)}
>
> However, I'm a little confused about the purpose of this one.
> First,
> shouldn't this be '%{!-sysroot=*}', i.e. with a leading dash, since
> the option is --sysroot ? But whether I use one or the other, it seems
> that the resulting compiler ignores a --sysroot argument; if I
> explicitly unexport WIND_BASE and manually add a --sysroot argument that
> should have the same effect as above, gcc fails with WIND_BASE not defined:
> The specs syntax doesn't explicitly list the negative form of %{S*:X},
> and I can't find any in-tree examples (though it's rather hard to grep
> for), so I don't even know if this is supposed to work.
I think it is, and it is used for example in:
config/i386/i386.h: {"cpu",
"%{!mtune=*:%{!mcpu=*:%{!march=*:-mtune=%(VALUE)}}}" }, \
> It's not a big deal, we can just continue to define and export
> WIND_BASE, but it's probably best for long-term maintenance if our build
> scripts and configure options are aligned with what you do on your end,
> so I would just like to understand this fully.
Sure, appreciated.
The purpose was indeed to also prevent producing the default option
if one is there already, and you are right that the form above doesn't
work as expected on this account.
I had made a couple of basic tests and thought it did, but must have
made a mistake. Might have been skewed by an implicit conviction.
The reason for which it doesn't work is the do_save = false in
driver_handle_option for --sysroot:
case OPT__sysroot_:
target_system_root = arg;
target_system_root_changed = 1;
do_save = false;
break;
Changing that has the intended effect on our use case,
with an additional dash indeed.
I'll test further and propose the change if it doesn't raise
unexpected problems. We could also even consider using DRIVER_SELF_SPECS
then.
Thanks for your feedback,
Olivier
Re: [PING] Fix size of static array in gcc.dg/vect/vect-simd-20.c
> On 20 Dec 2021, at 16:32, Jeff Law wrote: > > > > On 12/17/2021 4:21 AM, Olivier Hainque via Gcc-patches wrote: >> Hello, >> >> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html >> >> please ? >> >> Thanks in advance! > OK for the trunk. > Sorry it got lost. Thanks Jeff, no pb at all. All busy :)
Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants
> On 17 Dec 2021, at 20:16, Olivier Hainque wrote: > >> Don't you also need to add an fpclassify() macro? There's a >> >> checking for ISO C99 support in for C++98 >> >> which checks whether math.h supplies (among others) fpclassify(). > > We have a separate "fix" for a set of such functions indeed. I probably can merge the two, actually. I'll do that. >> We've patched our math.h to supply those constants as well as an >> fpclassify() macro. So I suppose the 'bypass = "FP_INFINITE"' would mean >> that this fixinclude would just be skipped for our case(?). > > That's my understanding, yes.
Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants
Hi again Rasmus, > On 17 Dec 2021, at 14:03, Rasmus Villemoes wrote: > > On 17/12/2021 13.10, Olivier Hainque wrote: >> Hello, >> >> The attached patch adds a fixincludes add for VxWorks >> to add missing FP_ constant definition to math.h, intended >> for old versions of the kernel math.h header. > > Don't you also need to add an fpclassify() macro? There's a > > checking for ISO C99 support in for C++98 > > which checks whether math.h supplies (among others) fpclassify(). We have a separate "fix" for a set of such functions indeed. > We've patched our math.h to supply those constants as well as an > fpclassify() macro. So I suppose the 'bypass = "FP_INFINITE"' would mean > that this fixinclude would just be skipped for our case(?). That's my understanding, yes.
Re: [PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c
> On 17 Dec 2021, at 16:17, Segher Boessenkool
> wrote:
>
>> In this instance, it's simple enough to be quoted directly:
>
> You may want to look into git send-email :-)
Eh, indeed.
>> --- a/gcc/testsuite/gcc.target/powerpc/pr97142.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr97142.c
>> @@ -1,5 +1,5 @@
>> /* { dg-do compile } */
>> -/* { dg-options "-Ofast" } */
>> +/* { dg-options "-Ofast -mdejagnu-cpu=power9" } */
>>
>> I'll change to power7 and commit.
>
> Okay for trunk like that. Thanks!
Sure, done. Thanks for your prompt feedback.
Cheers,
Olivier
Re: [PATCH] Add VxWorks fixincludes hack, open posix API
> On 17 Dec 2021, at 15:33, Rasmus Villemoes wrote:
>
> On 17/12/2021 15.12, Olivier Hainque wrote:
>> Hi Rasmus
>>
>>> On 17 Dec 2021, at 13:49, Rasmus Villemoes
>>> wrote:
>>
>>> I'm not sure what to do. But this patch will definitely break our build
>>> - primarily because we've done a private workaround.
>>
>> I don't think we can reasonably cope with private changes
>> to system headers.
>
> Of course not. And I'm more than willing to undo that private change if
> a suitable fix can be worked out.
>
>> Can't you just undo your workaround and use this (very simple)
>> "fix" instead?
>
> No, because as I explained, the open() implementation on vxworks 5.5
> must not be called as a two-arg function with garbage in r5.
> Do you have
> access to any of the kernel source code for the other vxworks versions
> with a three-arg-only open() in fcntl.h? If not, how can you know that
> those kernels do not make use of the mode argument even if O_CREAT is
> not in flags? (For example, I could actually imagine an implementation
> where non-zero mode would imply O_CREAT. Then 'open("foo", O_RDWR)'
> could result in foo being created with a more-or-less random mode, where
> it should have resulted in ENOENT.)
>
> I'm sure libstdc++ builds with this change, as I said I had the same
> thing initially, but after looking at the open() implementation we were
> worried about the implications.
Ah, I see. Sorry, I misunderstood the point you were making.
Let me check and think about it some more.
Cheers,
Olivier
Re: [PATCH] Add VxWworks fixincludes hack, prevent #include_next yvals.h
> On 17 Dec 2021, at 14:16, Rasmus Villemoes wrote: > > There's no yvals.h header in VxWorks 5.5, so I'm not sure I need to have > an opinion on this one. I wasn't sure about the situation on 5.5 but the fix just wont apply if there's no yvals.h around anyway. Cheers, Olivier
Re: [PATCH] Add VxWorks fixincludes hack, open posix API
Hi Rasmus > On 17 Dec 2021, at 13:49, Rasmus Villemoes wrote: > I'm not sure what to do. But this patch will definitely break our build > - primarily because we've done a private workaround. I don't think we can reasonably cope with private changes to system headers. Can't you just undo your workaround and use this (very simple) "fix" instead? Otherwise, add a local patch to your tree to remove this fix? Thanks in advance, Olivier
Re: [PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c
> On 17 Dec 2021, at 13:58, Segher Boessenkool
> wrote:
>
> Hi Olivier,
>
> Thanks for the patch!
>
> Please use p7 instead of p9.
Sure.
> Also, you attached some binary, so I cannot reply to it easily.
Ah, sorry. I did remember you told me this in the past
and renamed the file .diff to "circumvent" that, which
used to work. I'll check again.
In this instance, it's simple enough to be quoted directly:
--- a/gcc/testsuite/gcc.target/powerpc/pr97142.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr97142.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-Ofast" } */
+/* { dg-options "-Ofast -mdejagnu-cpu=power9" } */
I'll change to power7 and commit.
Thanks for your feedback!
Cheers,
Olivier
[PATCH] Add VxWworks fixincludes hack, prevent #include_next yvals.h
Hello, yvals.h on VxWorks expects the toolchain to provide its own version of the header, which we don't do. The attached patch adds a fixincludes hack to arrange to fallback on the common system definitions instead. We were able to get a successful complete build with c++ and libstdc++ after this. Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_next_yvals): New hack. * tests/base/yvals.h: New expected test result. * fixinc.x: Regenerate. 0004-Add-VxWworks-fixincludes-hack-prevent-include_next-y.patch Description: Binary data
[PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants
Hello, The attached patch adds a fixincludes add for VxWorks to add missing FP_ constant definition to math.h, intended for old versions of the kernel math.h header. As the other patches in the series, this helps libstdc++ build failures for old versions of VxWorks, 6.9 in particular for which we were able to get a successful complete build after this. Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_math_h_FP_macros): New hack. * tests/base/math.h: Update expected results. * fixinc.x: Regenerate. 0003-Add-VxWorks-fixincludes-hack-kernel-math.h-FP_-const.patch Description: Binary data
[PATCH] Add VxWorks fixincludes hack, open posix API
Hello, The attach patch adds a fixincludes "hack" for VxWorks to expose a more flexible (varargs) function prototype for 'open', able to accept calls with 2 or 3 arguments as we observe during libraries builds for powerpc vxworks 6.9. We have been using this for a while in-house. I could still observe related failures with mainline sources without the change and get a complete successful with it (plus a couple of others). Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_posix_open): New Hack. * tests/base/ioLib.h: Update expected results. * fixinc.x: Regenerate. 0002-Add-VxWorks-fixincludes-hack-open-posix-API.patch Description: Binary data
[PATCH] Adjust VxWorks fixincludes hack for mkdir to work for C++
Hello, The attached patch adjusts a very old fixincludes hack for VxWorks, to expose a varargs function prototype for "mkdir" instead of a varargs macro (!). The function version is more amenable to calls from C++ like std::mkdir(arg1, arg2). This helps libstdc++ build failures for old versions of VxWorks, 6.9 in particular for which we were able to get a successful complete build after this and a couple of other fixincludes changes which I'll send separately. Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_posix_mkdir): Refine to expose a varargs interface. * tests/base/sys/stat.h: Update expected results. * fixinc.x: Regenerate. 0001-Adjust-VxWorks-fixincludes-hack-for-mkdir-to-work-fo.patch Description: Binary data
[PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c
Hello, gcc.target/powerpc/pr97142.c scans the output assembly for specific instructions which our toolchain configured to default to -mcpu=604 doesn't produce. The PR refers to a power9 configuration for the original report, so the attached patch is a suggestion to add a -mdejagnu-cpu=power9 to dg-options, which gets the test to pass for us. Ok to commit? Thanks in advance, Olivier 0001-Add-mdejagnu-cpu-power9-to-dg-options-for-pr97142.c.diff Description: Binary data
[PING] Fix size of static array in gcc.dg/vect/vect-simd-20.c
Hello, Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html please ? Thanks in advance! With Kind Regards, Olivier > On 3 Nov 2021, at 15:54, Olivier Hainque wrote: > > Hello, > > This fixes the definition of the "p" static array in > gcc.dg/vect/vect-simd-20.c to accommodate the number of > strides performed by foo() for s == 78, which will be > 129 and not 128 since 1 / 78 > 128. > > This fixes a failure of the test we first observed in-house > on a x86_64-elf run, where the first call to foo() was clobbering > part of a static object we provide to __register_frame_info, > causing an abort() from __deregister_frame_info at termination time. > > Ok to commit? > > Thanks in advance, > > With Kind Regards, > > Olivier > > > 2021-11-02 Olivier Hainque > > testsuite/ > > * gcc.dg/vect/vect-simd-20.c: Fix size of p[] >to accommodate the number of strides performed >by foo() for s == 78. > >
[PATCH] Remove fpic multilib on x86_64-vxworks
The addition of fPIC for shared libraries is performed independently from multilibs and fpic multilibs have no other particular purpose for VxWorks at this stage. Tested together with our recent cleanups in the shared-objects support area, for a mix of builds/tests for vxworks 6.9 and 7.2 with our in-house gcc-11 based toolchains, including for x86_64 with support for shared libraries enabled. Cheers, Olivier 2021-12-14 Olivier Hainque * config/i386/t-vxworks: Drop the fPIC multilibs. 0001-Remove-fpic-multilib-on-x86_64-vxworks.patch Description: Binary data
[PATCH] Drop the fpic multilib for VxWorks on powerpc
The addition of fPIC for shared libraries is performed independently from multilibs and fpic multilibs have no other particular purpose for VxWorks at this stage. They incur extra build time, complexify the install tree and are a bit tricky because -fpic is not supported for kernel mode. Tested together with our recent cleanups in the shared-objects support area, for a mix of builds/tests for vxworks 6.9 and 7.2 with our in-house gcc-11 based toolchains, including for powerpc64 with support for shared libraries enabled. Sanity checked for mainline with a build for vxWorks 6.9. Olivier 2020-11-06 Fred Konrad gcc/ * config/rs6000/t-vxworks: Drop the fPIC multilib. 0001-Drop-the-fpic-multilib-for-powerpc-vxworks.patch Description: Binary data
[PATCH] Rework VXWORKS_LINK_SPEC for shared objects support
This change reworks the VXWORKS_LINK_SPEC a bit to fix a couple of issues observed while working on improving the support for shared objects, in particular differences between vxworks 7 and earlier regarding the need to pass specific linker options. It also introduces an internal VXWORKS_LINK_OS_SPEC to allow reuse of everything else by the powerpc-vxworks7 specific configuration. Tested as the previous patches in the current series. Best Regards, Olivier 2021-12-07 Doug Rupp Olivier Hainque gcc/ * config/vxworks.h (VXWORKS_LINK_OS_SPEC): New spec. (VXWORKS_BASE_LINK_SPEC): New spec, using the former. (VXWORKS_EXTRA_LINK_SPEC): New spec for old and new VxWorks. (VXWORKS_LINK_SPEC): Combo of BASE and EXTRA specs. * config/rs6000/vxworks.h (VXWORKS_LINK_OS_SPEC): Empty. (LINK_OS_EXTRA_SPEC32): Use VXWORKS_LINK_SPEC. (LINK_OS_EXTRA_SPEC64): Likewise. 0009-Rework-VXWORKS_LINK_SPEC-for-shared-objects-support.patch Description: Binary data
[PATCH] Remove ppc*-vxworks7* inadequate libgcc Makefile fragments
This change removes a couple of entries from the tmake_file list for ppc-vxworks7*, in particular: t-linux, which assigns .so version numbers to a set of symbols, some of which aren't included the VxWorks libgcc on powerpc (from ibm-ldouble.c, in particular). t-slibgcc-libgcc, which yields a kind of .so file that the default loader can't handle. This sort of extension to tmake_file for shared libs will be better handled in a grouped fashion for all targets. Test together as the previous patches in the current series, with successful build + in-house testing on a gcc-11 based tree (for VxWorks 7.2), then sanity checked that a build with mainline sources finishes as expected. Olivier 2021-12-13 Olivier Hainque * config.host (powerpc*-*-vxworks7*): Remove rs6000/t-linux and t-slibgcc-libgcc from tmake_file. 0008-Remove-ppc-vxworks7-inadequate-libgcc-Makefile-fragm.patch Description: Binary data
[PATCH] Remove special case for arm-vxworks on the use of vxcrtstuff
The special case for arm on the use of vxcrtstuff is not needed any more after the previous patches in this area. Cheers, Olivier 2021-12-13 Olivier Hainque libgcc/ * config.host (*vxworks*): Remove special case for arm on the use of vxcrtstuff. 0007-Remove-special-case-for-arm-vxworks-on-the-use-of-vx.patch Description: Binary data
[PATCH] Tigthen libc_internal and vxcrtstuff for VxWorks shared objects
This change tightens and documents the use of libc_internal, then strengthens the VxWorks crtstuff objects for the support of shared libraries. In particular: - Define __dso_handle, which libstdc++.so requires, - Provide _init and _fini functions to run through the init/fini arrays for shared libs in configurations which HAVE_INITFINI_ARRAY_SUPPORT. The init/fini functions are provided by libc_internal.a for static links but with slightly different names and we don't want to risk dragging other libc_internal contents in the closure accidentally so make sure we don't link with it. As for the !vxworks crtstuff, the new shared libs specific bits are conditioned by a CRTSTUFFS_O macro, for which we provide new Makefile fragment. The bits to actually use the fragment and the shared objects will be added by a forthcoming change, as part of a more general configury update for shared libs. The change also adds guards the eh table registration code in vxcrtstuff so the objects can be used for either init/fini or eh tables independently. Tested together with the other patches in the current series. Olivier 2021-12-07 Fred Konrad Olivier Hainque gcc/ * config/vxworks.h (VXWORKS_BASE_LIBS_RTP): Guard -lc_internal on !shared+!non-static and document. (VXWORKS_LIB_SPEC): Remove the bits intended to drag the init/fini functions from libc_internal in the shared lib case. (VX_CRTBEGIN_SPEC/VX_CRTEND_SPEC): Use vxcrtstuff objects also in configurations with shared lib and INITFINI_ARRAY support. libgcc/ * config/t-vxcrtstuffS: New Makefile fragment. * config/vxcrtstuff.c: Provide __dso_handle. Provide _init/_fini functions for INITFINI_ARRAY support in shared libs and guard the definition of eh table registration functions on conditions indicating they are needed. 0006-Tigthen-libc_internal-and-crtstuff-for-VxWorks-share.patch Description: Binary data
[PATCH] VxWorks config fixes for shared objects
This strengthens the VxWorks configuration files on the support
of shared objects, which encompasses a VxWorks specific "non-static"
mode for RTPs (in addition to -static and -shared).
I had good builds and test results with this in-house for gcc-11 based
toolchains for a variety of targets, with both static and dynamic links
(modulo other patches for the latter). I checked that a build for vx6.9
passes with mainline sources.
Olivier
2020-11-06 Fred Konrad
Olivier Hainque
gcc/
* config/vx-common.h: Define REAL_LIBGCC_SPEC since the
'-non-static' option is not standard.
* config/vxworks.h (VXWORKS_LIBGCC_SPEC): Implement the LIBGCC_SPEC
since REAL_LIBGCC_SPEC is used now.
(STARTFILE_PREFIX_SPEC): Use the PIC VSB when building shared libraries
or non-static binaries.
0005-VxWorks-config-fixes-for-shared-objects.patch
Description: Binary data
[PATCH] Preserve cpu specific CRTSTUFF_T_CFLAGS on powerpc-vxworks7
The unconditional assignment performed in t-vxworks to handle include flags currently overrides what specific cpu ports had for the regular (!vxworks) crtstuff objects. This was not done on purpose and the proposed change adjusts the configuration bits to apply the vxworks specific flags on top of the cpu ones instead. I had good builds and test results with this in-house for gcc-11 based toolchains for a variety of targets. I checked that a build for vx6.9 passes with mainline sources and verified that the spurious configure test failures are gone. Olivier 2021-12-07 Olivier Hainque * config.host (powerpc*-wrs-vxworks7*): Place t-crtstuff ahead of the other files in tmake_files. * config/t-vxworks: Add to CRTSTUFF_T_CFLAGS instead of overriding it. 0004-Preserve-cpu-specific-CRTSTUFF_T_CFLAGS-on-powerpc-v.patch Description: Binary data
[PATCH] Include yvals.h for VxWorks < 7 RTPs as well
Hello, For -mrtp on VxWorks 6.9, at least inttypes.h ends up #including system headers checking that _BITS_BYTES is 8, which the system yvals.h defines. We do pre-include _yvals.h ahead of inttypes.h for this kind of purpose, but it currently assumes that only VxWorks >= 7 provides yvals.h. This results in unexpected configure checks failures, complaining about _BITS_BYTES not being 8, spotted while inspecting libstdc++ config.log for unrelated reasons. This change relaxes the guard in _yvals.h to include yvals.h for __RTP__ in addition to version >= 7. I had good builds and test results with this in-house for gcc-11 based toolchains for a variety of targets. I checked that a build for vx6.9 passes with mainline sources and verified that the spurious configure test failures are gone. Will commit shortly. I'm not 100% sure about the situation on VxWorks 5. This is easy to adjust if need be. Olivier 2021-12-13 Olivier Hainque * config/vxworks/_yvals.h: #include yvals.h also if defined(__RTP__). 0002-Include-yvals.h-for-VxWorks-7-RTPs-as-well.patch Description: Binary data
Re: [PATCH] #undef isblank before def or decl in libstdc++ headers
> On 11 Dec 2021, at 18:09, Jonathan Wakely wrote: > > * config/vxworks.h (VXWORKS_OS_CPP_BUILTINS): Define > _C99 for C++. > > Makes sense? > > Yes. I can't approve patches outside libstdc++, but that looks definitely > correct for C++11 and later, because C++11 incorporates the whole C99 library > by reference. So if that macro is needed to get the C99 library (because the > vxworks libc doesn't check the__cplusplus macro and enable C99 features that > way), then I agree _C99 should be defined for C++11. Defining it for C++11 is > sufficient to solve the isblank problem, because std::isblank is only > declared for C++11 and later. (std::tr1::isblank is declared for C++98 if the > C library supports it, but nobody really cares about TR1 nowadays, and > probably hardly anybody cares about C++98). > > Defining _C99 is not strictly correct for C++98 mode, because C++98 > incorporates the C89 library by reference. But as you noted in the earlier > patch, libstdc++ likes to have full C99 facilities available even for C++98 > mode (so it can use them for std::tr1 features, among other things). So I > think defining it even for C++98 is fine too. Testing looks good so far and libstdc++ configure is a lot happier indeed. Inspecting the logs spotted an inaccuracy in another area, which I'll address separately. Thanks a lot for your feedback! With Kind Regards, Olivier
Re: [PATCH] #undef isblank before def or decl in libstdc++ headers
(Thanks for your feedback Jonathan)
> On 10 Dec 2021, at 19:24, Jonathan Wakely wrote:
>
> I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks
> has isblank, the configure check is:
Oh, hmm, very good point. The reason was that the definition
of isblank is conditioned on _C99/_HAS_C9X as well, so the need
for which we had introduced the definition in os_defines.h
would better be generalized.
* config/vxworks.h (VXWORKS_OS_CPP_BUILTINS): Define
_C99 for C++.
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -328,6 +328,10 @@ extern void vxworks_asm_out_destructor (rtx symbol, int
priority);
if (!flag_isoc99 && !c_dialect_cxx())\
builtin_define ("_ALLOW_KEYWORD_MACROS"); \
} \
+ /* C++ support relies on C99 features. Make sure they are \
+exposed by the system headers. */ \
+ if (c_dialect_cxx()) \
+ builtin_define("_C99"); \
} \
while (0)
Works with the two libstdc++ changes reverted, and gives
"configure" a better view of what's there.
Makes sense?
[PATCH] Leverage sysroot for VxWorks
Hello,
The build of a VxWorks toolchain relies a lot on system headers
and VxWorks has a few very specific features that require special
processing. For example, different sets of headers for the kernel
vs the rtp modes, which the compiler knows about by way of -mrtp
on the command line.
If we manage to avoid the need for fixincludes on recent versions
of VxWorks (>= 7), we still need to handle at least VxWorks 6.9 at
this stage.
We sort of get away with locating the correct headers at
run-time thanks to environment variables and various tests for
-mrtp in cpp specs, but getting fixincludes to work for old
configurations has always been tricky and getting a toolchain
to build with c++/libstdc++ support gets trickier with every
move to a more recent release.
sysroot_headers_suffix_spec is a pretty powerful device to help
address such issues, and this patch introduces changes that let
us get advantage of it.
The general idea is to leverage the assumption that compilations
occur with --sysroot=$VSB_DIR on vx7 or --sysroot=$WIND_BASE/target
prior to that.
For the toolchains we build, this is achieved with a few
configure options like:
--with-sysroot
--with-build-sysroot=${WIND_BASE}/target
--with-specs=%{!sysroot=*:--sysroot=%:getenv(WIND_BASE /target)}
This allows simplifying the libgcc compilation flags control
and we take the opportunity to merge t-vxworks7 into t-vxworks as
the two files were differing only on the libgcc2 flags part.
This also makes sure that we don't set inhibit_libc true
during the build, which is sane since the build really relies a
lot on system headers.
Preliminary tests showed that a build from mainline sources
now actually fail if the build configuration somehow gets to
inhibit_libc=true.
I have had very good results with this for several ports on a
gcc-11 branch, for both VxWorks 6.9 and two variants of 7.2,
for both kernel and rtp modes, including with shared libs on
two targets for 7.2 (powerpc64 and x86_64).
I was also able to get a successful build of c, c++
and libstdc++ on mainline for VxWorks 6.9, with a few fixincludes
adjustments as expected.
This touches only VxWorks related items and, all in all, I
believe this robustifies the family of ports and helps avoid
build failure with mainline sources so remains applicable
to the current stage.
Olivier
---
2021-12-09 Olivier Hainque
gcc/
* config/t-vxworks: Clear NATIVE_SYSTEM_HEADER_DIR.
* config/vxworks.h (SYSROOT_HEADERS_SUFFIX_SPEC): Define, for
VxWorks 7 and earlier.
(VXWORKS_ADDITIONAL_CPP_SPEC): Simplify accordingly.
(STARTFILE_PREFIX_SPEC): Adjust accordingly.
* config/rs6000/vxworks.h (STARTFILE_PREFIX_SPEC): Adjust.
libgcc/
* config/t-vxworks (LIBGCC2_INCLUDES): Simplify and handle
both VxWorks7 and earlier.
* config/t-vxworks7: Remove.
* config.host: Remove special case for vxworks7.
0001-Leverage-sysroot-for-VxWorks.patch
Description: Binary data
[PATCH] #undef isblank before def or decl in libstdc++ headers
Hello, The attached patch helps fix a build failure of libstdc++ on some variants of VxWorks where the system headers expose an "isblank" macro. I understand this kind of thing normally is handled through fixincludes, however fixincludes on VxWorks is very tricky and we already have libstdc++-v3/include/c_global/cctype:#undef isblank libstdc++-v3/include/tr1/cctype:#undef isblank so the suggestion here is to simply do the same in a couple more places. I checked that it gets us through the observed build failure for VxWorks, then bootstrapped and regtested on native 64bit linux. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-07 Olivier Hainque libstdc++-v3/ * include/bits/locale_facets.h: #undef isblank before providing a definition. * libstdc++-v3/include/bits/localefwd.h: Likewise. 0001-Add-undef-isblank-before-definition-or-decl-in-bits-.patch Description: Binary data
Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h
> On 10 Dec 2021, at 16:42, Jonathan Wakely wrote: > > > OK to commit then, thanks. > > The comment is a bit misleading though: > > +// libstdc++ relies on C99 features for virtually all versions of C++, > +// up to at least C++98. > +#undef _C99 > +#define _C99 1 > > The "up to" seems backwards, I'd expect it to say "down to" or "as far > back as at least C++98". > > But there's nothing older than C++98 anyway, so this just means "all > versions", there's no "virtually" about it. > > Please just say "libstdc++ relies on C99 features for all versions of C++". Sure, thanks Jonathan. Yes, I agree the comment is confused. I hesitated between a couple of perspectives and just mixed things up. Thanks for your prompt review! Olivier
Re: [PATCH 2/4] libgcc: vxcrtstuff.c: remove ctor/dtor declarations
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > These declarations prevent the priority given in the > constructor/destructor attributes from taking effect, thus emitting > the function pointers in the ordinary (lowest-priority) > .init_array/.fini_array sections. > > libgcc/ > * config/vxcrtstuff.c: Remove constructor/destructor > declarations. Ok, thanks. Olivier
Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static
> On 10 Dec 2021, at 16:07, Rasmus Villemoes wrote: > >> >> This is OK, can you please commit? > > Well, yes, but it depends contextually (but not functionally) on patch > 2/4. Should I redo this one, or can I get you to take a look at 2/4 first? > > You've already ok'ed 1/4 and 4/4 (which were anyway independent of each > other and 2,3) and I've committed those Ah, sure. Yes, 2/4 is ok as well. I have been testing with a combined version of the two, actually. I'll send a separate approval for 2/4 momentarily. Thanks. Olivier
[PATCH] Define _C99 in libstdc++ vxworks/os_defines.h
Hello, The attached patch for libstdc++ / VxWorks helps building the library for old versions of the OS, as witnessed with VxWorks 6.9 in particular. It explicitly requests C99 features from old system headers, on which libstc++ relies since at least c++98. The specific issue that exposed this was a failure to compile libstdc++-v3/src/c++17/floating_to_chars.cc for VxWorks 6.9 with a batch of errors such as: error: 'FP_NAN' was not declared in this scope The missing definitions are provided by the system headers with guards on _HAS_C9X, which gets internally defined when _C99 is. Ok to commit? Thanks in advance! 2021-12-07 Olivier Hainque libstdc++-v3/ * config/os/vxworks/os_defines.h: #define _C99. Olivier 0001-Define-_C99-in-libstdc-vxworks-os_defines.h.patch Description: Binary data
Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static
Hi again Rasmus, > On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > When the translation unit itself creates pointers to the ctors/dtors > in a specific section handled by the linker (whether .init_array or > .ctors.*), there's no reason for the functions to have external > linkage. That ends up polluting the symbol table in the running > kernel. > > This makes vxcrtstuff.c on par with the generic crtstuff.c which also > defines e.g. frame_dummy and __do_global_dtors_aux static. > > libgcc/ > * config/vxcrtstuff.c: Make constructor and destructor > functions static when possible. This is OK, can you please commit? Thanks! Cheers, Olivier
[PATCH] Fix inaccuracies in VxWorks LINK_SPEC
Hello,
The attached patch fixes a couple of incorrect things in
the VxWorks default LINK_SPEC, exposed during our work on
the support for building shared libraries.
-v needs to generate a -V not -v, as most/all other ports do,
to output the available emulations.
The latter causes collect2 to output exec'd collect-ld with same
switches, which in turn causes a configure test which accumulates
linker switches to contain duplicates, leading to a libstdc++ configure
failure in some configurations.
The change also removes reference to %(link_target), long obsolete.
Tested with builds and test runs on VxWorks 6.9 and 7.2.
Olivier
2021-12-07 Doug Rupp
* config/vxworks.h (LINK_SPEC): Remove %(link_target).
Change %{v:-v} to %{v:-V}.
0001-Fix-inaccuracies-in-VxWorks-LINK_SPEC.patch
Description: Binary data
[PATCH] Remove assignment to STMP_FIXINC from t-vxworks
Hello, The attached patch just removes the assignment to STMP_FIXINC from t-vxworks. This aligns VxWorks with what the vast majority of targets do and the value set was redundant with the default Makefile setting anyway, possibly confusing on a target when the management of fixincludes is pretty sensitive (more patches coming for that). Tested with build + tests on both Vxworks 6.9 and 7.2. Olivier 2021-12-07 Olivier Hainque * config/t-vxworks: Remove assignment to STMP_FIXINC. 0001-Remove-assignment-to-STMP_FIXINC-from-t-vxworks.patch Description: Binary data
Re: [PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*
> On 10 Dec 2021, at 14:29, Rasmus Villemoes wrote: > > On 10/12/2021 14.08, Olivier Hainque wrote: >> Hello, >> >> The attached patch is the one originally sent by Rasmus at >> >> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*) >> >> and which escaped the radar at the time. >> >> The change looked good and turned out helpful in the context of >> work on the support of shared library for VxWorks. >> >> Tested on VxWorks 7.2 and sanity checked with a build for VxWorks 6.9, >> I'll commit shortly. > > Thanks, I've actually been carrying that locally ever since (because I > have other changes on top that rely on it), so I'm quite confident > including that upstream won't break anything on my end :) Great, thanks for confirming. I still have a few minor cleanups to post, then a few more involved, starting with one regarding the use of sysroot prior to the bits more geared towards shared libraries. Cheers, Olivier
[PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*
Hello, The attached patch is the one originally sent by Rasmus at https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*) and which escaped the radar at the time. The change looked good and turned out helpful in the context of work on the support of shared library for VxWorks. Tested on VxWorks 7.2 and sanity checked with a build for VxWorks 6.9, I'll commit shortly. Thanks for proposing it in the first place Rasmus :) 2021-12-07 Rasmus Villemoes libgcc/ * config/rs6000/t-vxworks: New file. * config.host (powerpc*-*-vxworks*): Use it instead of t-ppccomm. --- (*) VxWorks doesn't use the __eabi function (in fact, the ecrti.o and ecrtn.o files are not added to extra_parts). This means that the __SBSS_END__ etc. symbols in eabi.S are always undefined. This is mostly harmless, but it is inconvenient when one wants to create a libgcc runtime module by doing a --whole-archive link of libgcc.a. Moreover, it turns out that ibm-ldouble.o ends up being empty for powerpc-wrs-vxworks, since only __ppc__ and __PPC__ are TARGET_OS_CPP_BUILTINS, while the entire ibm-ldouble.c is protected by #if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \ && !defined (__rtems__) To avoid the above inconvenience, and make it a little more clear what actually gets built and used for powerpc-wrs-vxworks, create a new t-vxworks which adds tramp.S to LIB2ADD, and use that instead of t-ppccomm. --- 0001-Replace-t-ppccomm-by-t-vxworks-in-libgcc-config-rs60.patch Description: Binary data
[PATCH] Fix path to t-ppc64-fp for ppc*-vxworks7* libgcc tmake_file
Hello, This fixes a basic mistake in the relative path used to reference a rs6000 specific Makefile fragment in the libgcc configuration bits for powerpc*-vxworks7*. This addresses build failures from link errors observed during preliminary work on the support for shared libraries on powerpc64. Will commit to mainline shortly. Olivier 2021-12-09 Fred Konrad libgcc/ * config.host (powerpc*-wrs-vxworks7*: Fix path to rs6000/t-ppc64-fp, relative to config/ not libgcc/. 0001-Fix-path-to-t-ppc64-fp-for-powerpc-wrs-vxworks7.patch Description: Binary data
Leverage VX_CPU_PREFIX in aarch64-vxworks.h
Hello, The attached patch tightens the CPU macro definitions issued for VxWorks system headers on aarch64 to incorporate the common VX_CPU_PREFIX facility, as the powperpc port does. The net effect for current configurations is the addition of an actual "_VX_" prefix to the references to architecture representative values. The absence of this prefix is most often compensated for in system headers, but not always (when going through particular #include paths), and this caused a couple of spurious test failures. We have been using this in-house successully for close to a couple of years now, on variations of VxWorks 7. I'll commit to mainline shortly. Olivier -- 2021-04-09 Olivier Hainque gcc/ * config/aarch64/aarch64-vxworks.h (TARGET_OS_CPP_BUILTINS): Use VX_CPU_PREFIX in CPU definitions. 0001-Leverage-VX_CPU_PREFIX-in-aarch64-vxworks.h.patch Description: Binary data
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
> On 6 Dec 2021, at 04:05, Alexandre Oliva wrote: > > On Dec 3, 2021, Olivier Hainque wrote: > >> Alex, how does that look to you? > > LGTM, thanks, Great, thanks. I'll commit shortly and will soon start proposing the batch of other changes I have been mentioning. Some of this might not be stage 3 amenable, so maybe commits will have to wait for the next stage 1. We'll see. It will give Rasmus an opportunity to see what's coming, still. Olivier
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
> On 3 Dec 2021, at 11:27, Rasmus Villemoes wrote: > > Reverting my fix and applying this on top of my gcc-11.2 based branch > seems to work. I haven't used the compiler for building or running any > modules (don't have the hardware handy), but I've done an 'objdump -d' > comparison on all the generated host binaries and target libraries with > no diff. > > So OK by me. Thanks for checking. Bootstrap and regression tests passed on a native x86_64-linux host. Alex, how does that look to you? Thanks in advance!
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
Hi Rasmus, Some new on this. > On 20 Nov 2021, at 09:07, Olivier Hainque wrote: > > I'll check how our build sequence proceeds. Turns out our build succeeds thanks to the presence of a vendor version of stdint.h in the VxWorks6/7 header dirs and we're lucky that the need to pre-include yvals.h isn't showing up during the libraries' build. It is of course not good to use one version during the build of libraries then install an alternate version that will be used by programs afterwards. The attached patch achieves the same kind of thing you initiated, only reusing a method previously introduced for glimits.h instead of adding a new use_gcc_stdint value, which seems a bit less intrusive to me. This introduces an indirect dependency on the VxWorks version.h for vxcrtstuff objects, for which we then need to apply the same tricks as for libgcc2 regarding include paths (to select the system header instead of the gcc one). I have had a few succesful builds and tests with this, for both VxWorks 6 and VxWorks 7 configurations. Bootstrap and regtest on x86°64-linux in progress. cc'ed Alex who proposed the T_GLIMITS_H change. Olivier 2021-02-12 Olivier Hainque Rasmus Villemoes gcc/ * Makefile.in (T_STDINT_GCC_H): New variable, path to stdint-gcc.h that a target configuration may override when use_gcc_stdint is "provide". (stmp-int-hdrs): Depend on it and copy that for USE_GCC_INT=provide. * config.gcc (vxworks): Revert to use_gcc_stdint=provide. * config/t-vxworks (T_STDINT_GCC_H): Define, as vxw-stdint-gcc.h. (vxw-stdint-gcc.h): New target, produced from the original stdint-gcc.h. (vxw-glimits.h): Use an automatic variable to designate the first and only prerequisite. * config/vxworks/stdint.h: Remove. libgcc/ * config/t-vxworks: Set CRTSTUFF_T_CFLAGS to $(LIBGCC2_INCLUDES). * config/t-vxworks7: Likewise. 0001-Provide-vxworks-alternate-stdint.h-during-the-build.patch Description: Binary data
Re: [PATCH v2] fix spelling of -linker-output-auto-nolto-rel
Hi Rasmus,
The VxWorks part is ok. The plugin part looks good to me
as well, now in line with Richard's comment, but is not for
me to approve.
Thanks, and Thanks Richard for the original review.
Cheers,
Olivier
> On 2 Dec 2021, at 08:22, Rasmus Villemoes wrote:
>
> The transposition nolto -> notlo is confusing and it makes the long
> name even harder to read than it already is - I kept reading it as
> "not lo" until I realized it was a simple typo.
>
> Fixes: 5269b24605b1 (Silence warning in LTO mode on VxWorks)
>
> lto-plugin/
> * lto-plugin.c: Fix -linker-output-auto-notlo-rel ->
> -linker-output-auto-nolto-rel typo.
> (process_option): Adjust accordingly, accepting both old and
> new spelling.
>
> gcc/
> * config/vxworks.h (LTO_PLUGIN_SPEC): Adapt to corrected
> spelling of -linker-output-auto-nolto-rel.
> ---
> v2: still accept -linker-output-auto-notlo-rel in the plugin.
>
> Like this?
>
> gcc/config/vxworks.h| 2 +-
> lto-plugin/lto-plugin.c | 6 --
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
> index e41f16a51e8..bddf2c37f42 100644
> --- a/gcc/config/vxworks.h
> +++ b/gcc/config/vxworks.h
> @@ -306,4 +306,4 @@ extern void vxworks_emit_call_builtin___clear_cache (rtx
> begin, rtx end);
>further incremental LTO linking. We do not do repeated incremental linking
>so silence the warning (instead of passing -flinker-output=nolto-rel). */
> #undef LTO_PLUGIN_SPEC
> -#define LTO_PLUGIN_SPEC "%{!mrtp:-plugin-opt=-linker-output-auto-notlo-rel}"
> +#define LTO_PLUGIN_SPEC "%{!mrtp:-plugin-opt=-linker-output-auto-nolto-rel}"
> diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
> index 6ab9822f369..b73483de994 100644
> --- a/lto-plugin/lto-plugin.c
> +++ b/lto-plugin/lto-plugin.c
> @@ -32,7 +32,7 @@ along with this program; see the file COPYING3. If not see
>-nop: Instead of running lto-wrapper, pass the original to the plugin. This
>only works if the input files are hybrid.
>-linker-output-known: Do not determine linker output
> - -linker-output-auto-notlo-rel: Switch from rel to nolto-rel mode without
> + -linker-output-auto-nolto-rel: Switch from rel to nolto-rel mode without
>warning. This is used on systems like VxWorks (kernel) where the link is
>always partial and repeated incremental linking is generally not used.
>-sym-style={none,win32,underscore|uscore}
> @@ -1321,7 +1321,9 @@ process_option (const char *option)
> {
> if (strcmp (option, "-linker-output-known") == 0)
> linker_output_known = true;
> - else if (strcmp (option, "-linker-output-auto-notlo-rel") == 0)
> + /* Also accept "notlo" for backwards compatibility. */
> + else if ((strcmp (option, "-linker-output-auto-nolto-rel") == 0)
> + || (strcmp (option, "-linker-output-auto-notlo-rel") == 0))
> linker_output_auto_nolto_rel = true;
> else if (strcmp (option, "-debug") == 0)
> debug = true;
> --
> 2.31.1
>
Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static
Hi Rasmus,
We had something close but slight different for
the support of shared libraries (for which I'm preparing
the patches). I think your version should work as well
but we have quite a few configurations and the devil is
in the details so I'm testing the effects in a few cases
before approving.
Olivier
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>
> When the translation unit itself creates pointers to the ctors/dtors
> in a specific section handled by the linker (whether .init_array or
> .ctors.*), there's no reason for the functions to have external
> linkage. That ends up polluting the symbol table in the running
> kernel.
>
> This makes vxcrtstuff.c on par with the generic crtstuff.c which also
> defines e.g. frame_dummy and __do_global_dtors_aux static.
>
> libgcc/
> * config/vxcrtstuff.c: Make constructor and destructor
> functions static when possible.
> ---
> libgcc/config/vxcrtstuff.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libgcc/config/vxcrtstuff.c b/libgcc/config/vxcrtstuff.c
> index c146e1be3be..652a65364b0 100644
> --- a/libgcc/config/vxcrtstuff.c
> +++ b/libgcc/config/vxcrtstuff.c
> @@ -58,14 +58,18 @@ __attribute__((section(__LIBGCC_EH_FRAME_SECTION_NAME__),
> aligned(4)))
>
> #define EH_CTOR_NAME _crtbe_register_frame
> #define EH_DTOR_NAME _ctrbe_deregister_frame
> +#define EH_LINKAGE static
>
> #else
>
> /* No specific sections for constructors or destructors: we thus use a
>symbol naming convention so that the constructors are then recognized
> - by munch or whatever tool is used for the final link phase. */
> + by munch or whatever tool is used for the final link phase. Since the
> + pointers to the constructor/destructor functions are not created in this
> + translation unit, they must have external linkage. */
> #define EH_CTOR_NAME _GLOBAL__I_00101_0__crtbe_register_frame
> #define EH_DTOR_NAME _GLOBAL__D_00101_1__crtbe_deregister_frame
> +#define EH_LINKAGE
>
> #endif
>
> @@ -88,13 +92,13 @@ __attribute__((section(__LIBGCC_EH_FRAME_SECTION_NAME__),
> aligned(4)))
>
> #endif /* USE_INITFINI_ARRAY */
>
> -EH_CTOR_ATTRIBUTE void EH_CTOR_NAME (void)
> +EH_LINKAGE EH_CTOR_ATTRIBUTE void EH_CTOR_NAME (void)
> {
> static struct object object;
> __register_frame_info (__EH_FRAME_BEGIN__, );
> }
>
> -EH_DTOR_ATTRIBUTE void EH_DTOR_NAME (void)
> +EH_LINKAGE EH_DTOR_ATTRIBUTE void EH_DTOR_NAME (void)
> {
> __deregister_frame_info (__EH_FRAME_BEGIN__);
> }
> --
> 2.31.1
>
Re: [PATCH 4/4] libgcc: vxcrtstuff.c: add a few undefs
Hi Rasmus, > On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > libgcc/ > * config/vxcrtstuff.c: Undefine caddr_t, pid_t, rlim_t, > ssize_t and vfork after including auto-host.h. Ok, thanks;
Re: [PATCH 1/4] libgcc: remove crt{begin,end}.o from powerpc-wrs-vxworks target
Hi Rasmus,
(making progress but not quite there on the stdint business)
> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote:
>
> Since commit 78e49fb1bc (Introduce vxworks specific crtstuff support),
> the generic crtbegin.o/crtend.o have been unnecessary to build. So
> remove them from extra_parts.
>
> This is effectively a revert of commit 9a5b8df70 (libgcc: add
> crt{begin,end} for powerpc-wrs-vxworks target).
>
> libgcc/
> * config.host (powerpc-wrs-vxworks): Do not add crtbegin.o and
> crtend.o to extra_parts.
Yes, this one is ok, thanks!
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
> On 19 Nov 2021, at 21:47, Rasmus Villemoes wrote: >> >> Your error triggers on O2ggnu++0x.gch and we configure with >> --disable-libstdcxx-pch. >> > > ISTR I already tried that, but just for good measure I did it again, and > no luck: > > /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile > .../gcc-build/./gcc/xgcc -shared-libgcc -B.../gcc-build/./gcc > -nostdinc++ -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src > -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src/.libs > -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/libsupc++/.libs > -B/usr/powerpc-wrs-vxworks/bin/ -B/usr/powerpc-wrs-vxworks/lib/ -isystem > /usr/powerpc-wrs-vxworks/include -isystem > /usr/powerpc-wrs-vxworks/sys-include > --sysroot=/usr/powerpc-wrs-vxworks/sys-root > -fdebug-prefix-map=.../gcc-build/= -fdebug-prefix-map=.../gcc-src/= > -I.../gcc-src/libstdc++-v3/../libgcc > -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/powerpc-wrs-vxworks > -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include > -I.../gcc-src/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall > -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 > -fdiagnostics-show-location=once-ffunction-sections -fdata-sections > -frandom-seed=del_opant.lo -g -O2 -mstrict-align -mmultiple > -fvisibility=hidden -c -o del_opant.lo > .../gcc-src/libstdc++-v3/libsupc++/del_opant.cc > .../gcc-src/libstdc++-v3/libsupc++/new_opa.cc:28:10: fatal error: > stdint.h: No such file or directory > 28 | #include > | ^~ Ok, thanks. Another diff is we're using fixincludes for vx6 (not 7), and have a local patch setting sysroot_headers_dir in a particular fashion to handle kernel vs rtp (part of what I was intending to propagate as well). We're not using --sysroot directly. I'll check how our build sequence proceeds.
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
Hi Rasmus, > On 12 Nov 2021, at 17:35, Olivier Hainque wrote: > We have had to use for stdbool a similar trick as we had > for stdint (need to preinclude yyvals.h), which we will need to > propagate somehow. I'm not yet sure how to reconcile that with > your observations. >> In file included from >> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72, >>from .../gcc-src/libstdc++-v3/include/precompiled/stdc++.h:82: >> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/align.h:36:10: >> fatal error: stdint.h: No such file or directory >> 36 | #include // uintptr_t >> | ^~ >> compilation terminated. >> Makefile:1861: recipe for target >> 'powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch' failed >> make[5]: *** [powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 >> For the approach with an extra makefile fragment to work, that rule >> would have to fire after stmp-int-hdrs as it does now (i.e., after the >> common logic has removed stdint.h), but it must also run before we >> actually start building target libraries that depend on having a >> stdint.h - and I can't find something reasonable to make the rule a >> dependency of. I was just able to get complete build of a gcc-11 based compiler with only a couple of minor additions on top of what we already have, part of which I was planning to propagate, including the stdbool trick similar to the one for stdint. I didn't hit the error you have and we have never hit it before, which suggests there might be some significant difference between our ways to build that could help. Your error triggers on O2ggnu++0x.gch and we configure with --disable-libstdcxx-pch. Can you see if adding this to your configuration options helps on your end? Thanks in advance, Olivier
Re: [PATCH] gcc: vxworks: fix providing stdint.h header
Hi Rasmus,
We have had to use for stdbool a similar trick as we had
for stdint (need to preinclude yyvals.h), which we will need to
propagate somehow. I'm not yet sure how to reconcile that with
your observations.
Olivier
> On 12 Nov 2021, at 11:15, Rasmus Villemoes wrote:
>
> Commit bbbc05957e (Arrange to preinclude yvals.h ahead of stdint on
> VxWorks 7) breaks the build of libstdc++ for our VxWorks 5 platform.
>
> In file included from
> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72,
> from .../gcc-src/libstdc++-v3/include/precompiled/stdc++.h:82:
> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/align.h:36:10:
> fatal error: stdint.h: No such file or directory
> 36 | #include // uintptr_t
> | ^~
> compilation terminated.
> Makefile:1861: recipe for target
> 'powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
> make[5]: *** [powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
>
> The problem is that the stdint.h header does not exist (in the
> gcc/include/ directory) during the build, but is only added at "make
> install" time.
>
> For the approach with an extra makefile fragment to work, that rule
> would have to fire after stmp-int-hdrs as it does now (i.e., after the
> common logic has removed stdint.h), but it must also run before we
> actually start building target libraries that depend on having a
> stdint.h - and I can't find something reasonable to make the rule a
> dependency of.
>
> I agree with the intent of avoiding "altering the common stdint-gcc.h
> with unpleasant vxworks specific bits". The best approach I could come
> up with is adding another variant of "use_gcc_stdint", "preserve",
> meaning "leave whatever the target's extra_headers settings put inside
> gcc/include/ alone". There's no change in behaviour for any of the
> existing values "none", "wrap" or "provide".
>
> gcc/ChangeLog:
>
> * Makefile.in (stmp-int-hdrs): Only remove include/stdint.h when
> $(USE_GCC_STDINT) != "preserve".
> * config.gcc: Document new possible value of use_gcc_stdint:
> "preserve".
> * config.gcc (vxworks): Add ../vxworks/stdint.h to
> extra_headers and set use_gcc_stdint=preserve.
> * config/t-vxworks: Remove install-stdint.h rule.
> ---
>
> I have previously sent something similar to Olivier privately, hoping
> I could come up with a better/cleaner fix. But I have failed, so now
> I've taken what I had and added the necesary documentation and
> changelog bits.
>
> Better ideas are of course welcome. I thought of using "custom"
> instead of "preserve", but chose the latter since "wrap" and "provide"
> are verbs.
>
> gcc/Makefile.in | 4 +++-
> gcc/config.gcc | 11 ++-
> gcc/config/t-vxworks | 12
> 3 files changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 571e9c28e29..759982f1d7d 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -3132,7 +3132,9 @@ stmp-int-hdrs: $(STMP_FIXINC) $(T_GLIMITS_H) $(USER_H)
> fixinc_list
> chmod a+r include/$$file; \
> fi; \
> done
> - rm -f include/stdint.h
> + if [ $(USE_GCC_STDINT) != preserve ]; then \
> + rm -f include/stdint.h; \
> + fi
> if [ $(USE_GCC_STDINT) = wrap ]; then \
> rm -f include/stdint-gcc.h; \
> cp $(srcdir)/ginclude/stdint-gcc.h include/stdint-gcc.h; \
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index edd12655c4a..7a236e1a967 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -129,8 +129,9 @@
> # use_gcc_stdint If "wrap", install a version of stdint.h that
> # wraps the system's copy for hosted compilations;
> # if "provide", provide a version of systems without
> -#such a system header; otherwise "none", do not
> -#provide such a header at all.
> +#such a system header; if "preserve", keep the copy
> +#installed via the target's extra_headers; otherwise
> +#"none", do not provide such a header at all.
> #
> # extra_programs List of extra executables compiled for this target
> # machine, used when linking.
> @@ -1024,11 +1025,11 @@ case ${target} in
> tm_file="${tm_file} vxworks-stdint.h"
>
> # .. only through the yvals conditional wrapping mentioned above
> - # to abide by the VxWorks 7 expectations. The final copy is performed
> - # explicitly by a t-vxworks Makefile rule.
> + # to abide by the VxWorks 7 expectations.
>
> - use_gcc_stdint=none
> + use_gcc_stdint=preserve
> extra_headers="${extra_headers} ../../ginclude/stdint-gcc.h"
> + extra_headers="${extra_headers} ../vxworks/stdint.h"
>
> case ${enable_threads} in
> no) ;;
> diff --git a/gcc/config/t-vxworks b/gcc/config/t-vxworks
> index 5a06ebe1b87..a544bedf634 100644
> ---
Re: [i386] Fix couple of issues in large PIC model on x86-64/VxWorks
> On 8 Nov 2021, at 09:27, Eric Botcazou wrote: > >> LGTM for the generic part, no idea for VxWorks. > > Thanks. The VxWorks-specific hunk is needed to make GCC compatible with the > system compiler on this architecture (LLVM) and I have CCed Olivier. Good for me, thanks Eric!
Re: [PATCH] libstdc++: only define _GLIBCXX_HAVE_TLS for VxWorks >= 6.6
> On 8 Nov 2021, at 10:56, Rasmus Villemoes wrote: > > According to > https://gcc.gnu.org/legacy-ml/gcc-patches/2008-03/msg01698.html, the > TLS support, including the __tls_lookup function, was added to VxWorks > in 6.6. > > It certainly doesn't exist on our VxWorks 5 platform, but the fallback > code in eh_globals.cc using __gthread_key_create() etc. used to work > just fine. > > libstdc++-v3/ChangeLog: > > * config/os/vxworks/os_defines.h (_GLIBCXX_HAVE_TLS): Only > define for VxWorks >= 6.6. Good for me, thanks Rasmus. Cheers, Olivier
Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7
> On 5 Nov 2021, at 15:12, Rasmus Villemoes wrote: > >> Yes, I think so. The builds you do used to work before >> the change that introduced the ifdef, > > Well, apart from all the other fixups, some of which are not > upstreamable, that I also need to apply :) Sure. My comment was only meant as positioning wrt the branch commit policy. The issue you address can be seen as triggering a regression on its own, regardless of other changes possibly causing issues as well, so a safe fix for it is eligible to the branch. > IIUC, and the adjustment >> you propose is close to being in the "obvious" category. > > Indeed. I'll cherry-pick it into releases/gcc-11. > > Have you had a chance to look at the other four patches I've sent > recently? They are also vxworks-only, and shouldn't be very controversial. Not yet, but I'm planning to get there RSN. I have been in delivery preparation mode on another project this week and we had to finalize a move to gcc-11 for non vxworks ports we have in-house first. VxWorks ports are next in line, starting next week. We have quite a few changes to push (wrt shared libs in particular), and I'll take the opportunity to incorporate your changes in my local testing cycles (pretty heavy for vx7, and some for vx6). We happen to also have a few fixincludes hunks around. Some of them have been there for years now and I thought would be nice to propagate at some point. Do you use it?
Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7
> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote: > Applied to master and pushed - hope I've done it right. AFAICS, yes. > How about the gcc-11 branch, can it be applied there as well, Yes, I think so. The builds you do used to work before the change that introduced the ifdef, IIUC, and the adjustment you propose is close to being in the "obvious" category. Very small, clearly vxworks only and in line with every other use of that macro. > and if so, > should I do a "git cherry-pick -x" and push it to that branch? > From > looking at the git history it seems to be the way things are done. That's my understanding as well. Thanks, Olivier
Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7
Hi Rasmus, > On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote: > > The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h). > Thus we need to test its value, not its definedness. > > Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6). > > gcc/ChangeLog: > > * config/vx-common.h: Test value of TARGET_VXWORKS7 rather > than definedness. Indeed. Ok, thanks!
Fix size of static array in gcc.dg/vect/vect-simd-20.c
Hello, This fixes the definition of the "p" static array in gcc.dg/vect/vect-simd-20.c to accommodate the number of strides performed by foo() for s == 78, which will be 129 and not 128 since 1 / 78 > 128. This fixes a failure of the test we first observed in-house on a x86_64-elf run, where the first call to foo() was clobbering part of a static object we provide to __register_frame_info, causing an abort() from __deregister_frame_info at termination time. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-11-02 Olivier Hainque testsuite/ * gcc.dg/vect/vect-simd-20.c: Fix size of p[] to accommodate the number of strides performed by foo() for s == 78. simd-20.diff Description: Binary data
Re: [FYI] zero-call-used-regs attr for ada
> On 15 Sep 2021, at 18:45, Alexandre Oliva wrote: > > On Sep 15, 2021, Alexandre Oliva wrote: > >> Regstrapped on x86_64-linux-gnu. Patch pre-approved by Olivier Hainque. > > Uhh, actually, Olivier had only seen and approved these changes: > >> for gcc/ada/ChangeLog > >> * gcc-interface/utils.c: Include opts.h. >> (handle_zero_call_used_regs_attribute): New. >> (gnat_internal_attribute_table): Add zero_call_used_regs. > > The trivial testcase went in without anyone's approval. Oops. > >> for gcc/testsuite/ChangeLog > >> * gnat.dg/zcur_attr.adb, gnat.dg/zcur_attr.ads: New. > > Sorry about the slip. It's trivial enough that I suppose it can fit the > "obviously correct" rule. Please let me know in case you disagree. No problem at all Alex. Thanks for your work on this!
Re: restore EH on x86-vx7r2
> On 4 May 2021, at 04:45, Alexandre Oliva wrote: > > > x86-vx7r2 needs svr4_dbx_register_map, but the default in i386/i386.h > was dbx_register_map, partially swapping ebp and esp in unwind info. > > i386/vxworks.h had a correct overrider, but it was conditional for > vxworks < 7. This patch reenables the overrider unconditionally. > > Tested on x86_64-linux-gnu with a cross to x86-vx7r2. Ok to install? Yes, good for me, thanks! > for gcc/ChangeLog > > * config/i386/vxworks.h (DBX_REGISTER_NUMBER): Make it > unconditional.
Fix for PR target/99660 - vxworksae/mils build failure from missing VX_CPU_PREFIX
Hello, This fixes an oversight which causes make all-gcc to fail for --target=*vxworksae or vxworksmils, a regression introduced by the recent VxWorks7 related updates. Thanks @Martin for opening the PR. Both AE and MILS variants resort to a common config/vxworksae.h, which misses a definition of VX_CPU_PREFIX expected by port specific headers. The change just provides the missing definition. Tested by checking that I could reproduce the failure for powerpc-wrs-vxworksae, then that all-gcc passes after the patch for powerpc-wrs-vxworksae, x86-wrs-vxworksae and powerpc-wrs-vxworksmils. With Kind Regards, Olivier 2021-03-19 Olivier Hainque gcc/ PR target/99660 * config/config/vxworksae.h (VX_CPU_PREFIX): Define. diff --git a/gcc/config/vxworksae.h b/gcc/config/vxworksae.h index 0f9b55357892..86d1923b718f 100644 --- a/gcc/config/vxworksae.h +++ b/gcc/config/vxworksae.h @@ -64,6 +64,10 @@ along with GCC; see the file COPYING3. If not see /* Both kernels and RTPs have the facilities required by this macro. */ #define TARGET_POSIX_IO +/* The AE/653 system headers all predate the introduction of _VX_ prefixes + ahead of CPU families of macros. */ +#define VX_CPU_PREFIX "" + /* A VxWorks 653 implementation of TARGET_OS_CPP_BUILTINS. */ #define VXWORKS_OS_CPP_BUILTINS() \ do\
Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h
Hi Alex, > On 14 Jan 2021, at 22:13, Alexandre Oliva wrote: > > Hello, Olivier, > > On Dec 18, 2020, Olivier Hainque wrote: > >> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html >> (copied below for convenience), please ? > > I think defining alloca as a macro in analyzer-alloca.h might conflict > with system headers included before or after analyzer-alloca.h > > Say, if a system header #defines alloca(n), GCC might warn when > encountering a different #define in analyzer-alloca.h, included later. > > OTOH, if analyzer-alloca.h is included first, then a later system header > that attempts to declare alloca as a function could be macro-substituted > into declaring __builtin_alloca, which probably wouldn't end well. > > While the alloca macro would render other changes from alloca to > __builtin_alloca unnecessary, there's such an explicit change in the > patch. > > If it were up to me, I'd rather use __builtin_alloca explicitly all > over. I think we already do that in several other tests, for similar > reasons (that some target systems don't have alloca.h or alloca) > > Would you mind if I submitted an alternate patch to do so? Not at all, thanks for your feedback and for proposing an alternative! Olivier
Re: Add missing vxworks filters to lib/target-supports.exp functions
> On 29 Dec 2020, at 11:26, Richard Sandiford via Gcc-patches
> wrote:
>
> Alexandre Oliva writes:
>> Explicitly disable some vxworks-missing features in the testsuite, that
>> the current feature tests detect as present.
>>
>> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
>> Ok to install?
>>
>>
>> from Olivier Hainque
>> for gcc/testsuite/ChangeLog
>>
>> * lib/target-supports.exp (check_weak_available,
>> check_fork_available, check_effective_target_lto,
>> check_effective_target_mempcpy): Add vxworks filters.
>
> This comes under Olivier's maintainership, but LGTM.
(With a bit of delay after the end-of-year break and
backlog + activity recovery ...)
Thanks for your input on this Richard.
We're discussing possible ways to improve symbol availability
detection, so we could get rid of the bits like:
>> proc check_effective_target_mempcpy {} {
>> +if { [istarget *-*-vxworks*] } {
>> +# VxWorks doesn't have mempcpy but our way to test fails
>> +# to detect as we're doing partial links for kernel modules.
>> +return 0
>> + }
>> return [check_function_available "mempcpy"]
>> }
Olivier
Re: robustify vxworks glimits.h overriding
> On 5 Jan 2021, at 08:51, Alexandre Oliva wrote: > > > The glimits.h overriding used in gcc/config/t-vxworks was fragile: the > intermediate file would already be there in a rebuild, and so the > adjustments would not be made, so the generated limits.h would miss > them, causing limits-width-[12] tests to fail on that target. > > While changing it, I also replaced the modern $(cmd) shell syntax with > the more portable `cmd` construct. > > Regstrapped on x86_64-linux-gnu, also tested on x-arm-wrs-vxworks7r2. > I'm checking it in unless there are objections in the next 24 hours. > > > for gcc/ChangeLog > > * Makefile.in (T_GLIMITS_H): New. > (stmp-int-hdrs): Depend on it, use it. > * config/t-vxworks (T_GLIMITS_H): Override it. > (vxw-glimits.h): New. Good for me, VxWorks' wise. Thanks!
