This is the mail archive of the binutils@sources.redhat.com 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: Relocs against unalloced sections in shared libraries


On Fri, Jan 10, 2003 at 03:24:20PM +0100, Andreas Schwab wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> |> On Thu, Jan 09, 2003 at 04:39:08PM -0800, Geoff Keating wrote:
> |> > > From: Andreas Schwab <schwab@suse.de>
> |> > > Date: 10 Jan 2003 01:29:50 +0100
> |> > 
> |> > > Geoff Keating <geoffk@geoffk.org> writes:
> |> > > 
> |> > > > Isn't this necessary for proper handling of DWARF2 debug information?
> |> > > 
> |> > > The debugger will know which bytes to relocate by looking at the
> |> > > structure while reading the debug information from a shared library.
> |> > 
> |> > Hmmm.  Have you asked the GDB people about this?  I believe the
> |> > conclusion was that it kind-of does this now, and it kind-of works,
> |> > but in the long run it should be looking at the relocations.
> |> 
> |> Yes.  I don't know if it's possible to reproduce the situation in a
> |> shared library on PPC (I haven't tried) but there are ET_REL objects
> |> on PPC that _can not_ be debugged without properly obeying the
> |> relocation information.  That's because there can be relocations
> |> against variables instead of against section symbols.
> 
> We are talking about ET_DYN objects, where this is a non-issue.  Of
> course, ET_REL object continue to contain the full relocation information.

Is it?  Will all these relocations be resolved to section+offset?  Hmm,
it appears so in practice but I can never figure out how that's
determined.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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