[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] '-e' parameter in gcc



Hi,

On tiistai 25 tammikuu 2011, Vincent Rivière wrote:
> Miro Kropáček wrote:
> > m68k-atari-mint-gcc -nostdlib -e main conftest.c
> > /home/mikro/gnu-tools/lib/gcc/m68k-atari-mint/4.5.1/../../../../m68k-at
> > ari-mint/bin/ld: warning: cannot find entry symbol main; defaulting to
> > 000000e4 /tmp/cc4HfuQ9.o:/tmp/cc4HfuQ9.o:(.text+0x6): undefined
> > reference to `___main'
> 
> There are 2 differences between Linux and MiNT, and both are related to
> ELF vs a.out.
> 
> 1) cannot find entry symbol main
> Traditionally, on a.out targets, the public C symbols are prefixed by
> '_'. It is some kind of namespace, to differentiate function names and
> register names which could have the same name.
> Also traditionally, on ELF targets, the public C symbols are not
> prefixed.
> 
> For your information, the preprocessor automatically defines
> __USER_LABEL_PREFIX__ to the character used as prefix for public C
> functions on the current target ( _ or nothing).
> 
> So Eero is right, to get rid of the first warning you have to write "-e
> _main" on MiNT.

Any idea how common this kind of stuff is in configure scripts
(is it less effort to fix it in every configure script or add in GCC
the prefix for symbols given with "-e")?


> 2) Calling code before main (constructors of global C++ variables and GCC
> extensions)
> On a.out targets, GCC silently inserts a call to __main() at the very
> beginning of the user's main(). That function is implemented inside
> -lgcc. Of course, as other functions, the public symbol is prefixed to
> an additional underscore, so the undefined symbol is ___main with 3
> underscores. On ELF targets, things are more sophisticated. Especially,
> the startup code is split into several object files. crtbegin.o is
> linked before the user's objects, and crtend.o is linked at the end. One
> of the jobs of crtbegin.o is to call the constructors, there is no need
> for the __main() hack.
> 
> So what happens ?
> On Linux, "gcc -nostdlib conftest.c -e main" do exactly what you think.
> The final executable contains only the main() function from conftest.c.
> But on MiNT (a.out), you also get an undefined reference to __main
> (inserted by GCC at the beginning of main()), and it can't be resolved
> by libgcc because of -nostdlib !
> 
> What to do ?
> 
> A) Add -lgcc -lc -lgcc to the end of the link command line. Two times
> -lgcc due to circular dependencies. But this will fail if either libgcc
> or libc is missing on your system.
>
> B) In conftest.c, name your function differently from main, for example
> main2. Then do: "m68k-atari-mint-gcc conftest.c -nostdlib -e _main2"
> This will work as expected, since GCC adds a call to __main() only in the
> very special case of a function named main().

C) give GCC object file containing:
	__main() {}
?
 
> Back to the real world:
> You're damned because Linux people don't care about things other than
> ELF. However, xBSD still use a.out and the same issues would appear.

In case they have larger community & more toolchain maintainers, maybe
this could be filed to their bug tracker?  (in hopes that they fix the a.out
issue ;-))


	- Eero