dl_iterate_phdr support

dl_iterate_phdr support

[John Marino]

FreeBSD and openBSD have had dl_iterate_phdr support in their runtime 
linker since 2007.  NetBSD-current added it in late 2010 and I just 
patched Dragonfly's RTLD to support it as well, which means the feature 
is fully supported by *BSD.

I was a bit surprised when I checked the gcc configure log and saw the 
check for dl_iterate_phdr came back "unknown" so I checked the 
gcc/configure script.

Basically the logic in the configure script is this:
If target <> solaris2 then gcc_cv_target_dl_iterate_phdr=unknown

Basically that means this feature is only possibly used by gcc when 
Solaris is the target.

Is this intentional?
Why are not Linux and BSD targets being tested?

Is the problem only a deficient configure script, or is there missing 
support within gcc itself?  I was told on the gcc-help mail list that 
using dl_iterate_phdr was a more efficient method of propagating 
exceptions and I'd like GNAT to take advantage of that.

Thanks,
John

Re: dl_iterate_phdr support

[Ian Lance Taylor]

John Marino <gnugcc@marino.st> writes:

> FreeBSD and openBSD have had dl_iterate_phdr support in their runtime
> linker since 2007.  NetBSD-current added it in late 2010 and I just
> patched Dragonfly's RTLD to support it as well, which means the
> feature is fully supported by *BSD.
>
> I was a bit surprised when I checked the gcc configure log and saw the
> check for dl_iterate_phdr came back "unknown" so I checked the
> gcc/configure script.
>
> Basically the logic in the configure script is this:
> If target <> solaris2 then gcc_cv_target_dl_iterate_phdr=unknown
>
> Basically that means this feature is only possibly used by gcc when
> Solaris is the target.
>
> Is this intentional?
> Why are not Linux and BSD targets being tested?
>
> Is the problem only a deficient configure script, or is there missing
> support within gcc itself?  I was told on the gcc-help mail list that
> using dl_iterate_phdr was a more efficient method of propagating
> exceptions and I'd like GNAT to take advantage of that.

The test in gcc/configure.ac is unfortunately rather misleading.  That
result of that test is currently only used on Solaris.

The relevant code can be found in two places: gcc/unwind-dw2-fde-glibc.c
and gcc/crtstuff.c.  In unwind-dw2-fde-glibc.c it looks like this:

#if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
    && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
	|| (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG)))
# define USE_PT_GNU_EH_FRAME
#endif

#if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
    && defined(__FreeBSD__) && __FreeBSD__ >= 7
# define ElfW __ElfN
# define USE_PT_GNU_EH_FRAME
#endif

#if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
    && defined(TARGET_DL_ITERATE_PHDR) \
    && defined(__sun__) && defined(__svr4__)
# define USE_PT_GNU_EH_FRAME
#endif

The idea is that USE_PT_GNU_EH_FRAME should be defined on any system for
which the linker supports --eh-frame-hdr and the library supports
dl_iterate_phdr.  As you can see, the test is being done based on the
library version.  It is done this way because when gcc is being used to
build the C library, particularly when building a cross-compiler, there
is no way to test the features that the C library supports.

Ian

Re: dl_iterate_phdr support

[John Marino]

On 2/14/2011 6:10 AM, Ian Lance Taylor wrote:
>
> The test in gcc/configure.ac is unfortunately rather misleading.  That
> result of that test is currently only used on Solaris.
>
> The relevant code can be found in two places: gcc/unwind-dw2-fde-glibc.c
> and gcc/crtstuff.c.  In unwind-dw2-fde-glibc.c it looks like this:
>
> #if !defined(inhibit_libc)&&  defined(HAVE_LD_EH_FRAME_HDR) \
>      &&  (__GLIBC__>  2 || (__GLIBC__ == 2&&  __GLIBC_MINOR__>  2) \
> 	|| (__GLIBC__ == 2&&  __GLIBC_MINOR__ == 2&&  defined(DT_CONFIG)))
> # define USE_PT_GNU_EH_FRAME
> #endif
>
> #if !defined(inhibit_libc)&&  defined(HAVE_LD_EH_FRAME_HDR) \
>      &&  defined(__FreeBSD__)&&  __FreeBSD__>= 7
> # define ElfW __ElfN
> # define USE_PT_GNU_EH_FRAME
> #endif
>
> #if !defined(inhibit_libc)&&  defined(HAVE_LD_EH_FRAME_HDR) \
>      &&  defined(TARGET_DL_ITERATE_PHDR) \
>      &&  defined(__sun__)&&  defined(__svr4__)
> # define USE_PT_GNU_EH_FRAME
> #endif
>
> The idea is that USE_PT_GNU_EH_FRAME should be defined on any system for
> which the linker supports --eh-frame-hdr and the library supports
> dl_iterate_phdr.  As you can see, the test is being done based on the
> library version.  It is done this way because when gcc is being used to
> build the C library, particularly when building a cross-compiler, there
> is no way to test the features that the C library supports.
>
> Ian


Thanks Ian.  If I understand the code in those two files correctly, only 
Solaris, Linux, and FreeBSD is being considered.  If I want to use this 
on Dragonfly 2.9+, NetBSD 5.99+, and/or OpenBSD, I'll have to patch 
these files will the appropriate code.

My FSF copyright assignment papers should have arrived to FSF by now, so 
I will pass along these patches with the others.

For the others, I am waiting for gcc 4.6 to get branched.  Would a 
configuration patch to these files make it into trunk before it's 
branched?  If you take the words "regression fixes and documentation 
only" literally then the answer would be no, it has to wait for 4.7 stage 1.

Regards,
John

Re: dl_iterate_phdr support

[Ian Lance Taylor]

John Marino <gnugcc@marino.st> writes:

> Thanks Ian.  If I understand the code in those two files correctly,
> only Solaris, Linux, and FreeBSD is being considered.  If I want to
> use this on Dragonfly 2.9+, NetBSD 5.99+, and/or OpenBSD, I'll have to
> patch these files will the appropriate code.

Right, or even better generalize the test somehow.

> For the others, I am waiting for gcc 4.6 to get branched.  Would a
> configuration patch to these files make it into trunk before it's
> branched?  If you take the words "regression fixes and documentation
> only" literally then the answer would be no, it has to wait for 4.7
> stage 1.

Generally target specific patches get additional leeway even in stage 4.
That would be a question for the *BSD maintainers.

Ian