Re: cross debug glibc loader problem

[Matt Rice <ratmice@gmail.com>]

On Wed, Feb 10, 2010 at 7:12 PM, Amker.Cheng <amker.cheng@gmail.com> wrote:
> On Thu, Feb 11, 2010 at 3:45 AM, Matt Rice <ratmice@gmail.com> wrote:
>> On Wed, Feb 10, 2010 at 4:09 AM, Amker.Cheng <amker.cheng@gmail.com> wrote:
>
>>
>> I would try it out with gdb from cvs, and if that doesn't work
>> investigate Jan Kratochvil's recent PIE: series of threads on the
>> gdb-patches list (at least some of which have been integrated), as I
>> am lead to believe from the first thread in the series that those
>> patches covered debugging ld.so.
>>
> Thanks, but I trid gdb-7.0.1 in two ways, both facing the same problem:

Yeah, I don't think 7.0.1 is recent enough to contain Jan's patches
gdb seems to be moving at quite the pace these days

> 1 : cross debug using gdb-7.0.1;
> 2 : native debug using gdb-7.0.1, which was built for and running
> under mipsel-linux;
>
> gdb always complains about "Cannot access memory at address 0x32a14"
>
> Maybe I've missed something important when following instruction at
> http://sources.redhat.com/glibc/wiki/Debugging/Loader_Debugging

I tried the same on x86_64 a while back, and had the same issues I
spoke with the author of this documentation, he couldn't remember the
version of gdb used and said that he had possibly patched it,

I believe that with a properly working gdb capable of debugging ld.so
this documentation is sound and will prove helpful to you.

but to get gdb capable of debugging ld.so, you'll currently have to
try out cvs, and if that doesn't work, researching Jan's PIE patches
is your best bet.

as in the first mail in the thread he mentions the various cases of
ld.so debugging.

http://sourceware.org/ml/gdb-patches/2009-11/msg00167.html
(note that these threads are split across months which if i recall the
list archives handle less than gracefully)

sorry i'm being real vague here, but this is a large patch series
which has undergone recent progress, and i'm not really aware of the
current status.   But in these cases the best way to ensure that a
future gdb release works how you need it is to try out current
developments.