Re: GCC 3.2 on the NetBSD/i386 port
Joel Baker <lucifer@lightbearer.com> writes:
> I believe they're from the dynamic linker (ld.elf_so), in this case.
That would indicate that the dynamic linker does not know what .hidden
symbols are, which is a problem on its own.
> > We have to consider __dso_handle and __cxa_atexit separately. For
> > __dso_handle, can you tell whether HAVE_GAS_HIDDEN is defined?
>
> root@thenet:/tmp/Build/gcc-3.2-HOLD/gcc-3.2-3.2ds0/src# find . -type f | xargs grep HAVE_GAS_HIDDEN
> ...
> ./gcc/config/cris/cris.h:#define HAVE_GAS_HIDDEN 1
>
> (All of the others are .in files for autoconf, ChangeLog entries, or
> #ifdef macros in various .c files)
Correct - and this is how they would be defined for your system:
configure runs, determines whether or not your assembler supports
hidden symbols, and then writes that information into gcc/auto-host.h
of the build directory. Thus, looking at the sources won't help that
much (I could have done that myself).
> I will note that the __dso_handle references go away if __cxa_atexit is not
> enabled.
Correct - __dso_handle is only used together with __cxa_atexit. So if
you decide not to use __cxa_atexit, you don't need to worry about
__dso_handle. If you get a definition for __cxa_atexit, you'll have to
come back and study the issue of .hidden symbols.
> grep -i cxa /usr/src/lib/libc/stdlib/atexit.* returns nothing; I'm not sure
> where else I would look, but that's not promising.
That might well be the case - so far, only Linux provides that
function, and perhaps HP-UX.
> I can file a feature
> request on it, but it won't show up in the stable tree until at least 1.6++
> (1.6 is at RC3 right now). Is there a simple spec, URL, or similar that I
> can point at when filing the request?
It's in the C++ ABI, at
http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor
> Is this something that can be autoconfed or otherwise detected?
This is tricky. You can try to come up with a test, but you need to test:
- whether as/ld support .hidden symbols,
- whether the dynamic linker correctly implements them,
- whether the C library provides __cxa_atexit and __cxa_finalize.
In gcc, since this is information about the target system (for which
you can't run programs), such information is usually hard-coded in the
machine descriptions.
For __cxa_atexit, it used to be the case that end-users would need to
add -fuse-cxa-atexit at g++ invocation time. The configure option was
added only recently, and nobody has attempted to provide per-target
defaults.
Regards,
Martin
Reply to: