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

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.


  parent reply	other threads:[~2010-04-11 21:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11  1:52 Pedro Alves
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 [this message]
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=t2k6dc9ffc81004111412z5b9e4128k6102e036ca33d15@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.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