Re: Dynamic linking is go (again)
Izumi Tsutsui <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.dreamcast,gmane.os.netbsd.ports.sh3 |
|---|---|
| Message-ID | <[email protected]> |
In article <[email protected]> [email protected] wrote: > > I notice that ld/emulparams/shelf_nbsd.sh in binutils-2.13.2.1 > > sets wrong default ENTRY point and it causes the problem. > > If that was the case, then how come I can link working binaries with > my native toolchain, which is also based on binutils-2.13.2.1? I have not tracked it yet, but if -nostdlib is not specified on linking binaries, "-e __start" is passed to ld by gcc (which is specified as NETBSD_LINK_SPEC_ELF in gcc/config/netbsd-elf.h) so it works. The problem only happens when binaries are built with USETOOLS=yes (i.e. -nostdlib is specified). > Anyway, looking at the crt0.c of i386_elf, they seem to define both > _start and __start to the same address so that the linker can choose > either, and then call the high level entry function "___start". Maybe > we should do the same? Then there shouldn't be a compatibility issue > at least. In sh3_elf/crt0.c, __start and _start are different, but __start only push r9 and r8 into stack for args of (Obj_Entry *) and (struct ps_strings *). (actually ENTRY is machine dependent value in gcc) I'm not familiar with startup code, but if these args are only used by PIC binaries, I guess there is no compatibility problem. --- Izumi Tsutsui [email protected]