Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Subject: Fix solib-disc.exp regression with x86 gdbserver
Date: Sun, 11 Apr 2010 01:52:00 -0000	[thread overview]
Message-ID: <201004110252.35997.pedro@codesourcery.com> (raw)

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 ());
 }


             reply	other threads:[~2010-04-11  1:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11  1:52 Pedro Alves [this message]
2010-04-11 14:04 ` H.J. Lu
2010-04-11 14:18   ` Pedro Alves
2010-04-11 15:43     ` H.J. Lu
2010-04-11 16:17       ` Pedro Alves
2010-04-11 16:22         ` H.J. Lu
2010-04-11 16:59     ` H.J. Lu
2010-04-11 16:04 ` H.J. Lu
2010-04-11 16:13   ` Pedro Alves
2010-04-11 16:18     ` H.J. Lu
2010-04-11 21:12 ` H.J. Lu
2010-04-11 21:18   ` H.J. Lu
2010-04-12  7:46   ` Pedro Alves
2010-04-12 13:05     ` H.J. Lu
2010-04-12 13:26       ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201004110252.35997.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox