[RFC/TileGX 2/6] simplify the handling of skip prologue for plt stub
Pedro Alves
palves@redhat.com
Fri Jan 18 17:30:00 GMT 2013
On 01/18/2013 03:12 PM, Jiong Wang wrote:
>
>>> for tilegx, when skip prologue, if the start_pc is a plt stub address, then
>>> stop to go further, just return the start_pc.
>>>
>>> gdb/ChangeLog:
>>>
>>> * tilegx-tdep.c (tilegx_skip_prologue): simplify the handling for
>>> plt stub.
>> Can you provide an example where this becomes necessary? I don't
>> see a problem with the patch per se, but I don't remember seeing
>> other ports doing this...
>>
> yes, there are some tricky thing.
>
> for the simple hello.c
>
> #include <stdio.h>
> int main(int argc, char **argv)
> {
> printf("hello, %d\n", argc);
> return 0
> }
>
> without this patch
> ===
> -bash-4.1$ gcc -o hello.tile hello.c
> -bash-4.1$ ./gdb hello.tile
> (gdb) b printf
> Error accessing memory address 0x10a40: Success.
>
> after this patch
> ===
> (gdb) b printf
> Breakpoint 1 at 0x10a40
>
>
> this is because tilegx skip_prologue will invoke tilegx_analyze_prologue, which
> will prefetch 32*8 bytes.
>
> while for when the address is in plt stub, you can see it near the eh_frame_hdr section
>
> [14] .plt 0000000000010a00 000a00 0000a0 28 AX 0 0 64
> ...
> [16] .eh_frame_hdr 0000000000010ac0 000ac0 000024 00 A 0 0 4
> [17] .eh_frame 0000000000010ae8 000ae8 0000b4 00 A 0 0 8
>
> the .eh_frame_hdr aligns to 4, there is a hole between .eh_frame_hdr and .eh_frame, and this
> will cause trouble for section_table_xfer_memory_partial.
>
> after fetch memory starting from 0x10ac0 to 0x10ae4, then the memaddr will be 0x10ae4 in section_table_xfer_memory_partial,
> while this function did not consider this hole situation, so goes to line 666, error occured.
Right. It's this issue that needs solving. Otherwise you're just
papering over the problem.
>
> for other targets, like x86, I have done a brief exploration, seems they do not have large prefetch window
--
Pedro Alves
More information about the Gdb-patches
mailing list