Fix solib-disc.exp regression with x86 gdbserver

Fix solib-disc.exp regression with x86 gdbserver

[Pedro Alves]

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.

---
 gdb/gdbserver/regcache.c |    2 ++
 1 file changed, 2 insertions(+)

Index: src/gdb/gdbserver/regcache.c
===================================================================
--- src.orig/gdb/gdbserver/regcache.c	2010-04-11 01:53:44.000000000 +0100
+++ src/gdb/gdbserver/regcache.c	2010-04-11 02:32:15.000000000 +0100
@@ -138,6 +138,8 @@ realloc_register_cache (struct inferior_
   struct regcache *regcache
     = (struct regcache *) inferior_regcache_data (thread);
 
+  if (regcache != NULL)
+    regcache_invalidate_one (thread_p);
   free_register_cache (regcache);
   set_inferior_regcache_data (thread, new_register_cache ());
 }

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

[H.J. Lu]

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:
>

>
>  #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,
>  ...

How can I debug gdbserver with gdb? I tried and it didn't work.

> 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>
> )

I will try it on AVX machine.

Thanks.

-- 
H.J.

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

[Pedro Alves]

On Sunday 11 April 2010 15:04:39, H.J. Lu wrote:
> How can I debug gdbserver with gdb? I tried and it didn't work.

What doesn't work?  It Just Works for me:

 $gdb -q --args ./gdbserver :9999 ~/gdb/tests/threads
 Reading symbols from /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver...done.
 (gdb) start
 Temporary breakpoint 1 at 0x40f51f: file ../../../src/gdb/gdbserver/server.c, line 2238.
 Starting program: /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver :9999 /home/pedro/gdb/tests/threads
 
 Temporary breakpoint 1, main (argc=4, argv=0x7fffffffe068) at ../../../src/gdb/gdbserver/server.c:2238
 2238      char **next_arg = &argv[1];
 (gdb)


Attaching works too:

 $ ./gdbserver :9999 ~/gdb/tests/threads
 ...

 $ gdb -p $(pidof gdbserver)
 ...

