debugger fix

[Ulrich Weigand]

I wrote:
> Eric Pouech wrote:
> 
> > > Could you send me the libwinspool.drv.so file that objcopy
> > > is choking on?  I'd like to look whether there's something
> > > strange with that.
> > here it is... (I've used libpsapi.so instead, because it's smaller, but
> > effects are the same)
> 
> Well, one difference I see is that yours has a .rel.stabs section,
> while mine doesn't.  Now I don't quite understand why stabs need
> to be relocated, but I guess this could be a source of confusion.
> In any case, after I strip the stabs data using objcopy --strip-debug,
> I can subsequently use objcopy -N without problems.
> 
> The problem might be caused by the objcopy -L step not correctly
> updating the debug info.  Could you try adding a --debugging
> argument to objcopy in both localize_imports and strip_imports?

No, it's definitely a problem with the .rel.stabs section.
In fact, *every* invocation of objcopy that leaves the .rel.stabs
section in its output fails -- even a simple identical copy.  
(Note that if you *remove* the .rel.stabs section, it works -- 
this is why a normal 'strip' works ...)

The reason for this is that objcopy relies on the bfd library
to assign the file offsets of the sections in the output file.
Unfortunately, the automatic assignment is done only for sections
that are part of a segment (i.e. loaded into memory), and also
for *those* sections outside of segments that are *not* reloc
sections ...  For reloc sections outside of segments, like the
.rel.stabs section, no automatic file offset assignment is
performed.  Instead, the upper layers must do this themselves,
which e.g. the linker does in its final_link step.  

The objcopy tool, however, never does.  This leads to an invalid
file offset being used when writing out the .rel.stabs section,
which causes the abort.

As a side note: I've tried using the --debugging argument,
which basically recreates the debug sections from scratch
instead of copying them, and this fails completely with my
toolchain -- it runs into an endless loop.  The reason for
this is apparently a compiler bug in gcc 2.95.2 that 
miscompiles a routine from objcopy by converting a recursive
function call into tail recursion in an invalid way ...

I still don't understand why your toolchain creates a
.rel.stabs section in the first place.  Could you check
at which point this is created first (as, ld, ld -shared)?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand at informatik.uni-erlangen.de