This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: fde-glibc.c bug
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: fde-glibc.c bug
- From: Richard Henderson <rth at redhat dot com>
- Date: Tue, 3 Jul 2001 09:49:40 -0700
- Cc: drepper at redhat dot com, hjl at lucon dot org, jes at sunsite dot dk, David Mosberger <davidm at hpl dot hp dot com>, gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- References: <d3pubkfymm.fsf@lxplus015.cern.ch> <200107020854.f628sOS01676@jeswick.caldera.de> <20010702055546.I32061@devserv.devel.redhat.com> <d3ofr3uj0v.fsf@lxplus015.cern.ch> <m3g0cf81ne.fsf@otr.mynet> <20010702175906.O32061@devserv.devel.redhat.com> <m38zi77zrc.fsf@otr.mynet> <20010703052922.Q32061@devserv.devel.redhat.com>
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~