From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30236 invoked by alias); 20 Aug 2010 11:45:25 -0000 Received: (qmail 30226 invoked by uid 22791); 20 Aug 2010 11:45:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.17.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Aug 2010 11:45:17 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id o7KBjEA7020618 for ; Fri, 20 Aug 2010 11:45:14 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7KBjEge4010094 for ; Fri, 20 Aug 2010 13:45:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o7KBjDlA005718 for ; Fri, 20 Aug 2010 13:45:14 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o7KBjCQ0005686; Fri, 20 Aug 2010 13:45:12 +0200 Message-Id: <201008201145.o7KBjCQ0005686@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 20 Aug 2010 13:45:12 +0200 Subject: Re: [rfc] Strip Thumb bit from PC returned by arm_get_longjmp_target To: matthew.gretton-dann@arm.com (Matthew Gretton-Dann) Date: Fri, 20 Aug 2010 11:45:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <1282294368.7290.23.camel@e102319-lin.cambridge.arm.com> from "Matthew Gretton-Dann" at Aug 20, 2010 09:52:48 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-08/txt/msg00367.txt.bz2 Matthew Gretton-Dann wrote: > Using two gdbarch objects seems reasonable, and also extends nicely if > we decide to support the ThumbEE ISA as well (which is intended for JITs > so gdb is unlikely to have any debug info to help it along). > > However, I am concerned about a couple of things: > > 1) What changes does this make to the user interface? Can I user still > say 'break main' and gdb will determine ARM or Thumb automatically? That's the one piece I mentioned where common code support will have to be added. Basically, we'd need a gdbarch callback that gets the gdbarch the breakpoint was parsed in, and the breakpoint's PC address (plus address space, eventually), and would return the gdbarch to be used to handle that particular breakpoint location. > Will the user still be able to see a backtrace with some frames in ARM > state and some in Thumb? This mechanism already exists and is used for Cell debugging today: we can install a frame architecture unwinder that, given a frame, returns the architecture to be used for the next-outer frame. > 2) This moves the decision what instruction set state a breakpoint is > targetting from the time we set the breakpoint to the time the > breakpoint is requested by the user. Is this a reasonable thing to do? > I think so - I don't expect code to change under the debugger's feet, so > making the decision when we have most information available (at > breakpoint request time) is the correct way to go. Actually, it would move the decision to the point where the breakpoint location structure is allocated. This happens when the breakpoint is initially requested, yes, but breakpoint locations are also recomputed every time the available debug information changes (e.g. shared libraries are loaded/unloaded). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com