From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2186 invoked by alias); 31 May 2012 10:48:06 -0000 Received: (qmail 2153 invoked by uid 22791); 31 May 2012 10:48:05 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-lb0-f169.google.com (HELO mail-lb0-f169.google.com) (209.85.217.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 31 May 2012 10:47:47 +0000 Received: by lbjn8 with SMTP id n8so857986lbj.0 for ; Thu, 31 May 2012 03:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.83.200 with SMTP id s8mr809122lby.13.1338461265998; Thu, 31 May 2012 03:47:45 -0700 (PDT) Received: by 10.152.128.42 with HTTP; Thu, 31 May 2012 03:47:45 -0700 (PDT) In-Reply-To: <4FC74796.5070504@redhat.com> References: <4FC74796.5070504@redhat.com> Date: Thu, 31 May 2012 10:48:00 -0000 Message-ID: Subject: Re: How to configure GDB for software single-stepping on an ARM remote stub From: Jonas Zaddach To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00156.txt.bz2 Thank you, that is exactly what I wanted :) I felt a bit stupid since I thought that there must be some configuration file for it ... A good way to make this configurable in my opinion would be to allow the remote stub to reply with an error to the step command, or query stepping support with a qStepping command, and then switch on software stepping when needed ... If you think other people are interested in that I can do a patch. On Thu, May 31, 2012 at 12:27 PM, Pedro Alves wrote: > On 05/31/2012 11:02 AM, Jonas Zaddach wrote: > >> Hi, >> >> I have written a remote stub for some ARM hardware that supports just >> memory breakpoints (the device does not have a hardware debugging >> unit). I figured out that I need single-stepping to go around >> breakpoints, > > > Or more fundamentally, for all stepping, right? > >> and that there is support for software single-stepping in >> the code ... but I have no idea on how to tell GDB that I want >> software single-stepping on my target. Can you give me a hint how to >> do it or where to look for documentation? > > > Unfortunately, GDB is not smart enough to figure out the target can't > single-step, and that it needs to do it itself with software > single-stepping. > The current way is that GDB hardcodes knowledge of when does the target > need it; it depends on architecture, for example, on ARM and MIPS, gdb > assumes the target can step, and then knows that if the target is running > Linux, it needs software stepping. =A0On other archs, knowing that no chip > was or will be built with hardware debugging smarts, GDB always uses > software stepping. =A0The simplest is to use a hack like below to force y= our > GDB to assume software stepping is necessary. =A0The best would be to make > GDB smarter. > > =A0gdb/arm-tdep.c | =A0 =A02 ++ > =A01 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c > index df5dea7..829cb5c 100644 > --- a/gdb/arm-tdep.c > +++ b/gdb/arm-tdep.c > @@ -10122,6 +10122,8 @@ arm_gdbarch_init (struct gdbarch_info info, struc= t gdbarch_list *arches) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_("arm_gdbarch_init: bad byte = order for float format")); > =A0 =A0 } > > + =A0set_gdbarch_software_single_step (gdbarch, arm_software_single_step); > + > =A0 /* On ARM targets char defaults to unsigned. =A0*/ > =A0 set_gdbarch_char_signed (gdbarch, 0); >