[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182
John Baldwin changed:
What|Removed |Added
CC||jhb at FreeBSD dot org
--- Comment #12 from John Baldwin ---
(In reply to Wilco from comment #9)
> It should be easy to add the
>
> #if __has_include()
>
> back in if that is what worked in the past (or use __gnu_linux__).
>
> Should there be a #elif that includes a different header for FreeBSD? Does
> it support the ABI for ifuncs?
>
> How is the similar issue resolved for libgcc/config/aarch64/lse-init.c?
Mark pointed me here. I am not the primary maintainer of aarch64 support in
FreeBSD, but I am familiar with some of the details. From what I can tell,
lse-init.c doesn't handle FreeBSD either. FreeBSD does have ifunc support for
aarch64, and its ABI is compatible with what cpuinfo.c expects. On
FreeBSD/aarch64, ifunc resolvers are passed the value of AT_HWCAP in the first
argument (ored with _IFUNC_ARG_HWCAP), and a pointer to an __ifunc_arg_t object
with the same layout as that used in cpuinfo.c as the second argument.
The various HWCAP_* constants are defined on FreeBSD in which
is included by other headers such as and .
For lse-init.c, FreeBSD's defines a function elf_aux_info which is
similar in spirit to __getauxval() though the calling convention is slightly
different, I think the equivalent would be:
#include
#include
static void __attribute__((constructor (90)))
init_have_lse_atomics (void)
{
unsigned long hwcap;
if (elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)) == 0)
__arch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
}
For cpuinfo.c, I think the main thing you'd have to deal with to support
FreeBSD is that you can't assume a fixed value for AT_* (or at least not the
same value used on Linux), and the calls to __getauxval would use elf_aux_info
instead.
If it would be helpful I could come up with an initial patch for FreeBSD
support, but I might need a pointer to a test if you have one for both the
lse-init.c bits and cpuinfo.c bits. I'll also happily defer to you on how you
would prefer to handle the AT_HWCAP* values being different on different
systems.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #11 from Mark Millard --- (In reply to Mark Millard from comment #10) > > How is the similar issue resolved for libgcc/config/aarch64/lse-init.c? Looks to me like the lang/gcc* and devel/freebsd-gcc* ports never had identified this area as something needing FreeBSD specifics. The: #ifdef __gnu_linux__ . . . #endif /* __gnu_linux__ */ structure avoided having init_have_lse_atomics or its independent AT_HWCAP 16 definition involved so it was not made obvious by a build failure historically, nor by making __getauxval(16) calls that would be odd to FreeBSD 's code for the context but possibly hard to notice. (Note: devel/freebsd-gcc* has not progressed beyond gcc15 yet.)
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #10 from Mark Millard --- (In reply to Wilco from comment #9) > It should be easy to add the > > #if __has_include() > > back in if that is what worked in the past (or use __gnu_linux__). > > . . . As for going in that direction . . . It was also the use of #ifndef . . . #endif that was in place to allow overrides of the gcc16+ defaults in the original code structure. Now the linux API values are AT_HWCAP* are hard coded without allowing for such. > Should there be a #elif that includes a different header for FreeBSD? That is getting into specifics that the actual maintainer folks should be answering for anything done that is FreeBSD OS specific directly in the gcc code. > Does it support the ABI for ifuncs? The FreeBSD OS does use ifuncs. But I'm not familiar with the details. > How is the similar issue resolved for libgcc/config/aarch64/lse-init.c? I'm not familiar with that. I only had looked into the known build breakage as an independent set of eyes. I'm not a maintainer of any lang/gcc* or freebsd-gcc* ports or anything associated with the system clang/clang++ or devel/llvm* ports either. So I'll have to look around and to get a clue.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #9 from Wilco --- It should be easy to add the #if __has_include() back in if that is what worked in the past (or use __gnu_linux__). Should there be a #elif that includes a different header for FreeBSD? Does it support the ABI for ifuncs? How is the similar issue resolved for libgcc/config/aarch64/lse-init.c?
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #8 from Mark Millard --- A note on the FreeBSD explorations on the issue that are visible in the FreeBSD port's 294062 bugzilla-entry. : Not knowing what gcc16+ would do for the overall issue, reverting to what is basically the historical technique for lang/gcc15 and before is what has been explored relative to checking build-ability. That included reverting the relevant aarch64 cpuinfo.c code structure to the old style. With that I was able to build --and so know that no other issues prevented building. But it does not necessarily make for the way gcc would want to handle the issues associated with aarch64's cpuinfo.c for gcc16 or later long term. It is just a workaround for now as far as I'm concerned. (But I do not maintain any lang/gcc* ports or devel/freebsd-gcc* ports.)
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #7 from Mark Millard --- (In reply to Alice Carlotti from comment #5) > Based on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294062#c5, it > looks like there's also an issue with indirectly including > defines for HWCAP_ that are numerically equivalent but spelled differently. > So I think we'll need to do one of: > - make the definitions conditional, > - not include , or > - use different names for the HWCAP_* macros to avoid the clash. > > The last option looks like the cleanest one to me. For names that are not names for allowing ABI history/choice based value variations, using names that are obviously GCC specific, and so unlikely to get #define conflicts with other contexts, would seem like a good idea to me. Relative to FreeBSD code, for example, these are names with textual definitions that would have no reason to need to track FreeBSD naming or the values FreeBSD code has in its #defines for its names --or to track how those values are expressed in the FreeBSD code.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #6 from Mark Millard --- (In reply to Alice Carlotti from comment #4) > Is it just the four getauxval arguments that differ? That is, are the bit > assignments withing each HWCAP the same? > > We should probably condition the AT_HWCAP* definitions upon the target OS. > Checking a header file first might work in practice, but it feels less > robust in case the header file is missing some of the definitions. The 4 are what I'm familiar with and they are ABI history/choice values rather than descriptions of aarch64 internal bit assignments or the like. I would not necessarily recognize another name that was also an example of ABI history/choice value but there may well not be other such in this context. What range of target ABI's would be covered in the conditioning? I've submitted for the FreeBSD OS context --but overall it is just an example of the more overall issue. Also, future ABI additions here with new names will repeat for each such distinct ABI. I'm not one of the folks that actually maintains the FreeBSD ports' lang/gcc1[67] or later. But I sometimes (rarely) have helped identify details of why/how lang/gcc* builds broke when extra eyes were needed. Thus my input to alternative techniques for handling the varying ABI value definitions is likely to be rather limited, even from a FreeBSD OS ports specific viewpoint. FreeBSD does have additional devel/freebsd-gcc* ports set up for testing building FreeBSD itself with gcc in its CI context. Those have not started using gcc16+ yet (gcc15 is the most recent) --and so have not yet hit the issue but at some point gcc16 will start to be used.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #5 from Alice Carlotti --- Based on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294062#c5, it looks like there's also an issue with indirectly including defines for HWCAP_ that are numerically equivalent but spelled differently. So I think we'll need to do one of: - make the definitions conditional, - not include , or - use different names for the HWCAP_* macros to avoid the clash. The last option looks like the cleanest one to me.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 Alice Carlotti changed: What|Removed |Added CC||acarlotti at gcc dot gnu.org --- Comment #4 from Alice Carlotti --- Is it just the four getauxval arguments that differ? That is, are the bit assignments withing each HWCAP the same? We should probably condition the AT_HWCAP* definitions upon the target OS. Checking a header file first might work in practice, but it feels less robust in case the header file is missing some of the definitions.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #3 from Mark Millard --- (In reply to Alex Coplan from comment #2) > I suppose this is r16-2683-ga6bb6934a491015c4d3f08763455d86ccfb3bcbe ? Yes, that change hard coded linux ABI values for AT_HWCAP, AT_SWCAP2, AT_HWCAP3, and AT_HWCAP4 . For the FreeBSD OS: AT_HWCAP, AT_HWCAP3, and AT_HWCAP4 differ in its ABI. If there are any other of the names that might be of OS ABI definitions, they would also be at potential issue for some operating systems.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org, ||wdijkstr at arm dot com --- Comment #2 from Alex Coplan --- I suppose this is r16-2683-ga6bb6934a491015c4d3f08763455d86ccfb3bcbe ?
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) Besides AT_HWCAP, AT_HWCAP3 and AT_HWCAP4 have different FreeBSD ABI values than gcc16/linux. AT_HWCAP2 happens to be a match.
[Bug target/125182] [16/17 Regression] libgcc/config/aarch64/cpuinfo.c now presumes linux ABI's AT_HWCAP, other ABI's need not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125182 Drea Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |16.2 Summary|libgcc/config/aarch64/cpuin |[16/17 Regression] |fo.c now presumes linux |libgcc/config/aarch64/cpuin |ABI's AT_HWCAP, other ABI's |fo.c now presumes linux |need not match |ABI's AT_HWCAP, other ABI's ||need not match
