Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 (齐尧)


  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