From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6321 invoked by alias); 23 Jan 2002 12:27:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6259 invoked from network); 23 Jan 2002 12:27:18 -0000 Received: from unknown (HELO atlas.acter.ch) (212.126.160.108) by sources.redhat.com with SMTP; 23 Jan 2002 12:27:18 -0000 Received: (from avbidder@localhost) by atlas.acter.ch (8.11.6/8.11.6/SuSE Linux 0.5) id g0NCRFJ11435; Wed, 23 Jan 2002 13:27:15 +0100 X-Authentication-Warning: atlas.acter.ch: avbidder set sender to avbidder@acter.ch using -f Subject: Re: [arm] force gdb into disassembling in thumb (arm) mode From: Adrian von Bidder To: Richard.Earnshaw@arm.com Cc: gdb mailing list In-Reply-To: <200201231044.KAA11674@cam-mail2.cambridge.arm.com> References: <200201231044.KAA11674@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/0.99.2 (Preview Release) Date: Wed, 23 Jan 2002 04:27:00 -0000 Message-Id: <1011788835.10900.8.camel@atlas> Mime-Version: 1.0 X-SW-Source: 2002-01/txt/msg00259.txt.bz2 On Wed, 2002-01-23 at 11:44, Richard Earnshaw wrote: > Hmm, a quick test on the CVS sources shows that using an odd address will= =20 > DTRT (ie force thumb mode but then round the address down); I can't see=20 > anything from the commit log that might have changed. The key is this=20 > line of code: >=20 > gdb/arm-tdep.c/gdb_print_insn_arm() > memaddr =3D UNMAKE_THUMB_ADDR (memaddr); >=20 > Which strips off the thumb bit before actually loading the half-word. Sorry, my fault, mostly - Memory didn't contain what I thought it did, which did confuse me, together with the memory addresses on the disassembler output having the lsb set. But you're right, the data actually displayed is at the right addresses. But then I should be able to do "display/i $pc+1" but this has no effect (neither does disp/i $pc|1): (gdb) disp/i $pc+1 4: x/i $pc + 1 0xf54: undefined (is the same as plain disp/i $pc - it tries to decode arm). while=20 (gdb) x/i $pc+1 0xf55: push {r4, r5, r7, lr} shows the thumb instruction really at 0xf54. greets from Z=FCrich -- vbi