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