From: Jiong Wang <jiwang@tilera.com>
To: Yao Qi <yao@codesourcery.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: Wed, 20 Feb 2013 02:49:00 -0000 [thread overview]
Message-ID: <51243991.4040304@tilera.com> (raw)
In-Reply-To: <511F0FE9.8030300@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
> On 01/18/2013 11:12 PM, Jiong Wang wrote:
>> 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.
>
> Wang Jiong,
>
> AFAICT, the root cause of this problem is GDB prefetches too much
> contents in one time that exceeds the boundary of a section.
>
> At the beginning of tilegx_analyze_prologue, I notice this comment
>
> /* To cut down on round-trip overhead, we fetch multiple bundles
> at once. These variables describe the range of memory we have
> prefetched. */
>
> Can't we fetch one bundle in one time? Fetching multiple bundles
> causes this problem, so we have to disable it.
I think we should keep prefetching multiple instruction bundles to cut
down on round-trip overhead, just as the comment explained.
>
> Even we still decide to use fetching multiple bundle in one time, we
> should take care of the boundary and existing code does this, see this
> comment,
>
> /* Figure out how many bytes to fetch. Don't span a page
> boundary since that might cause an unnecessary memory
> error. */
>
> Looks existing code takes care of not crossing the page boundary,
> similarly, we should also take care of not crossing the section
> boundary. What do you think?
thanks, check section boundary looks better, and I think we can remove
the old page boundary check, please CR the new patch
gdb/ChangeLog:
* tilegx-tdep.c (tilegx_skip_prologue): when prefetching
multiple instruction bundles, check section boundary
instead of page boundary.
Regards,
Jiong
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: section.patch.patch --]
[-- Type: text/plain; charset="gb18030"; name="section.patch.patch", Size: 1204 bytes --]
---
gdb/tilegx-tdep.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gdb/tilegx-tdep.c b/gdb/tilegx-tdep.c
index 2c4e349..f8a6255 100644
--- a/gdb/tilegx-tdep.c
+++ b/gdb/tilegx-tdep.c
@@ -424,15 +424,18 @@ tilegx_analyze_prologue (struct gdbarch* gdbarch,
/* Retrieve the next instruction. */
if (next_addr - instbuf_start >= instbuf_size)
{
- /* Figure out how many bytes to fetch. Don't span a page
+ /* Figure out how many bytes to fetch. Don't span a section
boundary since that might cause an unnecessary memory
error. */
- unsigned int size_on_same_page = 4096 - (next_addr & 4095);
+ unsigned int size_on_same_section;
+ struct obj_section *s = find_pc_section(next_addr);
+ gdb_assert(s != NULL);
+ size_on_same_section =
+ s->the_bfd_section->vma + s->the_bfd_section->size - next_addr;
instbuf_size = sizeof instbuf;
- if (instbuf_size > size_on_same_page)
- instbuf_size = size_on_same_page;
+ if (instbuf_size > size_on_same_section)
+ instbuf_size = size_on_same_section;
instbuf_start = next_addr;
status = safe_frame_unwind_memory (next_frame, instbuf_start,
--
1.8.1
next prev parent reply other threads:[~2013-02-20 2:49 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
2013-02-16 4:50 ` Yao Qi
2013-02-20 2:49 ` Jiong Wang [this message]
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=51243991.4040304@tilera.com \
--to=jiwang@tilera.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=walt@tilera.com \
--cc=yao@codesourcery.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