Re: Fix solib-disc.exp regression with x86 gdbserver

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sat, Apr 10, 2010 at 6:52 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> The testsuite shows a couple of new regression with x86 gdbserver:
>
> ?-PASS: gdb.base/solib-disc.exp: check $pc after load
> ?+FAIL: gdb.base/solib-disc.exp: check $pc after load
> ?-PASS: gdb.base/solib-disc.exp: check $pc after unload
> ?+FAIL: gdb.base/solib-disc.exp: check $pc after unload
>
> The test stops at a breakpoint, saves the PC,
> disconnects, reconnects, and expects to find the
> same PC. ?But, it doesn't currently:
>
> ?...
> ?print/x $pc
> ?$1 = 0x2b5a65534fc0
> ? ? ?^^^^^^^^^^^^^^
> ?(gdb) PASS: gdb.base/solib-disc.exp: save $pc after load
> ?disconnect
> ?Ending remote debugging.
> ?(gdb) PASS: gdb.base/solib-disc.exp: disconnect after load
> ?readchar: Got EOF
> ?Remote side has terminated connection. ?GDBserver will reopen the connection.
> ?Listening on port 2463
> ?Remote debugging from host 127.0.0.1
> ?target remote localhost:2463
>
> ?...
>
> ?Loaded symbols for /lib64/ld-linux-x86-64.so.2
> ?0x00002b5a65534fc1 in _dl_debug_state () at dl-debug.c:77
> ?77 ? ? ?dl-debug.c: No such file or directory.
> ? ? ? ? in dl-debug.c
> ?(gdb) PASS: gdb.base/solib-disc.exp: reconnect after load
> ?print/x $pc
> ?$2 = 0x2b5a65534fc1
> ? ? ?^^^^^^^^^^^^^^
> ?(gdb) FAIL: gdb.base/solib-disc.exp: check $pc after load
>
> Note the off-by-one. ?This is the decr_pc_after_break getting
> lost between disconnect/reconnect.
>
> gdbserver's regcache is not write-through, registers are only
> flushed to the threads just before resuming them. ?The problem
> is that there's new code that recreates all thread's regcaches
> without flushing them to the threads before the recreation.
>
> ?#0 ?init_register_cache (regcache=0x6453f0, regbuf=0x0) at ../../../src/gdb/gdbserver/regcache.c:85
> ?#1 ?0x00000000004074fb in new_register_cache () at ../../../src/gdb/gdbserver/regcache.c:114
> ?#2 ?0x00000000004075a5 in realloc_register_cache (thread_p=0x645390) at ../../../src/gdb/gdbserver/regcache.c:142
> ?#3 ?0x00000000004068ce in for_each_inferior (list=0x63c5c0, action=0x407570 <realloc_register_cache>)
> ? ? at ../../../src/gdb/gdbserver/inferiors.c:134
> ?#4 ?0x0000000000407662 in set_register_cache (regs=0x638580, n=58) at ../../../src/gdb/gdbserver/regcache.c:167
> ?#5 ?0x000000000041a0df in init_registers_amd64_linux () at amd64-linux.c:93
> ?#6 ?0x0000000000423692 in x86_linux_update_xmltarget () at ../../../src/gdb/gdbserver/linux-x86-low.c:849
> ?#7 ?0x00000000004238a2 in x86_linux_process_qsupported (query=0x0) at ../../../src/gdb/gdbserver/linux-x86-low.c:980
> ?#8 ?0x000000000042265e in linux_process_qsupported (query=0x0) at ../../../src/gdb/gdbserver/linux-low.c:4235
> ?#9 ?0x000000000040d433 in handle_query (own_buf=0x63d190 "qSupported:xmlRegisters=i386", packet_len=28,
> ?...
>
> This is losing any register changes done before "disconnect" in
> the previous session.
>
> The patch below fixes it, and I've applied it.
>
> (H.J., in case you don't know yet, here's how one easily
> tests against gdbserver on localhost:
> ?<http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration>
> )
>
> --
> Pedro Alves
>
> 2010-04-11 ?Pedro Alves ?<pedro@codesourcery.com>
>
> ? ? ? ?gdb/gdbserver/
> ? ? ? ?* regcache.c (realloc_register_cache): Invalidate inferior's
> ? ? ? ?regcache before recreating it.
>

This patch breaks gdbserver on AVX. We have

1. Connect from GDB with XML support:
      gdbserver enables XML support.
2. Disconnect.
3. Reconnect from any GDB
       a. gdberver assumes GDB doesn't support XML sets to
          target to Linux without AVX.
       b. Gdbserver  aborts when it tries to invalidate regcache
           since the target doesn't support AVX registers.

I will try to fix it.


-- 
H.J.