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

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

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.