Fix solib-disc.exp regression with x86 gdbserver

H.J. Lu hjl.tools@gmail.com
Sun Apr 11 21:18:00 GMT 2010


On Sun, Apr 11, 2010 at 2:12 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>

A patch is posted at

http://sourceware.org/ml/gdb-patches/2010-04/msg00336.html

-- 
H.J.



More information about the Gdb-patches mailing list