From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17768 invoked by alias); 29 Jan 2017 21:41:11 -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 17754 invoked by uid 89); 29 Jan 2017 21:41:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:wwokr33, H*f:sk:wwokr33 X-HELO: mail-qt0-f195.google.com Received: from mail-qt0-f195.google.com (HELO mail-qt0-f195.google.com) (209.85.216.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Jan 2017 21:41:00 +0000 Received: by mail-qt0-f195.google.com with SMTP id h53so17211020qth.3 for ; Sun, 29 Jan 2017 13:41:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O0Jw2rU1ZiL9+fcJlTART+aYrz/1HwgY/Fgyth0CmDE=; b=TGIHUfy6ExIQpyF0xp6mTOoZaP8dqRrKmIs7KCYw3lGa0ombdI7jT+XJq5ynbxNut3 A+GgepS3SaUCI2Y/K+jyUJ4q4Heawq876oRJESrS+2oji8F6NFUorVxiZ0Qt77u6V2CK ZpswbFLVakL8bnrOXOaLwyQhncvXmzjtGTdqerK8g8/2OtUdjTHUVauRuZtFAzOEdFLx KdL9Lw0tkezQIWAEC6kin/rpwTeG37ewe90SNmqldQupNnmwvBp3dA/0PLcPrZ1uqm9V ilj1itOhjpF3bG0djX5/h5t1CrrWOqIBOZf/uG8Oi7b+DpAzi4JfreKlmK61OnzX/uum edfA== X-Gm-Message-State: AIkVDXLvLvYdTI5cELEA7rQNAUgnSNfTkHe1zGFHDKiuhCSf2/ljCpLkHtwj1vw5fKOjB/nBE9BXP8YAdWk3FA== X-Received: by 10.200.41.73 with SMTP id z9mr17556251qtz.137.1485726058535; Sun, 29 Jan 2017 13:40:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.140.194 with HTTP; Sun, 29 Jan 2017 13:40:58 -0800 (PST) In-Reply-To: References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> From: Yao Qi Date: Sun, 29 Jan 2017 21:41:00 -0000 Message-ID: Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping To: Antoine Tremblay Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00639.txt.bz2 On Fri, Jan 27, 2017 at 6:24 PM, Antoine Tremblay wrote: > > Yao Qi writes: > >> On Fri, Jan 27, 2017 at 4:06 PM, Antoine Tremblay >> wrote: >> If emulation is complex, probably >> we can partially fix this problem by "always using 16-bit thumb instruct= ion >> if program is out of IT block". >> > > I would be against that since it would leave the feature partially > working and crashing the program when it fails... > > It would also be a regression compared to previous GDBServer. There won't be any regression. 16-bit thumb breakpoint works pretty well for any thumb instructions (16-bit and 32-bit) if program is out of IT bloc= k. The 32-bit thumb-2 breakpoint was added for single step IT block. > Also, IT blocks are a common place to have a breakpoint/tracepoint. > We don't change anything when setting breakpoint inside IT block. >>> I think it would be better to get the current single stepping working >>> with the stop all threads logic since GDBServer was working like that >>> when GDB was doing the single stepping anyway. This would fix the curre= nt >>> regression. >>> >>> Then work could be done to improve GDBServer to be better at >>> non-stopping. >>> >>> WDYT ? >>> >> >> Sounds like we are applying the ARM linux limitation to a general >> place. >> Other software single step targets may write breakpoint in atomic way, >> so we don't need to stop all threads. Even in -marm mode, we don't >> have to stop all threads on inserting breakpoints. > > Well ARM is the only software single stepping target, while I agreee > that we would be affecting general code, I think that since there is > no software single step breakpoint target that supports atomic > breakpoint writes at the moment it's normal that the run control > doesn't support that. No, ARM Linux ptrace POKETEXT is _atomic_ if the address is 4-byte aligned, so 32-bit arm breakpoint and 16-bit thumb breakpoint can be written atomically. 32-bit thumb-2 breakpoint can be written atomically too if the address is 4-byte aligned. The only problem we have is inserting a breakpoint on a 2-byte aligned 32-bit thumb-2 instruction inside IT block, we can not use neither 16-bit t= humb breakpoint nor 32-bit thumb breakpoint. Everything works fine in other cases. > > I don't count -marm as an arch since there no way to check that all the > program including shared libs etc is -marm, I don't think we could make > the distinction in GDBServer AFAIK. We can check with -mthumb. My hack in last email fixes fails in schedlock.exp in thumb mode. --=20 Yao (=E9=BD=90=E5=B0=A7)