From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10397 invoked by alias); 16 Jan 2004 14:15:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10388 invoked from network); 16 Jan 2004 14:15:39 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 16 Jan 2004 14:15:39 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id i0GEEuAO020135; Fri, 16 Jan 2004 14:14:56 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i0GEEud05631; Fri, 16 Jan 2004 14:14:56 GMT Message-Id: <200401161414.i0GEEud05631@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: Andrew Cagney , gdb-patches@sources.redhat.com, rearnsha@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: RFA/ARM: Switch mode when setting PC In-reply-to: Your message of "Fri, 16 Jan 2004 09:10:40 EST." <20040116141040.GA8134@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 2004 14:15:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-01/txt/msg00409.txt.bz2 > On Fri, Jan 16, 2004 at 12:43:46AM -0500, Andrew Cagney wrote: > > >This patch fixes several failures in virtfunc.exp for arm-sim/-mthumb. The > > >problem is that the non-virtual thunk for pDe->vg() is emitted in ARM mode > > >and called via _call_via_r2. But the rest of the program is Thumb mode, > > >and > > >nothing tells the simulator (or target; I haven't tested this on hardware > > >yet but I expect the same result) to switch to ARM. So it gets very > > >confused. > > > > > >This is somewhat suboptimal in that if you want, for some reason, to call > > >something marked as an ARM function with Thumb mode enabled you will have > > >to > > >set $ps yourself _after_ setting $pc. I think it's still a good idea, > > >though. OK? > > > > (sorry, but I don't understand that paragraph - doesn't that code set > > the $ps after setting the $pc?) > > Right. But if you want to start a Thumb function in ARM mode you'll > have to do: > (gdb) set $pc = start_of_function > (gdb) set $ps = $ps & ~0x20 > > > The ari contains this yellow card: > > > > write pc > > Replace write_pc() with get_frame_base_address or get_frame_id; at > > present the inferior function call code still uses this when doing a > > DECR_PC_AFTER_BREAK > > > > the concern is with the way write_pc is being called to perform two > > different operations: > > > > - decrement the pc just after the target stops > > Arrrg! > > - jump to a specific address > > As with an inferior function call or jump. > > > > I think it would be better to have two methods so that it's clear that > > this case only applies when doing a jump. > > Well, it'd be better to rip out the current DECR_PC_AFTER_BREAK and > handle it completely within the four (roughly) affected targets, > thereby removing the overloading of write_pc. IMVHO. > Unless the "Thumb bit" is being stripped out by GDB, then I suspect that this is a bug in the gdb/simulator binding layer. Any attempt to force the PC value by the debugger should be taken as a potential state change. If that is not happening, then all sorts of things may not work. I've suspected that there is a problem in the way that gdb drives the simulator for a while now. R.