This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Jun 22, 2016 at 8:04 PM, Maciej W. Rozycki <macro@imgtec.com> wrote:
>
>> 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?

On ARM target, instruction "blx rm" is generated for indirect call, and "rm" has
the target address, plus ISA bit if needed.  If the target function is ARM code,
"rm" has the target function address, otherwise, it has the thumb
target function
address with LSB set.  I want to make it clear that, although thumb function
symbol value has LSB set, which only indicates this is a thumb function, the
function address is still 2-byte aligned.  All these ISA bit set/clear
is managed
by LD.

However, LD doesn't need to handle the address reported in the run time.
When we set a breakpoint on a certain address in thumb code, the address
must be 2-byte aligned, and we get troubles on matching the reported address
with adjusted symbols (with LSB set).  I suspect the reported address on MIPS
has ISB bit set.

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

In my prototype GDB, it doesn't work either, because breakpoint is set at 2-byte
aligned address, but the LSB of address in line table is set.

>> 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 ...'?
>

Hmm, either is fine to me, so I don't mind changing it to kfail.

-- 
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]