It used to be GDB would get confused due to the uses of the clone
syscall in linux-low.c, and so breakpoints wouldn't work.  The
easy workaround was just to comment out the linux_test_for_tracefork
call (and hardcode linux_supports_tracefork_flag as 1, to get the
same behaviour you'd get without the hack).  clone is only used
on uclinux/nommu, so you shouldn't need the hack anymore on linux.

gdbserver's "--debug" command line switch is also useful (it enables
all that the internal debug output controlled by `if (debug_threads)').
"(gdb) monitor set debug 1" has the same effect.

-- 
Pedro Alves

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

[H.J. Lu]

On Sun, Apr 11, 2010 at 7:17 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 15:04:39, H.J. Lu wrote:
>> How can I debug gdbserver with gdb? I tried and it didn't work.
>
> What doesn't work?  It Just Works for me:
>
>  $gdb -q --args ./gdbserver :9999 ~/gdb/tests/threads
>  Reading symbols from /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver...done.
>  (gdb) start
>  Temporary breakpoint 1 at 0x40f51f: file ../../../src/gdb/gdbserver/server.c, line 2238.
>  Starting program: /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver :9999 /home/pedro/gdb/tests/threads
>
>  Temporary breakpoint 1, main (argc=4, argv=0x7fffffffe068) at ../../../src/gdb/gdbserver/server.c:2238
>  2238      char **next_arg = &argv[1];
>  (gdb)
>
>
> Attaching works too:
>
>  $ ./gdbserver :9999 ~/gdb/tests/threads
>  ...
>
>  $ gdb -p $(pidof gdbserver)
>  ...
>
> It used to be GDB would get confused due to the uses of the clone
> syscall in linux-low.c, and so breakpoints wouldn't work.  The
> easy workaround was just to comment out the linux_test_for_tracefork
> call (and hardcode linux_supports_tracefork_flag as 1, to get the
> same behaviour you'd get without the hack).  clone is only used
> on uclinux/nommu, so you shouldn't need the hack anymore on linux.
>
> gdbserver's "--debug" command line switch is also useful (it enables
> all that the internal debug output controlled by `if (debug_threads)').
> "(gdb) monitor set debug 1" has the same effect.

I will git it a try next time when I run into gdbserver problems.

BTW, I followed:

http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration

I couldn't get dejagnu to find the native-gdbserver board file. I had
to put

set gdbserve_board_dir xxxxx/gdbserver/boards
lappend boards_dir $gdbserve_board_dir

in my ~/.dejagnurc.


-- 
H.J.

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

[H.J. Lu]

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:
>
> This is losing any register changes done before "disconnect" in
> the previous session.
>
>
> (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>
> )

I got following extra failures with native gdbserver on Linux/x86-64.
Are they expected?

FAIL: gdb.ada/tasks.exp: continue to breakpoint (the program exited)
FAIL: gdb.ada/tasks.exp: continue until end of program (the program is
no longer running)
FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
FAIL: gdb.ada/tasks.exp: info tasks before inserting breakpoint
FAIL: gdb.base/break-entry.exp: running to *0x4002e0 in runto
FAIL: gdb.base/randomize.exp: fixed addresses should match
FAIL: gdb.base/recurse.exp: second instance watchpoint deleted when
leaving scope
FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw)
(the program exited)
FAIL: gdb.cp/exception.exp: continue to second throw
FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now
FAIL: gdb.threads/attach-stopped.exp: threaded: attach2, exit leaves
process sleeping
FAIL: gdb.threads/execl.exp: continue across exec
FAIL: gdb.threads/fork-child-threads.exp: get to the spawned thread
(the program exited)
FAIL: gdb.threads/fork-child-threads.exp: next over fork
FAIL: gdb.threads/fork-child-threads.exp: two threads found
FAIL: gdb.trace/backtrace.exp: 1.13: trace in recursion: depth not equal to 3
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect
args and locals
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect nothing
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect regs
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect
stack mem expr
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect
stack mem expr
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect
stack mem expr
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 1, collect
stack mem expr
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 2, collect
args and locals
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 2, collect nothing
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 2, collect regs
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 3, collect
args and locals
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 3, collect nothing
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 3, collect regs
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 4, collect
args and locals
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 4, collect nothing
FAIL: gdb.trace/backtrace.exp: 8.6: Backtrace, depth == 4, collect regs
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 1
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 10
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 11
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 12
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 14
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 15
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 16
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 17
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 19
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 2
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 4
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 5
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 6
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 7
FAIL: gdb.trace/backtrace.exp: 8.6: find frame 9
FAIL: gdb.trace/backtrace.exp: 8.6: find start frame
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/backtrace.exp: printf "TDP %d:\n", $tracepoint
FAIL: gdb.trace/collection.exp: collect argarray collectively: cease
trace debugging
FAIL: gdb.trace/collection.exp: collect argarray collectively: start
trace experiment
FAIL: gdb.trace/collection.exp: collect argarray collectively: tfind test frame
FAIL: gdb.trace/collection.exp: collect argarray individually: define actions
FAIL: gdb.trace/collection.exp: collect args collectively: cease trace debugging
FAIL: gdb.trace/collection.exp: collect args collectively: collected arg char
FAIL: gdb.trace/collection.exp: collect args collectively: collected arg double
FAIL: gdb.trace/collection.exp: collect args collectively: collected arg float
FAIL: gdb.trace/collection.exp: collect args collectively: collected arg int
FAIL: gdb.trace/collection.exp: collect args collectively: collected
arg struct member char
FAIL: gdb.trace/collection.exp: collect args collectively: collected
arg struct member double
FAIL: gdb.trace/collection.exp: collect args collectively: collected
arg struct member float
FAIL: gdb.trace/collection.exp: collect args collectively: collected
arg struct member int
FAIL: gdb.trace/collection.exp: collect args collectively: start trace
experiment
FAIL: gdb.trace/collection.exp: collect args collectively: tfind test frame
FAIL: gdb.trace/collection.exp: collect args individually: collected arg char
FAIL: gdb.trace/collection.exp: collect args individually: collected arg double
FAIL: gdb.trace/collection.exp: collect args individually: collected arg float
FAIL: gdb.trace/collection.exp: collect args individually: collected arg int
FAIL: gdb.trace/collection.exp: collect args individually: collected
arg struct member char
FAIL: gdb.trace/collection.exp: collect args individually: collected
arg struct member double
FAIL: gdb.trace/collection.exp: collect args individually: collected
arg struct member float
FAIL: gdb.trace/collection.exp: collect args individually: collected
arg struct member int
FAIL: gdb.trace/collection.exp: collect args individually: define actions
FAIL: gdb.trace/collection.exp: collect argstruct collectively: cease
trace debugging
FAIL: gdb.trace/collection.exp: collect argstruct collectively:
collected arg struct member char
FAIL: gdb.trace/collection.exp: collect argstruct collectively:
collected arg struct member double
FAIL: gdb.trace/collection.exp: collect argstruct collectively:
collected arg struct member float
FAIL: gdb.trace/collection.exp: collect argstruct collectively:
collected arg struct member int
FAIL: gdb.trace/collection.exp: collect argstruct collectively: start
trace experiment
FAIL: gdb.trace/collection.exp: collect argstruct collectively: tfind test frame
FAIL: gdb.trace/collection.exp: collect argstruct individually:
collected arg struct member char
FAIL: gdb.trace/collection.exp: collect argstruct individually:
collected arg struct member double
FAIL: gdb.trace/collection.exp: collect argstruct individually:
collected arg struct member float
FAIL: gdb.trace/collection.exp: collect argstruct individually:
collected arg struct member int
FAIL: gdb.trace/collection.exp: collect argstruct individually: define actions
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
cease trace debugging
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local char
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local double
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local float
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local int
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local member char
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local member double
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local member float
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected local member int
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected locarray #0
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected locarray #1
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected locarray #2
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
collected locarray #3
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
start trace experiment
FAIL: gdb.trace/collection.exp: collect auto locals collectively:
tfind test frame
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local char
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local double
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local float
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local int
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local member char
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local member double
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local member float
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected local member int
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected locarray #0
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected locarray #1
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected locarray #2
FAIL: gdb.trace/collection.exp: collect auto locals individually:
collected locarray #3
FAIL: gdb.trace/collection.exp: collect auto locals individually: define actions
FAIL: gdb.trace/collection.exp: collect register locals collectively:
cease trace debugging
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local char
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local double
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local float
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local int
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local member char
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local member double
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local member float
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected local member int
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected locarray #0
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected locarray #1
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected locarray #2
FAIL: gdb.trace/collection.exp: collect register locals collectively:
collected locarray #3
FAIL: gdb.trace/collection.exp: collect register locals collectively:
start trace experiment
FAIL: gdb.trace/collection.exp: collect register locals collectively:
tfind test frame
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local char
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local double
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local float
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local int
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local member char
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local member double
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local member float
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected local member int
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected locarray #0
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected locarray #1
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected locarray #2
FAIL: gdb.trace/collection.exp: collect register locals individually:
collected locarray #3
FAIL: gdb.trace/collection.exp: collect register locals individually:
define actions
FAIL: gdb.trace/collection.exp: collect static locals collectively:
cease trace debugging
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local char
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local double
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local float
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local int
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local member char
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local member double
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local member float
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected local member int
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected locarray #0
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected locarray #1
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected locarray #2
FAIL: gdb.trace/collection.exp: collect static locals collectively:
collected locarray #3
FAIL: gdb.trace/collection.exp: collect static locals collectively:
start trace experiment
FAIL: gdb.trace/collection.exp: collect static locals collectively:
tfind test frame
FAIL: gdb.trace/report.exp: 11.1: test $trace_frame
FAIL: gdb.trace/report.exp: 11.2: test $tracepoint
FAIL: gdb.trace/report.exp: 11.3: test $trace_line
FAIL: gdb.trace/report.exp: 11.4: test $trace_file
FAIL: gdb.trace/report.exp: 11.x, 12.1: find start frame
FAIL: gdb.trace/report.exp: 12.1: trace report #1
FAIL: gdb.trace/report.exp: 12.2: find first TDP #2 frame
FAIL: gdb.trace/report.exp: 12.2: trace report #2
FAIL: gdb.trace/report.exp: 12.3: find first TDP #3 frame
FAIL: gdb.trace/report.exp: 12.3: trace report #3
FAIL: gdb.trace/report.exp: 12.4: find first TDP #6 frame
FAIL: gdb.trace/report.exp: 12.4: trace report #4
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 2
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 3
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 4
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 5
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 6
FAIL: gdb.trace/report.exp: 9.1: find frame for TP 7
FAIL: gdb.trace/report.exp: 9.1: tdump, args collected
FAIL: gdb.trace/report.exp: 9.1: tdump, global variables collected
FAIL: gdb.trace/report.exp: 9.1: tdump, locals collected
FAIL: gdb.trace/report.exp: 9.1: tdump, memrange collected
FAIL: gdb.trace/report.exp: 9.1: tdump, nothing collected
FAIL: gdb.trace/report.exp: 9.1: tdump, regs collected
FAIL: gdb.trace/while-dyn.exp: 5.12: define stepping <stepcount>
FAIL: gdb.trace/while-dyn.exp: 5.12: define while-stepping <stepcount>
FAIL: gdb.trace/while-dyn.exp: 5.12: define ws <stepcount>


