This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: R_386_32 relocations with sym-value=0 ?
Hi!
> I think the unwind routines can be found both in libgcc and in glibc.
> However, I suspect they will only be in libgcc if gcc believes that the
> linker supports the --eh-frame-hdr option.
>
> Certainly the best way is to use a linker which supports --eh-frame-hdr
> and use a gcc which believes that to be true. Otherwise, you will need
> to use gcc's startup code to register the exception frames.
I'm using binutils 2.20 and gcc 4.4.3 and gcc seems to know that ld
supports --eh-frame-hdr: (from gcc's config.log)
configure:24001: checking linker PT_GNU_EH_FRAME support
configure:24023: result: yes
The reason why the glibc-unwind-stuff is not in libgcc in my case is
that gcc checks for:
#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)))
Since I'm not using the glibc, the __GLIBC__-part is false. Defining
that would a bad idea, I think, because it would have impact on other
things (it occurrs at a few other files in gcc as well). One way could
be to change that condition above and tell gcc that it should use the
unwind-dw2-fde-glibc.c (by default it uses the unwind-dw2-fde.c). When I
supply dl_iterate_phdr(), it may work. But I don't know if thats a good
solution...
Another way I tried was to register the exception-frames in my dynamic
linker. That means, it goes through all shared libraries, looks where
the .eh_frame-section is and does:
struct object *obj = (struct object*)malloc(sizeof(struct object));
__register_frame_info_bases(lib->ehFrameAddr,obj,0,0);
So, its a similar way as frame_dummy does register it.
The problem is: The function classify_object_over_fdes() from gcc goes
through the entries in the .eh_frame-section. Each entry has a length
and some stuff behind it. The last entry should have a zero-length, so
that it knows that it should stop. This works fine for
the .eh_frame-section in the executable, because it really has a
zero-length entry. But my shared library has no zero-length entry. So it
simply walks behind the whole section.
I don't know whats wrong here. Maybe its simply not the way it should be
used?
Nils Asmussen