From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [RFC] FRV: Skip call to __main in main()
Date: Sat, 15 Nov 2008 18:40:00 -0000 [thread overview]
Message-ID: <20081114161353.3495cc1e@mesquite.lan> (raw)
For frv-elf (and perhaps other frv targets too), GCC now emits a call
to __main() in the prologue of main(). The patch below adds code to
test for this call and to skip over it so that placing a breakpoint in
main() will correctly cause the breakpoint to be placed on the first
statement instead of in the prologue.
I submitted a similar patch for PPC a while back and was asked to fix
the hard-coded constants. However, the convention in frv-tdep.c seems
to be to use hard-coded constants preceded by a comment block showing
how the constant was derived. I chose to follow that convention in
this patch.
Comments?
* frv-tdep.c (frv_skip_main_prologue): New function.
(frv_gdbarch_init): Register frv_skip_main_prologue.
Index: frv-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/frv-tdep.c,v
retrieving revision 1.122
diff -u -p -r1.122 frv-tdep.c
--- frv-tdep.c 11 Sep 2008 14:23:15 -0000 1.122
+++ frv-tdep.c 14 Nov 2008 22:40:25 -0000
@@ -999,6 +999,85 @@ frv_skip_prologue (struct gdbarch *gdbar
}
+/* Examine the instruction pointed to by PC. If it corresponds to
+ a call to __main, return the address of the next instruction.
+ Otherwise, return PC. */
+
+static CORE_ADDR
+frv_skip_main_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
+{
+ gdb_byte buf[4];
+ unsigned long op;
+ CORE_ADDR orig_pc = pc;
+
+ if (target_read_memory (pc, buf, 4))
+ return pc;
+ op = extract_unsigned_integer (buf, 4);
+
+ /* In PIC code, GR15 may be loaded from some offset off of FP prior
+ to the call instruction.
+
+ Skip over this instruction if present. It won't be present in
+ non-PIC code, and even in PIC code, it might not be present.
+ (This is due to the fact that GR15, the FDPIC register, already
+ contains the correct value.)
+
+ The general form of the LDI is given first, followed by the
+ specific instruction with the GRi and GRk filled in as FP and
+ GR15.
+
+ ldi @(GRi, d12), GRk
+ P KKKKKK 0110010 IIIIII SSSSSSSSSSSS = 0x00c80000
+ 0 000000 1111111 000000 000000000000 = 0x01fc0000
+ . . . . . . . .
+ ldi @(FP, d12), GR15
+ P KKKKKK 0110010 IIIIII SSSSSSSSSSSS = 0x1ec82000
+ 0 001111 1111111 000010 000000000000 = 0x7ffff000
+ . . . . . . . . */
+
+ if ((op & 0x7ffff000) == 0x1ec82000)
+ {
+ pc += 4;
+ if (target_read_memory (pc, buf, 4))
+ return orig_pc;
+ op = extract_unsigned_integer (buf, 4);
+ }
+
+ /* The format of an FRV CALL instruction is as follows:
+
+ call label24
+ P HHHHHH 0001111 LLLLLLLLLLLLLLLLLL = 0x003c0000
+ 0 000000 1111111 000000000000000000 = 0x01fc0000
+ . . . . . . . .
+
+ where label24 is constructed by concatenating the H bits with the
+ L bits. The call target is PC + (4 * sign_ext(label24)). */
+
+ if ((op & 0x01fc0000) == 0x003c0000)
+ {
+ LONGEST displ;
+ CORE_ADDR call_dest;
+ struct minimal_symbol *s;
+
+ displ = ((op & 0xfe000000) >> 7) | (op & 0x0003ffff);
+ if ((displ & 0x00800000) != 0)
+ displ |= ~((LONGEST) 0x00ffffff);
+
+ call_dest = pc + 4 * displ;
+ s = lookup_minimal_symbol_by_pc (call_dest);
+
+ if (s != NULL
+ && SYMBOL_LINKAGE_NAME (s) != NULL
+ && strcmp (SYMBOL_LINKAGE_NAME (s), "__main") == 0)
+ {
+ pc += 4;
+ return pc;
+ }
+ }
+ return orig_pc;
+}
+
+
static struct frv_unwind_cache *
frv_frame_unwind_cache (struct frame_info *this_frame,
void **this_prologue_cache)
@@ -1501,6 +1580,7 @@ frv_gdbarch_init (struct gdbarch_info in
set_gdbarch_pseudo_register_write (gdbarch, frv_pseudo_register_write);
set_gdbarch_skip_prologue (gdbarch, frv_skip_prologue);
+ set_gdbarch_skip_main_prologue (gdbarch, frv_skip_main_prologue);
set_gdbarch_breakpoint_from_pc (gdbarch, frv_breakpoint_from_pc);
set_gdbarch_adjust_breakpoint_address
(gdbarch, frv_adjust_breakpoint_address);
next reply other threads:[~2008-11-14 23:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-15 18:40 Kevin Buettner [this message]
2008-11-15 21:13 ` Daniel Jacobowitz
2008-11-20 1:58 ` Kevin Buettner
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=20081114161353.3495cc1e@mesquite.lan \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
/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