fde-glibc.c bug

Richard Henderson rth@redhat.com
Tue Jul 3 09:51:00 GMT 2001


On Tue, Jul 03, 2001 at 05:29:22AM -0400, Jakub Jelinek wrote:
> > I haven't looked at the problem and won't do it.  Not my job.  I'll
> > not accept any additional exposure of existing data structures and no
> > new global variables.
> 
> Ok, in that case I guess the only remaining solution is to do what
> fde-glibc.c does inside of glibc, so that glibc internals don't have to be
> exposed, because I don't think fde-glibc.c can find the ELF headers of
> shared libraries just from the link_map exported portion.

This is unfortunate.  It's not like libgcc is the only application
that wants to iterate over the set of mapped DSOs.

I'd be disapointed if the preferred solution was just to take 
_Unwind_FindTableEntry (or _Unwind_Find_FDE) and drop it into glibc.
That would mean that the next time someone wanted to do something
similar, they'd not be able.

How about a for_each_dso type function that took a callback, takes
care of the locking, passes the link_map and mapping bounds?  The
callback returns 0 to keep searching, non-zero is passed back to
the caller.


r~



More information about the Libc-alpha mailing list