From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20902 invoked by alias); 11 Apr 2010 21:18:48 -0000 Received: (qmail 20891 invoked by uid 22791); 11 Apr 2010 21:18:47 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45,TW_EG X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Apr 2010 21:18:41 +0000 Received: by vws15 with SMTP id 15so1160509vws.0 for ; Sun, 11 Apr 2010 14:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.44.198 with HTTP; Sun, 11 Apr 2010 14:18:39 -0700 (PDT) In-Reply-To: References: <201004110252.35997.pedro@codesourcery.com> Date: Sun, 11 Apr 2010 21:18:00 -0000 Received: by 10.220.126.140 with SMTP id c12mr1520307vcs.50.1271020719538; Sun, 11 Apr 2010 14:18:39 -0700 (PDT) Message-ID: Subject: Re: Fix solib-disc.exp regression with x86 gdbserver From: "H.J. Lu" To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00337.txt.bz2 On Sun, Apr 11, 2010 at 2:12 PM, H.J. Lu wrote: > On Sat, Apr 10, 2010 at 6:52 PM, Pedro Alves wro= te: >> The testsuite shows a couple of new regression with x86 gdbserver: >> >> =A0-PASS: gdb.base/solib-disc.exp: check $pc after load >> =A0+FAIL: gdb.base/solib-disc.exp: check $pc after load >> =A0-PASS: gdb.base/solib-disc.exp: check $pc after unload >> =A0+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. =A0But, it doesn't currently: >> >> =A0... >> =A0print/x $pc >> =A0$1 =3D 0x2b5a65534fc0 >> =A0 =A0 =A0^^^^^^^^^^^^^^ >> =A0(gdb) PASS: gdb.base/solib-disc.exp: save $pc after load >> =A0disconnect >> =A0Ending remote debugging. >> =A0(gdb) PASS: gdb.base/solib-disc.exp: disconnect after load >> =A0readchar: Got EOF >> =A0Remote side has terminated connection. =A0GDBserver will reopen the c= onnection. >> =A0Listening on port 2463 >> =A0Remote debugging from host 127.0.0.1 >> =A0target remote localhost:2463 >> >> =A0... >> >> =A0Loaded symbols for /lib64/ld-linux-x86-64.so.2 >> =A00x00002b5a65534fc1 in _dl_debug_state () at dl-debug.c:77 >> =A077 =A0 =A0 =A0dl-debug.c: No such file or directory. >> =A0 =A0 =A0 =A0 in dl-debug.c >> =A0(gdb) PASS: gdb.base/solib-disc.exp: reconnect after load >> =A0print/x $pc >> =A0$2 =3D 0x2b5a65534fc1 >> =A0 =A0 =A0^^^^^^^^^^^^^^ >> =A0(gdb) FAIL: gdb.base/solib-disc.exp: check $pc after load >> >> Note the off-by-one. =A0This 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. =A0The problem >> is that there's new code that recreates all thread's regcaches >> without flushing them to the threads before the recreation. >> >> =A0#0 =A0init_register_cache (regcache=3D0x6453f0, regbuf=3D0x0) at ../.= ./../src/gdb/gdbserver/regcache.c:85 >> =A0#1 =A00x00000000004074fb in new_register_cache () at ../../../src/gdb= /gdbserver/regcache.c:114 >> =A0#2 =A00x00000000004075a5 in realloc_register_cache (thread_p=3D0x6453= 90) at ../../../src/gdb/gdbserver/regcache.c:142 >> =A0#3 =A00x00000000004068ce in for_each_inferior (list=3D0x63c5c0, actio= n=3D0x407570 ) >> =A0 =A0 at ../../../src/gdb/gdbserver/inferiors.c:134 >> =A0#4 =A00x0000000000407662 in set_register_cache (regs=3D0x638580, n=3D= 58) at ../../../src/gdb/gdbserver/regcache.c:167 >> =A0#5 =A00x000000000041a0df in init_registers_amd64_linux () at amd64-li= nux.c:93 >> =A0#6 =A00x0000000000423692 in x86_linux_update_xmltarget () at ../../..= /src/gdb/gdbserver/linux-x86-low.c:849 >> =A0#7 =A00x00000000004238a2 in x86_linux_process_qsupported (query=3D0x0= ) at ../../../src/gdb/gdbserver/linux-x86-low.c:980 >> =A0#8 =A00x000000000042265e in linux_process_qsupported (query=3D0x0) at= ../../../src/gdb/gdbserver/linux-low.c:4235 >> =A0#9 =A00x000000000040d433 in handle_query (own_buf=3D0x63d190 "qSuppor= ted:xmlRegisters=3Di386", packet_len=3D28, >> =A0... >> >> 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: >> =A0 >> ) >> >> -- >> Pedro Alves >> >> 2010-04-11 =A0Pedro Alves =A0 >> >> =A0 =A0 =A0 =A0gdb/gdbserver/ >> =A0 =A0 =A0 =A0* regcache.c (realloc_register_cache): Invalidate inferio= r's >> =A0 =A0 =A0 =A0regcache before recreating it. >> > > This patch breaks gdbserver on AVX. We have > > 1. Connect from GDB with XML support: > =A0 =A0 =A0gdbserver enables XML support. > 2. Disconnect. > 3. Reconnect from any GDB > =A0 =A0 =A0 a. gdberver assumes GDB doesn't support XML sets to > =A0 =A0 =A0 =A0 =A0target to Linux without AVX. > =A0 =A0 =A0 b. Gdbserver =A0aborts when it tries to invalidate regcache > =A0 =A0 =A0 =A0 =A0 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 --=20 H.J.