Thanks.


-- 
H.J.

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

[Pedro Alves]

On Sunday 11 April 2010 17:04:28, H.J. Lu wrote:
> I got following extra failures with native gdbserver on Linux/x86-64.

Compared to what?

> Are they expected?
> 
> FAIL: gdb.ada/tasks.exp: continue to breakpoint (the program exited)
> FAIL: gdb.ada/tasks.exp: continue until end of program (the program is
> no longer running)
> FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
> FAIL: gdb.ada/tasks.exp: info tasks before inserting breakpoint

No clue.

> FAIL: gdb.base/break-entry.exp: running to *0x4002e0 in runto

I see this too (Linux/x86-64).

> FAIL: gdb.base/randomize.exp: fixed addresses should match

Expected, gdbserver doesn't support disabling randomization.

> FAIL: gdb.base/recurse.exp: second instance watchpoint deleted when
> leaving scope

I don't see this one.

> FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw)
> (the program exited)

Expected.

> FAIL: gdb.cp/exception.exp: continue to second throw

I see this too.

> FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now

I see this too.

> FAIL: gdb.threads/attach-stopped.exp: threaded: attach2, exit leaves
> process sleeping

I don't see this one.  May be a red herring -- gdbserver doesn't
support what's being tested, IIRC.

> FAIL: gdb.threads/execl.exp: continue across exec
> FAIL: gdb.threads/fork-child-threads.exp: get to the spawned thread
> (the program exited)
> FAIL: gdb.threads/fork-child-threads.exp: next over fork
> FAIL: gdb.threads/fork-child-threads.exp: two threads found

