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: Thu, 21 Feb 2013 13:40:00 -0000	[thread overview]
Message-ID: <512623BE.2030608@tilera.com> (raw)
In-Reply-To: <51244CBA.4000009@codesourcery.com>

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

On 02/20/2013 12:10 PM, Yao Qi wrote:
> Is it possible that the section layouts on two pages?  I mean, if is 
> possible that NEXT_ADDR is within section FOO and page A, but the end 
> of section FOO is within page A + 1.  If this is true, we need to 
> check to the min (page boundary, section boundary), otherwise, we 
> don't have to worry about it.

    sure, and I guess the page boundary check is for the risk that the 
next page is not in memory that need to be paged in.
    but some of the time, we just need to analyze a few instructions 
then we could get the result, so we only cross a page when necessary, 
but this do not make sense for disk file access.

    after a second think, I fell it's reasonable that 
"section_table_xfer_memory_partial" do not handle those gap between 
sections, because there is no bit on the disk file for those gap, while 
if the debuggee is loaded and under running, then target_read_memory 
will use ptrace to fetch runtime memory, then those gap has physical map 
in memory, and set to zero.

    for x86, this is a issue also. for a simple testcase

char *fmt = "x%d\n";
int main(int argc, char **argv)
{
         printf(fmt, argc);
         return 0;
}

gcc test.c
gdb a.out
(gdb) x/10 fmt
0x4005c0 <__dso_handle+8>:    174335352    Cannot access memory at 
address 0x4005c4
(gdb) b main
Breakpoint 1 at 0x4004e0
(gdb) r
Starting program: /home/jiwang/GDB-TEST/a.out
Breakpoint 1, 0x00000000004004e0 in main ()
(gdb) x/10 fmt
0x4005c0 <__dso_handle+8>:    174335352    0    990059265 44
0x4005d0:    4    -552    72    -236
0x4005e0:    112    -184

so, I think fix this issue by checking section boundary simultaneously 
is a bit strange, the clean and proper way is to stop skip_prologue 
analysis when the pc is in plt stub.

below is the old patch, any one comments on this?


gdb/ChangeLog:

        * tilegx-tdep.c (tilegx_skip_prologue): simplify the handling for
        plt stub.

-- 
Regards,
Jiong. Wang
Tilera Corporation.


[-- Attachment #2: 0001-xx.patch --]
[-- Type: text/x-patch, Size: 588 bytes --]

---
 gdb/tilegx-tdep.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gdb/tilegx-tdep.c b/gdb/tilegx-tdep.c
index 2c4e349..2452232 100644
--- a/gdb/tilegx-tdep.c
+++ b/gdb/tilegx-tdep.c
@@ -758,6 +758,10 @@ tilegx_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc)
         return max (start_pc, post_prologue_pc);
     }
 
+  /* for plt stub, just return the start pc */
+  if (in_plt_section (start_pc, NULL))
+    return start_pc;
+
   /* Otherwise, try to skip prologue the hard way.  */
   return tilegx_analyze_prologue (gdbarch,
 				  start_pc,
-- 
1.7.10.4


  reply	other threads:[~2013-02-21 13:40 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 [this message]
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=512623BE.2030608@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