On Tue, 2014-12-02 at 11:22 +0100, Richard Biener wrote: > On Mon, Dec 1, 2014 at 11:48 PM, Oleg Endo <oleg.e...@t-online.de> wrote: > > On Mon, 2014-12-01 at 12:09 +0100, Richard Biener wrote: > >> On Mon, Dec 1, 2014 at 8:21 AM, Oleg Endo <oleg.e...@t-online.de> wrote: > >> > Hi, > >> > > >> > When running the testsuite on a sh-elf configuration, some test cases > >> > fail due to multiple definitions of the function '_init'. This is > >> > because on sh-elf every function is automatically prefixed with a '_' > >> > char. When defining a C function 'init' in some code, the actual name > >> > becomes '_init' and this conflicts with the _init function in libgcc > >> > (crti.S). While the behavior of adding the '_' prefix is debatable, the > >> > testsuite failures can be easily fixed by the attached patch. > >> > Is this OK for trunk? > >> > >> The testcases are certainly valid C testcases and thus sh-elf is buggy > >> here. As '_init' is a reserved identifier it shouldn't mangle 'init' as > >> '_init'. > >> > >> Do you never run into "real" applications naming a function 'init'? > > > > Looking for USER_LABEL_PREFIX shows that the '_' prefix mangling scheme > > is being used by quite some targets/configs. So it's not just sh-elf, > > but other bare metal configs and their ABIs, where 'init' gets mangled > > to '_init' and there's a '.global _init' in libgcc. Yes, it does break > > valid standard C code 'void init (void)', but it's been doing that for > > quite a while. > > Oh, and I wonder why the global init isn't then __init (two underscores), > as obviously on those targets symbols with _ prefix are not in the > implementation namespace.
My guess: Because it's written in asm, and there it's not known whether a _ prefix should be used or not. It's an ABI/convention. BTW it's not only the init function, but potentially several others. E.g. newlib/libc/sys/sh/crt0.S refers to other symbols such as _stack, _edata, _end, _main, _exit. Thus, having something global named "stack" in a C program will potentially clash. So while we maybe could use USER_LABEL_PREFIX in libgcc to add the prefix, there would still be issues with things defined in e.g. newlib or the linker script. For bare metal configs / programs having some additional reserved/prohibited names is not a big deal, as there are often other restrictions which are even worse. I guess the issue isn't that bad. Out of all the gcc test cases, I hit only 4. In the context of gcc sim testing, one option could be to use a special toolchain config, which does not do the _ prefixing. However, there's no such configure option and the only way to change it is to change the USER_LABEL_PREFIX definition, or add a subtarget which doesn't prefix _. Another option could be adding something to the global configure stuff so that the option -fno-leading-underscore can be turned on by default for the resulting compiler. Cheers, Oleg
