From: Jiong Wang <jiwang@tilera.com>
To: Pedro Alves <palves@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
<gdb-patches@sourceware.org>, Walter Lee <walt@tilera.com>
Subject: Re: [RFC/TileGX 2/6] simplify the handling of skip prologue for plt stub
Date: Fri, 15 Feb 2013 03:22:00 -0000 [thread overview]
Message-ID: <511DA9D9.7090202@tilera.com> (raw)
In-Reply-To: <50F9868C.6030905@redhat.com>
On 01/19/2013 01:29 AM, Pedro Alves wrote:
> 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.
Ping,
is this patch OK to commit?
---
Regards,
Jiong
>
>> for other targets, like x86, I have done a brief exploration, seems they do not have large prefetch window
>
>
--
Regards,
Jiong. Wang
Tilera Corporation.
next prev parent reply other threads:[~2013-02-15 3:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 9:25 Jiong Wang
2013-01-18 13:15 ` Joel Brobecker
2013-01-18 15:12 ` Jiong Wang
2013-01-18 17:30 ` Pedro Alves
2013-02-15 3:22 ` Jiong Wang [this message]
2013-02-16 4:50 ` Yao Qi
2013-02-20 2:49 ` Jiong Wang
2013-02-20 4:11 ` Yao Qi
2013-02-21 13:40 ` Jiong Wang
2013-03-01 10:35 ` Jiong Wang
2013-03-01 11:31 ` Pedro Alves
2013-03-01 14:08 ` Jiong Wang
2013-03-01 15:59 ` Pedro Alves
2013-03-02 1:40 ` [COMMITTED][RFC/TileGX " Jiong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511DA9D9.7090202@tilera.com \
--to=jiwang@tilera.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=walt@tilera.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox