> On Mon, 18 Nov 2019, Rainer Orth wrote: > > > So you certainly need such an effective-target test and, at least as > > importantly, a configure test at build time that you can assemble, link, > > and run a test correctly before enabling it in gcc. Just > > unconditionally dropping it into elfos.h is wrong. > > Tests in gcc/configure for linking or running something are a bad idea > because they don't work for cross compilation (at all, for run tests; when > bootstrapping and target libc hasn't been built, for link tests). > > I'd assume any bare-metal ELF target used with GNU binutils *could* > support symbol versioning if it happens to be used with an RTOS that has a > dynamic linker with that support, even if in fact it's much more likely to > be used with static linking only. So I don't think the information is > available when GCC is built, beyond (a) it's definitely not supported for > non-ELF targets (as determined through by a list of targets such as in > config/elf.m4:ACX_ELF_TARGET_IFELSE) and (b) there might be a list of ELF > OS targets known to lack support.
Current patch makes GCC to accept symver attribute on all ELF targets and simply output .symver directive into the assembly file hoping for the best. I hope that is acceptable since user will be informed by assembler that symver is not supported. For testsuite we however needs tests to not fail when .symver is not accepted by assembler that can probably by tested by the dg-require infrastructure... It is not perfect solution but also not much worse than what we do elsewhere... Honza
