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


  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