Relocs against unalloced sections in shared libraries

Andreas Schwab schwab@suse.de
Fri Jan 10 15:08:00 GMT 2003


Daniel Jacobowitz <drow@mvista.com> writes:

|> 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?

What is "it" refering to?

|> Will all these relocations be resolved to section+offset?

The only relocations that would occur in a shared library are
R_PPC_RELATIVE relocations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



More information about the Binutils mailing list