From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58347 invoked by alias); 19 Oct 2015 11:48:02 -0000 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 Received: (qmail 58248 invoked by uid 89); 19 Oct 2015 11:48:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 19 Oct 2015 11:47:59 +0000 Received: by padhk11 with SMTP id hk11so28264574pad.1 for ; Mon, 19 Oct 2015 04:47:58 -0700 (PDT) X-Received: by 10.68.227.227 with SMTP id sd3mr34826272pbc.116.1445255278007; Mon, 19 Oct 2015 04:47:58 -0700 (PDT) Received: from E107787-LIN (gcc2-power8.osuosl.org. [140.211.9.43]) by smtp.gmail.com with ESMTPSA id xg2sm35969501pbb.2.2015.10.19.04.47.54 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 19 Oct 2015 04:47:57 -0700 (PDT) From: Yao Qi To: Yao Qi Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 00/18] Remote all-stop on top of non-stop References: <1444836486-25679-1-git-send-email-palves@redhat.com> <86lhb23gm4.fsf@gmail.com> Date: Mon, 19 Oct 2015 11:48:00 -0000 In-Reply-To: <86lhb23gm4.fsf@gmail.com> (Yao Qi's message of "Fri, 16 Oct 2015 17:47:31 +0100") Message-ID: <86h9ln2i6x.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00334.txt.bz2 Yao Qi writes: > There is one fail on multi-arch aarch64-linux in > gdb.base/range-stepping.exp, > > FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=3D1 vCont= ;r=3D1 > > in the testing GDB and GDBserver is configured for aarch64-linux, but > the program is compiled for arm-linux. I checked gdb.log that there is > vCont;r but no vCont;s. I suspect that GDB does software single > step, but arm-linux-tdep.c:arm_linux_software_single_step has already dis= able > software single step if GDBserver can do single step (AArch64 GDBserver > can do hardware single step). Hi Pedro, This fail above isn't caused by your patch series, but this series exposes something we need to think about here. In the test, after command "n" is issued, the test expects to see vCont;s and vCont;r, because GDB first steps over the breakpoint and then do range-stepping across the line of code. Here is an assumption that the remote target can do range stepping must support single step (either by hardware or by software done by remote target itself), and that is why I check the number vCont;r and vCont;s in the tests. This assumption is true for x86-linux and aarch64-linux. However, it isn't the case when aarch64-linux GDBservers debugs arm-linux program. Aarch64-linux GDBserver claims supporting range-stepping by defining aarch64_supports_range_stepping in linux-aarch64-low.c, gdb.base/range-stepping.exp is tested. (Note that this test is skipped on pure arm-linux testing, because arm-linux GDBserver doesn't support range-stepping). GDB will still emit vCont;r to do range stepping, that is fine. Before range-stepping, GDB needs to step over the breakpoint by in-line stepping, GDB uses the right gdbarch (for arm-linux) to do that, so the right decision on hardware single step vs software single step can be made according to target_can_do_single_step ... static int arm_linux_software_single_step (struct frame_info *frame) { struct gdbarch *gdbarch =3D get_frame_arch (frame); struct address_space *aspace =3D get_frame_address_space (frame); CORE_ADDR next_pc; if (arm_deal_with_atomic_sequence (frame)) return 1; /* If the target does have hardware single step, GDB doesn't have to bother software single step. */ if (target_can_do_single_step () =3D=3D 1) return 0; in the multi-arch case, GDB stills emit vCont;s because it knows the remote target can do single step. That is why these tests pass before. With your patch applied, GDB prefers to step over the breakpoint by out-of-line stepping, and nowadays gdbarch (for arm-linux) decides to resume the instructions in scratchpad rather than single step them, in infrun.c:resume: /* Update pc to reflect the new address from which we will execute instructions due to displaced stepping. */ pc =3D regcache_read_pc (get_thread_regcache (inferior_ptid)); displaced =3D get_displaced_stepping_state (ptid_get_pid (inferior_ptid)= ); step =3D gdbarch_displaced_step_hw_singlestep (gdbarch, displaced->step_closure); (gdbarch_displaced_step_hw_singlestep returns zero on arm-linux), so GDB emits vCont;c rather than vCont;s. There are some ways fixing this problem, 1. stop checking vCont;s packet anymore in range-stepping tests. 2. let gdbarch_displaced_step_hw_singlestep returns true for arm-linux in the multi-arch case like this, int arm_displaced_step_hw_singlestep (struct gdbarch *gdbarch, struct displaced_step_closure *closure) { if (target_can_do_single_step () =3D=3D 1) return 1; return 0; } then further, we need to either, 2.1 teach GDB core to support single stepping multiple instructions in scratch pad. Nowadays, GDB only expects one stop event when executing instructions in the scratchpad. ARM is the only target that GDB copies more than one instructions to the scratchpad, and resume program there instead of single step. Other targets, like x86, aarch64, GDB only copies *one* instruction to the scratchpad and single step. 2.2 rewrite arm displaced stepping code to be aware that the target may be able to do single step, so that each time GDB has only to copy one instruction to the scratchpad, do single step and fix up if necessary. Fix #1 looks reasonable and ideal to me, and the easiest one. Fix #2.1 and #2.2 will need much work, at least #2.2, and I don't know how useful #2.1 is. --=20 Yao (=E9=BD=90=E5=B0=A7)