Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jiong Wang <jiwang@tilera.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <yao@codesourcery.com>,
	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, 01 Mar 2013 14:08:00 -0000	[thread overview]
Message-ID: <5130B63A.1060304@tilera.com> (raw)
In-Reply-To: <51309167.5050608@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On 03/01/2013 07:30 PM, Pedro Alves wrote
> I do agree that trying to find the end of the prologue of a plt stub is futile.  We know plt stubs
> aren't "normal" functions, and don't have prologues.
>
> But, I do think the prologue analyzer still has a problem.  You should see this
> same issue with any small normal function (with no debug info) that happens to
> end up close enough to the end of its section.

   I agree, but normally there will be crtn* files which will placed 
after the noraml
function, so that the distance to the section with different alignment, 
for example .eh_frame_hdr,
will be long enough to prevent this happen.

>
> I suggest limiting the end address of the analysis with something like
> in tilegx_skip_prologue
>
> + /* Don't straddle a section boundary.  */
> + s = find_pc_section (start_pc);
> + end_pc = start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES;
> + if (s != NULL)
> +   end_pc = min (end_pc, obj_section_endaddr (s));
>
>    return tilegx_analyze_prologue (gdbarch,
> 				  start_pc,
> -				  start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES,
> +				  end_pc,
>
> and also, make tilegx_analyze_prologue never touch memory
> over end_addr.  It doesn't seem to take that care currently?
    I think this fix make sense, and tilegx_analyze_prologue has glitch, 
it will ignore "end_pc" to some extent.
  the prefetch buffer in tilegx_analyze_prologue should consider the end_pc.

    I have tested the new patch by rerun dejagnu, please review, thanks.

    gdb/ChangeLog:

         * tilegx-tdep.c (tilegx_analyze_prologue): Improve the evaluation
         of "instbuf_size".
         (tilegx_skip_prologue): Improve the evaluation of the end address
         for prologue analyze.

-- 
Regards,
Jiong. Wang
Tilera Corporation.


[-- Attachment #2: new.patch --]
[-- Type: text/x-patch, Size: 1471 bytes --]

---
 gdb/tilegx-tdep.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/gdb/tilegx-tdep.c b/gdb/tilegx-tdep.c
index f45c20f..b398507 100644
--- a/gdb/tilegx-tdep.c
+++ b/gdb/tilegx-tdep.c
@@ -433,6 +433,8 @@ tilegx_analyze_prologue (struct gdbarch* gdbarch,
 
 	  if (instbuf_size > size_on_same_page)
 	    instbuf_size = size_on_same_page;
+
+	  instbuf_size = min (instbuf_size, (end_addr - next_addr));
 	  instbuf_start = next_addr;
 
 	  status = safe_frame_unwind_memory (next_frame, instbuf_start,
@@ -745,7 +747,8 @@ tilegx_analyze_prologue (struct gdbarch* gdbarch,
 static CORE_ADDR
 tilegx_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc)
 {
-  CORE_ADDR func_start;
+  CORE_ADDR func_start, end_pc;
+  struct obj_section *s = NULL;
 
   /* This is the preferred method, find the end of the prologue by
      using the debugging information.  */
@@ -758,10 +761,16 @@ tilegx_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc)
         return max (start_pc, post_prologue_pc);
     }
 
+  /* Don't straddle a section boundary.  */
+  s = find_pc_section (start_pc);
+  end_pc = start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES;
+  if (s != NULL)
+    end_pc = min (end_pc, obj_section_endaddr (s));
+
   /* Otherwise, try to skip prologue the hard way.  */
   return tilegx_analyze_prologue (gdbarch,
 				  start_pc,
-				  start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES,
+				  end_pc,
 				  NULL, NULL);
 }
 

  reply	other threads:[~2013-03-01 14:08 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
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 [this message]
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=5130B63A.1060304@tilera.com \
    --to=jiwang@tilera.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --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