for __do_global_ctors_aux() and __do_global_dtors_aux(),
to fix building with gcc3 -O3.
Discussed with Matt Thomas & Christos Zoulas, and tested on alpha & i386.
_eprol@GOTPCREL, it resolved it internally as a PC-relative instruction,
getting garbage, since the needed value is in the GOT. Add a CPP hook
to export it explicitly, this makes it work. Only active on amd64. XXX
empty for others. x86_64 (and s390, which we do not have) have .eh_frame
as a read-only section, so __EH_FRAME_BEGIN__ and the register/deregister
functions must take a const foo *.
This also fixes an ICE in gcc 3.3.1 (see gcc PR #9552)
Previously dlsym resolved to the version in crt0.o or libc which would
mean that the caller's shared object couldn't be determined correctly
using __builtin_return_address(0).
Mainly from FreeBSD, but adapted by me. Benefits of this solutions are:
- backward comptibility maintained
- existing broken binaries are fixed with a new ld.elf_so
- __mainprog_obj can be removed from crt0.o
- we do the same thing as FreeBSD
Fixes PR 22067.
OKed by Jason and Christos.
replaced mostly with .IMPSRC, so add .c wrappers for variant .o names
* any machine with a shared crt0.c that also uses common_elf (I didn't see
any) will now need a reachover wrapper in .CURDIR a la crtbeginS.c
this should fix the build breakage
and .fini sections, respectively (same as the {init,fini}_fallthru
stubs).
This is needed on PowerPC, where otherwise the linker would be unhappy
with the relocation records for the fallthru stubs when building a
shared library.
things like the .note.netbsd.ident section are provided by crti/crtn.
crti/crtn also provide the _init() and _fini() routines.
crtbegin/crtend now only provide support for ctors/dtors. This paves
the way to using the "crtstuff" provided with GCC (when we upgrade to
GCC 3.3), which provides, among other things, much better C++/Java
exception handling.
SH-5, meet NetBSD.
Let's hope this is the start of a long and fruitful relationship. :-)
This code, funded by Wasabi Systems, adds initial support for the
Hitachi SuperH(tm) SH-5 cpu architecture to NetBSD.
At the present time, NetBSD/evbsh5 only runs on a SH-5 core simulator
which has no simulated devices other than a simple console. However, it
is good enough to get to the "root device: " prompt.
Device driver support for Real SH-5 Hardware is in place, particularly for
supporting the up-coming Cayman evaluation board, and should be quite
easy to get running when the hardware is available.
There is no in-tree toolchain for this port at this time. Gcc-current has
rudimentary SH-5 support but it is known to be buggy. A working toolchain
was obtained from SuperH to facilitate this port. Gcc-current will be
fixed in due course.
The SH-5 architecture is fully 64-bit capable, although NetBSD/evbsh5 has
currently only been tested in 32-bit mode. It is bi-endian, via a boot-
time option and it also has an "SHcompact" mode in which it will execute
SH-[34] user-land instructions.
For more information on the SH-5, see www.superh.com. Suffice to say it
is *not* just another respin of the SH-[34].
skrll