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. > I didn't mean to open a can of worms because of 4 test cases showing up > in sh-elf sim tests. From what I can see, those 4 cases would also pop > up for other configs, not only sh-elf. Anyway, the function names in > those test cases don't matter at all, do they? No, but it looks like papering over a problem. After all we could have a valid testcase checking for exactly this situation - that a C function named 'init' works fine. Joseph may have more experience with how targets should setup USER_LABEL_PREFIX to avoid this situation. Richard. > Cheers, > Oleg >
