Re: [PATCH] Skip gdb.base/func-ptrs.exp in thumb mode

["Maciej W. Rozycki" <macro at imgtec dot com>]

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 <sentinel>
> 
> 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