From: Yao Qi <yao@codesourcery.com>
To: Jiong Wang <jiwang@tilera.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: Sat, 16 Feb 2013 04:50:00 -0000 [thread overview]
Message-ID: <511F0FE9.8030300@codesourcery.com> (raw)
In-Reply-To: <50F9664D.2090008@tilera.com>
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.
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?
--
Yao (é½å°§)
next prev parent reply other threads:[~2013-02-16 4:50 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 [this message]
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=511F0FE9.8030300@codesourcery.com \
--to=yao@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jiwang@tilera.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