This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]