From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104118 invoked by alias); 22 Jun 2016 19:05:03 -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 104106 invoked by uid 89); 22 Jun 2016 19:05:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=absence, our X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Jun 2016 19:04:56 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 621A6E37AF7F4; Wed, 22 Jun 2016 20:04:49 +0100 (IST) Received: from [10.20.78.208] (10.20.78.208) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Wed, 22 Jun 2016 20:04:51 +0100 Date: Wed, 22 Jun 2016 19:05:00 -0000 From: "Maciej W. Rozycki" To: Yao Qi CC: Subject: Re: [PATCH] Skip gdb.base/func-ptrs.exp in thumb mode In-Reply-To: <1465812702-22061-1-git-send-email-yao.qi@linaro.org> Message-ID: References: <1465812702-22061-1-git-send-email-yao.qi@linaro.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg00371.txt.bz2 On Mon, 13 Jun 2016, Yao Qi wrote: > This test case was added > https://sourceware.org/ml/gdb-patches/2014-10/msg00088.html to teach > GDB to treat ISA bit on MIPS. I thought we can do the same for ARM > thumb mode, but I failed to do so due to the difference of mips16 > and thumb. FWIW it looks like an ABI deficiency to me then, perhaps just in the debug support part. You ought to be able to make the same operations in GDB (e.g. function pointer assignments) as you do at the source level of your programming language (e.g. C), and yield the same results. Of course it doesn't have to be an ISA bit that guarantees consistency though. > As Maciej described in > https://sourceware.org/ml/gdb-patches/2012-05/msg00515.html > "Any instruction executed at an even address is interpreted as a > standard MIPS instruction (the address still has to have its bit > #1 clear), any instruction executed at an odd address is > interpreted as a MIPS16 instruction.", it is natural to have > instructions at odd addresses, see the disassembly in current GDB > for mips16 code, > > (gdb) disassemble incr > Dump of assembler code for function incr: > 0x0040055d <+0>: save a0,32,ra,s1 > 0x00400561 <+4>: addiu s1,sp,16 > 0x00400563 <+6>: jal 0x400551 > > However, arm does the trick by using the right branch instruction > (bx and blx) together with setting the LSB in the target address. So how does this work for indirect calls, such as ones made via function pointers, with the ARM target? With dynamic reassignment such a pointer can change at the run time and with mixed code it can point to regular ARM code sometimes and at other times it can point to Thumb code, still within the same execution of a program. Can't GDB reproduce the same actions? What do GCC/GAS/LD do with function pointer assignments that GDB can't? > The instructions are still at even addresses. > > Due to this difference on address, we have troubles mapping stop > address to line table on thumb mode, because we've set the LSB in > address in line table, as what we did for mips, but the stop address > reported by the hardware is still an even one, so we'll get a fail, > > Breakpoint 3, 0x00008604 in incr (i=-1) at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/func-ptrs.c:37^M > 37 {^M > (gdb) FAIL: gdb.base/func-ptrs.exp: continue to incr, first time > > the hex 0x00008604 is unexpected by the test, because it is not the > starting address of line table entry, so the hex is printed, > > 3 37 0x00000000000085fd > 4 38 0x0000000000008605 > 5 39 0x0000000000008609 > > In fact, my prototype GDB works well except on this address-line > mapping. I didn't try to tweak target to report the address with > LSB set, because it makes no sense on ARM thumb mode. Hmm, so how does breakpoint matching work in the absence of function pointer reassignment? > diff --git a/gdb/testsuite/gdb.base/func-ptrs.exp > b/gdb/testsuite/gdb.base/func-ptrs.exp > index a3b55a8748..b3ea1ce 100644 > --- a/gdb/testsuite/gdb.base/func-ptrs.exp > +++ b/gdb/testsuite/gdb.base/func-ptrs.exp > @@ -24,6 +24,10 @@ if { ![runto_main] } { > return -1 > } > > +if { 0 == [get_integer_valueof "supported" "0"] } { > + unsupported "function pointer assignment is not supported" > + return 1 > +} > > # First set our breakpoints. > Not `kfail ...'? Maciej