Re: gdbserver regression [Re: [COMMIT PATCH][GDBserver] Multi-process + multi-arch]

Pedro Alves
2013-06-11T13:56:35Z

On 06/08/2013 02:53 AM, Jan Kratochvil wrote:
> On Fri, 07 Jun 2013 12:50:44 +0200, Pedro Alves wrote:
>> I've now squashed everything into a single patch, and checked it in,
>> as below.
>
> 412f6d9c3dd9bf3049d1b78aefdc7391f95b5484 is the first bad commit
> commit 412f6d9c3dd9bf3049d1b78aefdc7391f95b5484
> Author: Pedro Alves <palves@redhat.com>
> Date: Fri Jun 7 10:46:57 2013 +0000
>
> [GDBserver] Multi-process + multi-arch
>
> cd gdb/testsuite/
> ../gdbserver/gdbserver :1234 ~/t/hello &
> echo p=$!
> ../gdb -nx ~/t/hello -ex 'set debug remote 1' -ex 'target remote localhost:1234' -ex c -ex 'set confirm no' -ex q 2>&1|tee log
> kill -9 $p
> grep 'Inferior .* exited normally' log
>
>
> ~/t/hello is hello world: int main () { puts("hello"); }
>
>
> [...]
> Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S;t;r
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Packet received: T0506:0000000000000000;07:0000000000000000;10:0000000000000000;thread:p54b6.54b6;core:1;
> Sending packet: $z0,39e6403f92,1#a2...Packet received: OK
> Sending packet: $z0,39e6413355,1#6f...Packet received: OK
> Sending packet: $z0,39e6414285,1#72...Packet received: OK
> Sending packet: $m0,1#fa...Packet received: E01
> Sending packet: $m0,1#fa...Packet received: E01
> Sending packet: $m0,9#02...Packet received: E01
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000000000000000 in ?? ()

Unfortunately I can't reproduce this. :-/ I've tried both 64-bit
and and 32-bit. All I can think of I might have broken would be sending
the wrong target description to GDB.

Maybe I've messed that up (x86_linux_read_description, vs the previous
-x86_linux_update_xmltarget)? Looking over the current code I notice
x32/avx must be broken (http://sourceware.org/ml/gdb-patches/2013-06/msg00247.html)
but given the above log shows breakpoints at 39e6403f92 (>32-bit) it doesn't
look like that'd be the arch in question..

Maybe comparing before/after RSP logs shows some hint? Particularly
the target.xml fetching bit:

"Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<?xml version="1.0"?>\n \n\n \n\n \n<target>\n <architecture>i386:x86-64</architecture>\n <osabi>GNU/Linux</osabi>\n <xi:include href="64bit-core.xml"/>\n <xi:include href="64bit-sse.xml"/>\n <xi:include href="64bit-linux.xml"/>\n <xi:include href="64bit-avx.xml"/>\n</target>\n"

m0 means reading memory from 0, which results from:

> Sending packet: $vCont;c#a8...Packet received: T0506:0000000000000000;07:0000000000000000;10:0000000000000000;thread:p54b6.54b6;core:1;

That's 0 for rbp,rsp,rip. That means prepare_resume_reply, is finding
_a_ description that includes those 3 registers, which is correct. If
there was no description, then there'd be no expedite registers in that
reply to vCont. However, if the description is the wrong one, I guess
GDBserver could be sending out the wrong registers to GDB (fetching them
from the wrong offsets).

--
Pedro Alves