Expected, gdbserver doesn't support following exec or fork events.

> FAIL: gdb.trace/backtrace.exp: 1.13: trace in recursion: depth not equal to 3
<skip a bunch of gdb.trace failures>
> FAIL: gdb.trace/while-dyn.exp: 5.12: define ws <stepcount>

Only recently (a couple of days) have the gdb.trace/ tests started
running against gdbserver (it didn't support tracepoints before),
but, none of these fails are expected on x86_64.  The all pass
for me.  I'd like to understand them.  What are the failures like?

-- 
Pedro Alves

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

[Pedro Alves]

On Sunday 11 April 2010 16:43:11, H.J. Lu wrote:
> BTW, I followed:
> 
> http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration
> 
> I couldn't get dejagnu to find the native-gdbserver board file. I had
> to put
> 
> set gdbserve_board_dir xxxxx/gdbserver/boards
> lappend boards_dir $gdbserve_board_dir
> 
> in my ~/.dejagnurc.
>

I have:

append boards_dir "/home/pedro/etc/boards"

in my site.exp (~/etc/site.exp); I don't remember if this was actually
needed.  Maybe a good idea to update the wiki if this is always needed.

BTW, you can run the testsuite in parallel mode against gdbserver as
well, to speed up testing.  Here's how:

 make check RUNTESTFLAGS="--target_board native-gdbserver" FORCE_PARALLEL="1" -j4

-- 
Pedro Alves

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

[H.J. Lu]

On Sun, Apr 11, 2010 at 9:13 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 17:04:28, H.J. Lu wrote:
>> I got following extra failures with native gdbserver on Linux/x86-64.
>
> Compared to what?

Compared to normal "make check".

>> Are they expected?
>>
>> FAIL: gdb.ada/tasks.exp: continue to breakpoint (the program exited)
>> FAIL: gdb.ada/tasks.exp: continue until end of program (the program is
>> no longer running)
>> FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
>> FAIL: gdb.ada/tasks.exp: info tasks before inserting breakpoint
>
> No clue.
>
>> FAIL: gdb.base/break-entry.exp: running to *0x4002e0 in runto
>
> I see this too (Linux/x86-64).
>
>> FAIL: gdb.base/randomize.exp: fixed addresses should match
>
> Expected, gdbserver doesn't support disabling randomization.
>
>> FAIL: gdb.base/recurse.exp: second instance watchpoint deleted when
>> leaving scope
>
> I don't see this one.
>
>> FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw)
>> (the program exited)
>
> Expected.
>
>> FAIL: gdb.cp/exception.exp: continue to second throw
>
> I see this too.
>
>> FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now
>
> I see this too.
>
>> FAIL: gdb.threads/attach-stopped.exp: threaded: attach2, exit leaves
>> process sleeping
>
> I don't see this one.  May be a red herring -- gdbserver doesn't
> support what's being tested, IIRC.
>
>> FAIL: gdb.threads/execl.exp: continue across exec
>> FAIL: gdb.threads/fork-child-threads.exp: get to the spawned thread
>> (the program exited)
>> FAIL: gdb.threads/fork-child-threads.exp: next over fork
>> FAIL: gdb.threads/fork-child-threads.exp: two threads found
>
> Expected, gdbserver doesn't support following exec or fork events.
>
>> FAIL: gdb.trace/backtrace.exp: 1.13: trace in recursion: depth not equal to 3
> <skip a bunch of gdb.trace failures>
>> FAIL: gdb.trace/while-dyn.exp: 5.12: define ws <stepcount>
>
> Only recently (a couple of days) have the gdb.trace/ tests started
> running against gdbserver (it didn't support tracepoints before),
> but, none of these fails are expected on x86_64.  The all pass
> for me.  I'd like to understand them.  What are the failures like?
>

I am running Fedora 12. It may make a difference.

BTW, I noticed a few bugs when running gdbserver tests on
AVX. I will try to fix them.


-- 
H.J.

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

[H.J. Lu]

On Sun, Apr 11, 2010 at 9:16 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 16:43:11, H.J. Lu wrote:
>> BTW, I followed:
>>
>> http://sourceware.org/gdb/wiki/TestingGDB#Testing_gdbserver_in_a_native_configuration
>>
>> I couldn't get dejagnu to find the native-gdbserver board file. I had
>> to put
>>
>> set gdbserve_board_dir xxxxx/gdbserver/boards
>> lappend boards_dir $gdbserve_board_dir
>>
>> in my ~/.dejagnurc.
>>
>
> I have:
>
> append boards_dir "/home/pedro/etc/boards"
>
> in my site.exp (~/etc/site.exp); I don't remember if this was actually
> needed.  Maybe a good idea to update the wiki if this is always needed.

Yes, it is required. It took me a while to figure it out. One needs

1. Set DEJAGNU to an empty file.
2. Append the directory contains native-gdbserve.exp to boards_dir
in ~/.dejagnurc.

> BTW, you can run the testsuite in parallel mode against gdbserver as
> well, to speed up testing.  Here's how:
>
>  make check RUNTESTFLAGS="--target_board native-gdbserver" FORCE_PARALLEL="1" -j4
>

Yes, that is what I am using. Do I need FORCE_PARALLEL="1"?
It seems to work without it.

Thanks.


-- 
H.J.

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

[H.J. Lu]

On Sun, Apr 11, 2010 at 7:17 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 15:04:39, H.J. Lu wrote:
>> How can I debug gdbserver with gdb? I tried and it didn't work.
>
> What doesn't work?  It Just Works for me:
>
>  $gdb -q --args ./gdbserver :9999 ~/gdb/tests/threads
>  Reading symbols from /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver...done.
>  (gdb) start
>  Temporary breakpoint 1 at 0x40f51f: file ../../../src/gdb/gdbserver/server.c, line 2238.
>  Starting program: /home/pedro/gdb/gdbserver_tracepoints_step_over_bkpt_pushed/build/gdb/gdbserver/gdbserver :9999 /home/pedro/gdb/tests/threads
>
>  Temporary breakpoint 1, main (argc=4, argv=0x7fffffffe068) at ../../../src/gdb/gdbserver/server.c:2238
>  2238      char **next_arg = &argv[1];
>  (gdb)
>
>
> Attaching works too:
>
>  $ ./gdbserver :9999 ~/gdb/tests/threads
>  ...
>
>  $ gdb -p $(pidof gdbserver)
>  ...
>
> It used to be GDB would get confused due to the uses of the clone
> syscall in linux-low.c, and so breakpoints wouldn't work.  The
> easy workaround was just to comment out the linux_test_for_tracefork
> call (and hardcode linux_supports_tracefork_flag as 1, to get the
> same behaviour you'd get without the hack).  clone is only used
> on uclinux/nommu, so you shouldn't need the hack anymore on linux.
>
> gdbserver's "--debug" command line switch is also useful (it enables
> all that the internal debug output controlled by `if (debug_threads)').
> "(gdb) monitor set debug 1" has the same effect.
>

I set breakpoint in x86_linux_process_qsupported. Gdb only stopped
at the first call. The second call was never stopped. It may be a
follow-fork issue.


-- 
H.J.

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

[H.J. Lu]

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.

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

[H.J. Lu]

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.

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

[Pedro Alves]

On Sunday 11 April 2010 22:12:08, H.J. Lu wrote:
> 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.
> 

Then, this means we're invalidating the regcache too late. 
We're flushing the old regcache contents to the threads, that were
created using the previous gdb's register layout, but we're flushing
the data using the _new_ register cache layout and low target
methods.  That sounds wrong indeed.

I think this would help.  Or is this still too late?

-- 
Pedro Alves

2010-04-12  Pedro Alves  <pedro@codesourcery.com>

	gdb/gdbserver/
	* regcache.c (set_register_cache): Invalidate regcaches before
	changing the register cache layout.
	(regcache_invalidate_one): Allow a NULL regcache.
	* linux-x86-low.c (x86_linux_update_xmltarget): Invalidate
	regcaches before changing the register cache layout or the target
	regsets.

---
 gdb/gdbserver/linux-x86-low.c |    5 +++++
 gdb/gdbserver/regcache.c      |    7 +++++++
 2 files changed, 12 insertions(+)

Index: src/gdb/gdbserver/regcache.c
===================================================================
--- src.orig/gdb/gdbserver/regcache.c	2010-04-12 08:03:43.000000000 +0100
+++ src/gdb/gdbserver/regcache.c	2010-04-12 08:20:23.000000000 +0100
@@ -61,6 +61,9 @@ regcache_invalidate_one (struct inferior
 
   regcache = (struct regcache *) inferior_regcache_data (thread);
 
+  if (regcache == NULL)
+    return;
+
   if (regcache->registers_valid)
     {
       struct thread_info *saved_inferior = current_inferior;
@@ -149,6 +152,10 @@ set_register_cache (struct reg *regs, in
 {
   int offset, i;
 
+  /* Before changing the register cache internal layout, flush the
+     contents of valid caches back to the threads.  */
+  regcache_invalidate ();
+
   reg_defs = regs;
   num_registers = n;
 
Index: src/gdb/gdbserver/linux-x86-low.c
===================================================================
--- src.orig/gdb/gdbserver/linux-x86-low.c	2010-04-12 08:23:08.000000000 +0100
+++ src/gdb/gdbserver/linux-x86-low.c	2010-04-12 08:37:57.000000000 +0100
@@ -841,6 +841,11 @@ x86_linux_update_xmltarget (void)
   if (!current_inferior)
     return;
 
+  /* Before changing the register cache internal layout or the target
+     regsets, flush the contents of the current valid caches back to
+     the threads.  */
+  regcache_invalidate ();
+
   pid = pid_of (get_thread_lwp (current_inferior));
 #ifdef __x86_64__
   if (num_xmm_registers == 8)

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

[H.J. Lu]

On Mon, Apr 12, 2010 at 12:45 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Sunday 11 April 2010 22:12:08, H.J. Lu wrote:
>> 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.
>>
>
> Then, this means we're invalidating the regcache too late.
> We're flushing the old regcache contents to the threads, that were
> created using the previous gdb's register layout, but we're flushing
> the data using the _new_ register cache layout and low target
> methods.  That sounds wrong indeed.
>
> I think this would help.  Or is this still too late?
>
> --
> Pedro Alves
>
> 2010-04-12  Pedro Alves  <pedro@codesourcery.com>
>
>        gdb/gdbserver/
>        * regcache.c (set_register_cache): Invalidate regcaches before
>        changing the register cache layout.
>        (regcache_invalidate_one): Allow a NULL regcache.
>        * linux-x86-low.c (x86_linux_update_xmltarget): Invalidate
>        regcaches before changing the register cache layout or the target
>        regsets.
>

It works.

Thanks.


-- 
H.J.

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

[Pedro Alves]

On Monday 12 April 2010 14:05:01, H.J. Lu wrote:
> > 2010-04-12  Pedro Alves  <pedro@codesourcery.com>
> >
> >        gdb/gdbserver/
> >        * regcache.c (set_register_cache): Invalidate regcaches before
> >        changing the register cache layout.
> >        (regcache_invalidate_one): Allow a NULL regcache.
> >        * linux-x86-low.c (x86_linux_update_xmltarget): Invalidate
> >        regcaches before changing the register cache layout or the target
> >        regsets.
> >
> 
> It works.
> 
> Thanks.

Great, I've applied it.  Thanks.

-- 
Pedro Alves