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

[Pedro Alves <palves@redhat.com>]

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<!-- Copyright (C) 2010-2013 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!-- AMD64 with AVX - Includes Linux-only special "register".  -->\n\n<!DOCTYPE target SYSTEM "gdb-target.dtd">\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