* [PATCH] add 'rs6000_in_function_epilogue_p()'
@ 2005-11-30 23:56 Paul Gilliam
2005-12-01 5:21 ` Jim Blandy
2005-12-02 1:13 ` Jim Blandy
0 siblings, 2 replies; 39+ messages in thread
From: Paul Gilliam @ 2005-11-30 23:56 UTC (permalink / raw)
To: gdb-patches
This patch fixes a problem when watching local variables on PowerPC.
Here is a reference from the gdb mailing list:
http://sourceware.org/ml/gdb/2005-11/msg00602.html
I know the patch uses a depreciated function and I am open to ideas.
Here is a reference from the gdb mailing list about ideas to avoid using the depreciated function:
http://sourceware.org/ml/gdb/2005-11/msg00623.html
I wanted to submit this patch as a starting point, but if it is acceptable, I'll commit it.
2005-11-30 Paul Gilliam <pgilliam@us.ibm.com>
* rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()'
and put it into the architecture vector.
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.248
diff -a -u -p -r1.248 rs6000-tdep.c
--- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248
+++ rs6000-tdep.c 30 Nov 2005 18:59:27 -0000
@@ -502,6 +502,63 @@ rs6000_skip_prologue (CORE_ADDR pc)
return pc;
}
+static int
+insn_changes_sp(unsigned long insn)
+{
+ int opcode = (insn>>26) & 0x03f;
+ int sd = (insn>>21) & 0x01f;
+ int a = (insn>>16) & 0x01f;
+ int b = (insn>>11) & 0x01f;
+ int subcode = (insn>> 1) & 0x3ff;
+ int rc = insn & 0x001;
+
+ if (opcode == 31 && subcode == 444 && a == 1)
+ return 1; /* mr R1,Rn */
+ if (opcode == 14 && sd == 1)
+ return 1; /* addi R1,Rn,simm */
+ if (opcode == 58 && sd == 1)
+ return 1; /* ld R1,ds(Rn) */
+
+ return 0;
+}
+
+/* Return true if we are in the functin's epilogue, i.e. after the
+ instruction that destroyed the function's stack frame. */
+static int
+rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc)
+{
+ bfd_byte insn_buf[PPC_INSN_SIZE];
+ CORE_ADDR scan_pc, func_addr, func_end;
+ unsigned long insn;
+
+ /* Find the search limits. */
+ if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end))
+ return 0;
+
+ /* Scan forward untill next 'blr'. */
+ for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE)
+ {
+ if (deprecated_read_memory_nobpt (scan_pc, insn_buf, PPC_INSN_SIZE))
+ return 0;
+ insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE);
+ if (insn == 0x4e800020) break;
+ if (insn_changes_sp(insn))
+ return 0;
+ }
+
+ /* Scan backward untill adjustment to stack pointer (R1). */
+ for (scan_pc=pc-PPC_INSN_SIZE; scan_pc>=func_addr; scan_pc-=PPC_INSN_SIZE)
+ {
+ if (deprecated_read_memory_nobpt (scan_pc, insn_buf, PPC_INSN_SIZE))
+ return 0;
+ insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE);
+ if (insn_changes_sp(insn))
+ return 1;
+ }
+
+ return 0;
+}
+
/* Fill in fi->saved_regs */
@@ -3342,6 +3399,8 @@ rs6000_gdbarch_init (struct gdbarch_info
set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address);
set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue);
+ set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p);
+
set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc);
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-11-30 23:56 [PATCH] add 'rs6000_in_function_epilogue_p()' Paul Gilliam @ 2005-12-01 5:21 ` Jim Blandy 2005-12-01 18:27 ` Paul Gilliam 2005-12-02 1:13 ` Jim Blandy 1 sibling, 1 reply; 39+ messages in thread From: Jim Blandy @ 2005-12-01 5:21 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches I'm not objecting to the patch, but following the links to the other messages I didn't really see an explanation as to how incorrectly recognizing the prologue causes the watchpoints to be deleted early. I assume we're talking about a case like: - we're in some function foo - we set a watchpoint on one of its local variables - we step through a call from foo to bar - as we exit bar, the watchpoint gets deleted, even though it's in the frame we're returning to, not the frame that is exiting. Is that right? How does correctly recognizing the prologue fix this? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-01 5:21 ` Jim Blandy @ 2005-12-01 18:27 ` Paul Gilliam 2005-12-01 20:14 ` Paul Gilliam 0 siblings, 1 reply; 39+ messages in thread From: Paul Gilliam @ 2005-12-01 18:27 UTC (permalink / raw) To: gdb-patches; +Cc: Jim Blandy, gdb-patches On Wednesday 30 November 2005 21:21, Jim Blandy wrote: > I'm not objecting to the patch, but following the links to the other > messages I didn't really see an explanation as to how incorrectly > recognizing the prologue causes the watchpoints to be deleted early. > I assume we're talking about a case like: > - we're in some function foo > - we set a watchpoint on one of its local variables > - we step through a call from foo to bar > - as we exit bar, the watchpoint gets deleted, even though it's in the > frame we're returning to, not the frame that is exiting. > > Is that right? How does correctly recognizing the prologue fix this? > > You have it, that's exactly what's going on. The reason the watchpoint gets deleted when exiting bar is that 'watchpoint_check' ("breakpoint.c":2480) thinks that the watched variable is out of scope. It thinks that because once the stack pointer has been diddled with in the functions epilogue, 'frame_find_by_id' ("./frame.c":394) is unable to find frame where the variable is active. It is unable to do so because when scanning through the frames, 'get_frame_id' ("./frame.c":333) returns a frame_id with the correct 'stack_addr' but with the wrong 'code_addr'. The 'code_addr' is for the function being exited instead of the function being returned to. When the frame where the variable is active can not be found, 'gdbarch_in_function_epilogue_p' is called to see if execution is in an epilogue. If it is 'watchpoint_check' just returns 'no change'. Once execution gets out of the epilogue by returning, 'get_frame_id' does the right thing again and everything is good. The default 'gdbarch_in_function_epilogue_p' always just says no. By defining 'rs6000_in_function_epilogue_p' and puting it's address into the arch. vector, the correct determination is made and the bug is fixed. -=# Paul #=- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-01 18:27 ` Paul Gilliam @ 2005-12-01 20:14 ` Paul Gilliam 0 siblings, 0 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-01 20:14 UTC (permalink / raw) To: gdb-patches; +Cc: Jim Blandy, gdb-patches On Wednesday 30 November 2005 21:21, Jim Blandy wrote: > I'm not objecting to the patch, but following the links to the other > messages I didn't really see an explanation as to how incorrectly > recognizing the prologue causes the watchpoints to be deleted early. > I assume we're talking about a case like: > - we're in some function foo > - we set a watchpoint on one of its local variables > - we step through a call from foo to bar > - as we exit bar, the watchpoint gets deleted, even though it's in the > frame we're returning to, not the frame that is exiting. > > Is that right? How does correctly recognizing the prologue fix this? > > You have it, that's exactly what's going on. The reason the watchpoint gets deleted when exiting bar is that 'watchpoint_check' ("breakpoint.c":2480) thinks that the watched variable is out of scope. It thinks that because once the stack pointer has been diddled with in the functions epilogue, 'frame_find_by_id' ("./frame.c":394) is unable to find frame where the variable is active. It is unable to do so because when scanning through the frames, 'get_frame_id' ("./frame.c":333) returns a frame_id with the correct 'stack_addr' but with the wrong 'code_addr'. The 'code_addr' is for the function being exited instead of the function being returned to. When the frame where the variable is active can not be found, 'gdbarch_in_function_epilogue_p' is called to see if execution is in an epilogue. If it is 'watchpoint_check' just returns 'no change'. Once execution gets out of the epilogue by returning, 'get_frame_id' does the right thing again and everything is good. The default 'gdbarch_in_function_epilogue_p' always just says no. By defining 'rs6000_in_function_epilogue_p' and puting it's address into the arch. vector, the correct determination is made and the bug is fixed. -=# Paul #=- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-11-30 23:56 [PATCH] add 'rs6000_in_function_epilogue_p()' Paul Gilliam 2005-12-01 5:21 ` Jim Blandy @ 2005-12-02 1:13 ` Jim Blandy 2005-12-02 1:23 ` Daniel Jacobowitz ` (3 more replies) 1 sibling, 4 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-02 1:13 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches Paul wanted to fast-track this patch, in hopes it could get into the 6.4 release. Joel, what are your thoughts? I think the best alternative to deprecated_read_memory_nobpt would be to actually call current_frame (this will be cheap, since we just called it in watchpoint_check, before calling gdbarch_in_function_epilogue_p) and then call safe_frame_unwind_memory. Whatever we do immediately, the underlying cause here is that unwinding isn't working at every instruction. If it were, then the call to frame_find_by_id would find the frame containing the watched variable, and watchpoint_check would correctly conclude that the variable was still in scope. Paul, does your test program have Dwarf CFI for the functions in question? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 1:13 ` Jim Blandy @ 2005-12-02 1:23 ` Daniel Jacobowitz 2005-12-02 20:12 ` Paul Gilliam 2005-12-02 4:02 ` Joel Brobecker ` (2 subsequent siblings) 3 siblings, 1 reply; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 1:23 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches On Thu, Dec 01, 2005 at 05:07:24PM -0800, Jim Blandy wrote: > Paul wanted to fast-track this patch, in hopes it could get into the > 6.4 release. Joel, what are your thoughts? I'm opposed. The patch is a serious hack - it assumes that the exit of the function is near the end of the function - and I think we need to think about the underlying issues a bit. It's also for a very minor bug. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 1:23 ` Daniel Jacobowitz @ 2005-12-02 20:12 ` Paul Gilliam 2005-12-02 20:17 ` Paul Gilliam 2005-12-03 3:05 ` Jim Blandy 0 siblings, 2 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-02 20:12 UTC (permalink / raw) To: gdb-patches; +Cc: Daniel Jacobowitz, Jim Blandy, gdb-patches On Thursday 01 December 2005 17:17, Daniel Jacobowitz wrote: > On Thu, Dec 01, 2005 at 05:07:24PM -0800, Jim Blandy wrote: > > Paul wanted to fast-track this patch, in hopes it could get into the > > 6.4 release. Joel, what are your thoughts? > > I'm opposed. The patch is a serious hack - it assumes that the exit of > the function is near the end of the function - and I think we need to > think about the underlying issues a bit. It's also for a very minor > bug. > This patch does *not* assume that the exit of the function is near the end of the function. It's more/less of a hack than that! Here is the 'algorithm': 1) scan forward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. b) Stop scanning if you find a return instruction or reach the end of the function. 2) scan backward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. b) Stop scanning if you reach the beginning of the function. Some other points: * The PowerPC would not be the only architecture that uses 'gdbarch_in_function_epilogue_p()'. * Danial may characterize the inability to watch a local variable as a very minor bug, but if a user (we have one) is so desperate with a bug of their own that they see *software* watchpoints as a needed tool, I don't think they would characterize this is "very minor". 8-) * I know that this is a hack. It really is a fall-back-hack, as Jim Blandly aluded to in his posting: http://sourceware.org/ml/gdb-patches/2005-12/msg00028.html * If the 'underlying cause' Jim refers to gets fixed, the hack will no longer be executed and it could be removed, or it could stay. * I would prefer the 'right' fix and will presue it, but for right now, this patch 'fixes' a bug and all though it's a hack, it is isolated and easly addressed once the 'right' fix is found. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 20:12 ` Paul Gilliam @ 2005-12-02 20:17 ` Paul Gilliam 2005-12-03 3:05 ` Jim Blandy 1 sibling, 0 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-02 20:17 UTC (permalink / raw) To: gdb-patches; +Cc: Daniel Jacobowitz, Jim Blandy, gdb-patches On Thursday 01 December 2005 17:17, Daniel Jacobowitz wrote: > On Thu, Dec 01, 2005 at 05:07:24PM -0800, Jim Blandy wrote: > > Paul wanted to fast-track this patch, in hopes it could get into the > > 6.4 release. Joel, what are your thoughts? > > I'm opposed. The patch is a serious hack - it assumes that the exit of > the function is near the end of the function - and I think we need to > think about the underlying issues a bit. It's also for a very minor > bug. > This patch does *not* assume that the exit of the function is near the end of the function. It's more/less of a hack than that! Here is the 'algorithm': 1) scan forward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. b) Stop scanning if you find a return instruction or reach the end of the function. 2) scan backward from the point of execution: a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. b) Stop scanning if you reach the beginning of the function. Some other points: * The PowerPC would not be the only architecture that uses 'gdbarch_in_function_epilogue_p()'. * Danial may characterize the inability to watch a local variable as a very minor bug, but if a user (we have one) is so desperate with a bug of their own that they see *software* watchpoints as a needed tool, I don't think they would characterize this is "very minor". 8-) * I know that this is a hack. It really is a fall-back-hack, as Jim Blandly aluded to in his posting: http://sourceware.org/ml/gdb-patches/2005-12/msg00028.html * If the 'underlying cause' Jim refers to gets fixed, the hack will no longer be executed and it could be removed, or it could stay. * I would prefer the 'right' fix and will presue it, but for right now, this patch 'fixes' a bug and all though it's a hack, it is isolated and easly addressed once the 'right' fix is found. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 20:12 ` Paul Gilliam 2005-12-02 20:17 ` Paul Gilliam @ 2005-12-03 3:05 ` Jim Blandy 2005-12-02 23:38 ` Jim Blandy 2005-12-04 20:19 ` Daniel Jacobowitz 1 sibling, 2 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-03 3:05 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches, Daniel Jacobowitz, gdb-patches On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote: > This patch does *not* assume that the exit of the function is near the end of the function. > > It's more/less of a hack than that! > > Here is the 'algorithm': > 1) scan forward from the point of execution: > a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. > b) Stop scanning if you find a return instruction or reach the end of the function. > 2) scan backward from the point of execution: > a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. > b) Stop scanning if you reach the beginning of the function. (That text belongs in a comment, else Daniel wouldn't have got it wrong!) You know, there's no reason this logic wouldn't be equally useful in the skip_prologue function. If the prologue scan doesn't make it to the PC, then we could do the above, and use it to provide an accurate frame ID. That would fix the bug, and backtraces too. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-03 3:05 ` Jim Blandy @ 2005-12-02 23:38 ` Jim Blandy 2005-12-04 20:19 ` Daniel Jacobowitz 1 sibling, 0 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-02 23:38 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches, Daniel Jacobowitz, gdb-patches On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote: > This patch does *not* assume that the exit of the function is near the end of the function. > > It's more/less of a hack than that! > > Here is the 'algorithm': > 1) scan forward from the point of execution: > a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. > b) Stop scanning if you find a return instruction or reach the end of the function. > 2) scan backward from the point of execution: > a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. > b) Stop scanning if you reach the beginning of the function. (That text belongs in a comment, else Daniel wouldn't have got it wrong!) You know, there's no reason this logic wouldn't be equally useful in the skip_prologue function. If the prologue scan doesn't make it to the PC, then we could do the above, and use it to provide an accurate frame ID. That would fix the bug, and backtraces too. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-03 3:05 ` Jim Blandy 2005-12-02 23:38 ` Jim Blandy @ 2005-12-04 20:19 ` Daniel Jacobowitz 2005-12-04 18:59 ` Daniel Jacobowitz 2005-12-04 20:48 ` Jim Blandy 1 sibling, 2 replies; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-04 20:19 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches, gdb-patches On Fri, Dec 02, 2005 at 02:19:07PM -0800, Jim Blandy wrote: > On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote: > > This patch does *not* assume that the exit of the function is near the end of the function. > > > > It's more/less of a hack than that! > > > > Here is the 'algorithm': > > 1) scan forward from the point of execution: > > a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. > > b) Stop scanning if you find a return instruction or reach the end of the function. > > 2) scan backward from the point of execution: > > a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. > > b) Stop scanning if you reach the beginning of the function. > (That text belongs in a comment, else Daniel wouldn't have got it wrong!) For all sorts of reasons, this isn't a safe algorithm; just a guess. - A forward scan really has to stop at any control flow instruction. - A backward scan, in general, is just not possible. GCC does agressive basic block reordering and tail merging, and will do more so in the future; who knows where you came from... It may be a useful guess though. > You know, there's no reason this logic wouldn't be equally useful in > the skip_prologue function. If the prologue scan doesn't make it to > the PC, then we could do the above, and use it to provide an accurate > frame ID. That would fix the bug, and backtraces too. I don't think I follow... Anyway, there is exactly this one user of the method. It occured to me that there may be a better way to figure out what we _really_ want to check there. We want to know "is this watchpoint in a stack frame that isn't there any more". A gdbarch method that knows whether we're above or below the stack pointer... But this all gets tangled up in what we're _really_ watching. We want to watch the local variable, which may move around - we get the "multiple locations" (loclist) case completely wrong today. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-04 20:19 ` Daniel Jacobowitz @ 2005-12-04 18:59 ` Daniel Jacobowitz 2005-12-04 20:48 ` Jim Blandy 1 sibling, 0 replies; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-04 18:59 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches, gdb-patches On Fri, Dec 02, 2005 at 02:19:07PM -0800, Jim Blandy wrote: > On 12/2/05, Paul Gilliam <pgilliam@us.ibm.com> wrote: > > This patch does *not* assume that the exit of the function is near the end of the function. > > > > It's more/less of a hack than that! > > > > Here is the 'algorithm': > > 1) scan forward from the point of execution: > > a) If you find an instruction that modifies the stack pointer, execution is not in an epilogue, return. > > b) Stop scanning if you find a return instruction or reach the end of the function. > > 2) scan backward from the point of execution: > > a) If you find an instruction that modifies the stack pointer, execution *is* in an epilogue, return. > > b) Stop scanning if you reach the beginning of the function. > (That text belongs in a comment, else Daniel wouldn't have got it wrong!) For all sorts of reasons, this isn't a safe algorithm; just a guess. - A forward scan really has to stop at any control flow instruction. - A backward scan, in general, is just not possible. GCC does agressive basic block reordering and tail merging, and will do more so in the future; who knows where you came from... It may be a useful guess though. > You know, there's no reason this logic wouldn't be equally useful in > the skip_prologue function. If the prologue scan doesn't make it to > the PC, then we could do the above, and use it to provide an accurate > frame ID. That would fix the bug, and backtraces too. I don't think I follow... Anyway, there is exactly this one user of the method. It occured to me that there may be a better way to figure out what we _really_ want to check there. We want to know "is this watchpoint in a stack frame that isn't there any more". A gdbarch method that knows whether we're above or below the stack pointer... But this all gets tangled up in what we're _really_ watching. We want to watch the local variable, which may move around - we get the "multiple locations" (loclist) case completely wrong today. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-04 20:19 ` Daniel Jacobowitz 2005-12-04 18:59 ` Daniel Jacobowitz @ 2005-12-04 20:48 ` Jim Blandy 2005-12-04 21:12 ` Jim Blandy 2005-12-04 21:16 ` Daniel Jacobowitz 1 sibling, 2 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-04 20:48 UTC (permalink / raw) To: Jim Blandy, pgilliam, gdb-patches, gdb-patches On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > > You know, there's no reason this logic wouldn't be equally useful in > > the skip_prologue function. If the prologue scan doesn't make it to > > the PC, then we could do the above, and use it to provide an accurate > > frame ID. That would fix the bug, and backtraces too. > > I don't think I follow... I've been loose with my words, so what I'm describing may not correspond exactly to what I've said before, or to what Paul has posted, so erase all that and read afresh. If you call rs6000-tdep.c skip_prologue to analyze a live frame, with 'pc' being the function's entry point and 'lim_pc' being the current PC within that function, then sometimes the analysis won't reach lim_pc; it'll hit some branch or unrecognized instruction. In that case, we just give up and hope that the information we've gathered so far would still be accurate if we had been able to analyze all the way to lim_pc. But we can do a bit better than that. If skip_prologue were sure that lim_pc represents a real PC value (its callers know), and scanning from the entry point wasn't able to reach lim_pc, and lim_pc points directly at a return instruction, then we *know* that the current SP is our CFA. And if you actually understand all the instructions between lim_pc and the return instruction, then you may again be able to derive the CFA. This information can be used in preference to that obtained with the from-entry-point scan. To put it another way, there are two cases where we can be pretty confident our machine code analysis has gotten us the straight dope: when we recognize everything from the entry point to lim_pc, and when we recognize everything from lim_pc to a return instruction. In the first case, we can run backwards from lim_pc to reconstruct the state when we were at the entry point; in the second case, we can run forwards from lim_pc to construct the state we'll be at when we return. Either one is equivalent, for our concept of unwinding. If we moved Paul's heuristic (actually, it's a bit loose for my tastes too, so maybe something tighter) into skip_prologue, we could solve the watchpoint problem, and also improve backtraces, which will also be broken in the midst of the epilogue (if they weren't then watchpoint_check wouldn't be unhappy). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-04 20:48 ` Jim Blandy @ 2005-12-04 21:12 ` Jim Blandy 2005-12-04 21:16 ` Daniel Jacobowitz 1 sibling, 0 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-04 21:12 UTC (permalink / raw) To: Jim Blandy, pgilliam, gdb-patches, gdb-patches On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > > You know, there's no reason this logic wouldn't be equally useful in > > the skip_prologue function. If the prologue scan doesn't make it to > > the PC, then we could do the above, and use it to provide an accurate > > frame ID. That would fix the bug, and backtraces too. > > I don't think I follow... I've been loose with my words, so what I'm describing may not correspond exactly to what I've said before, or to what Paul has posted, so erase all that and read afresh. If you call rs6000-tdep.c skip_prologue to analyze a live frame, with 'pc' being the function's entry point and 'lim_pc' being the current PC within that function, then sometimes the analysis won't reach lim_pc; it'll hit some branch or unrecognized instruction. In that case, we just give up and hope that the information we've gathered so far would still be accurate if we had been able to analyze all the way to lim_pc. But we can do a bit better than that. If skip_prologue were sure that lim_pc represents a real PC value (its callers know), and scanning from the entry point wasn't able to reach lim_pc, and lim_pc points directly at a return instruction, then we *know* that the current SP is our CFA. And if you actually understand all the instructions between lim_pc and the return instruction, then you may again be able to derive the CFA. This information can be used in preference to that obtained with the from-entry-point scan. To put it another way, there are two cases where we can be pretty confident our machine code analysis has gotten us the straight dope: when we recognize everything from the entry point to lim_pc, and when we recognize everything from lim_pc to a return instruction. In the first case, we can run backwards from lim_pc to reconstruct the state when we were at the entry point; in the second case, we can run forwards from lim_pc to construct the state we'll be at when we return. Either one is equivalent, for our concept of unwinding. If we moved Paul's heuristic (actually, it's a bit loose for my tastes too, so maybe something tighter) into skip_prologue, we could solve the watchpoint problem, and also improve backtraces, which will also be broken in the midst of the epilogue (if they weren't then watchpoint_check wouldn't be unhappy). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-04 20:48 ` Jim Blandy 2005-12-04 21:12 ` Jim Blandy @ 2005-12-04 21:16 ` Daniel Jacobowitz 2005-12-04 21:22 ` Jim Blandy 1 sibling, 1 reply; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-04 21:16 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches On Fri, Dec 02, 2005 at 08:20:48PM -0800, Jim Blandy wrote: > But we can do a bit better than that. If skip_prologue were sure that > lim_pc represents a real PC value (its callers know), and scanning > from the entry point wasn't able to reach lim_pc, and lim_pc points > directly at a return instruction, then we *know* that the current SP > is our CFA. And if you actually understand all the instructions > between lim_pc and the return instruction, then you may again be able > to derive the CFA. This information can be used in preference to that > obtained with the from-entry-point scan. Fascinating. So, do both prologue and epilogue recognition. It would be useful for backtraces in epilogues, but not for much else, and it would be a lot of work, so I have trouble seeing this get implemented. But, maybe. Of course this is only useful without CFI and the main reason PPC doesn't use CFI has been solved. And the problem is likely to reoccur with CFI that doesn't describe the epilogue, which today is prevalent. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-04 21:16 ` Daniel Jacobowitz @ 2005-12-04 21:22 ` Jim Blandy 0 siblings, 0 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-04 21:22 UTC (permalink / raw) To: Jim Blandy, pgilliam, gdb-patches On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > Fascinating. So, do both prologue and epilogue recognition. It would > be useful for backtraces in epilogues, but not for much else, and it > would be a lot of work, so I have trouble seeing this get implemented. > But, maybe. Well, I was suggesting that Paul do it, you see. :) (I don't think it'd be that much work.) > Of course this is only useful without CFI and the main reason PPC > doesn't use CFI has been solved. And the problem is likely to > reoccur with CFI that doesn't describe the epilogue, which today is > prevalent. As I've always said, compiler-provided CFI is better. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 1:13 ` Jim Blandy 2005-12-02 1:23 ` Daniel Jacobowitz @ 2005-12-02 4:02 ` Joel Brobecker 2005-12-02 18:44 ` Mark Kettenis 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam 3 siblings, 0 replies; 39+ messages in thread From: Joel Brobecker @ 2005-12-02 4:02 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches > Paul wanted to fast-track this patch, in hopes it could get into the > 6.4 release. Joel, what are your thoughts? I think it's too late for 6.4, the cutoff time is just hours away. The bug seems to be minor too, so I don't think it's going to be so bad for 6.4. Eventually, if the maintainers agree to having this in 6.4.1, we can add it to the branch later. -- Joel ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' 2005-12-02 1:13 ` Jim Blandy 2005-12-02 1:23 ` Daniel Jacobowitz 2005-12-02 4:02 ` Joel Brobecker @ 2005-12-02 18:44 ` Mark Kettenis 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam 3 siblings, 0 replies; 39+ messages in thread From: Mark Kettenis @ 2005-12-02 18:44 UTC (permalink / raw) To: jimb; +Cc: pgilliam, gdb-patches > Date: Thu, 1 Dec 2005 17:07:24 -0800 > From: Jim Blandy <jimb@red-bean.com> > > Whatever we do immediately, the underlying cause here is that > unwinding isn't working at every instruction. If it were, then the > call to frame_find_by_id would find the frame containing the watched > variable, and watchpoint_check would correctly conclude that the > variable was still in scope. > > Paul, does your test program have Dwarf CFI for the functions in question? Unfortunately, GCC's CFI is not complete. At one point GCC did generate CFI for epilogues, but that really screwed up cases like: main: prologue jump to body epilogue: epilogue body: ... ... jump to epilogue whis GCC was generating quite a lot. So generating CFI for epilogues was disabled. I vaguely remember that Richard Henderson said that generating correct CFI for the above case would be possible with tree SSA. But I don't think this has ahppened yet. Actually I think the fact that CFI works at all is mostly because it is also used for exception handling. Obviously, generating correct CFI for the epilogue isn't terribly important for exception handling, since there is no code that can throw exceptions in the epilogue (although it becomes somewhat important if you allow for asynchronous exceptions). It'd be great if we could get some of the GCC hackers a bit more interested in gdb. Mark ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 1:13 ` Jim Blandy ` (2 preceding siblings ...) 2005-12-02 18:44 ` Mark Kettenis @ 2005-12-02 19:15 ` Paul Gilliam 2005-12-02 20:28 ` Mark Kettenis ` (2 more replies) 3 siblings, 3 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-02 19:15 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 4043 bytes --] On Thursday 01 December 2005 17:07, Jim Blandy wrote: > Paul wanted to fast-track this patch, in hopes it could get into the > 6.4 release. Joel, what are your thoughts? > I guess this is now moot. Oh well. > I think the best alternative to deprecated_read_memory_nobpt would be > to actually call current_frame (this will be cheap, since we just > called it in watchpoint_check, before calling > gdbarch_in_function_epilogue_p) and then call > safe_frame_unwind_memory. > I revised the patch using your alternative (see below). > Whatever we do immediately, the underlying cause here is that > unwinding isn't working at every instruction. If it were, then the > call to frame_find_by_id would find the frame containing the watched > variable, and watchpoint_check would correctly conclude that the > variable was still in scope. > > Paul, does your test program have Dwarf CFI for the functions in question? > > I have attached a couple of dumps (and a typescript show how they where made), the executable, and the source. And here is the revised patch: 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -p -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 2 Dec 2005 18:43:19 -0000 @@ -502,6 +502,69 @@ rs6000_skip_prologue (CORE_ADDR pc) return pc; } +static int +insn_changes_sp(unsigned long insn) +{ + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + int b = (insn>>11) & 0x01f; + int subcode = (insn>> 1) & 0x3ff; + int rc = insn & 0x001; + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + return 0; +} + +/* Return true if we are in the functin's epilogue, i.e. after the + instruction that destroyed the function's stack frame. */ +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_addr, func_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits. */ + if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + return 0; + + /* Get the current frame. This may be cheap, since we might have just called + it in watchpoint_check, before calling gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward untill next 'blr'. */ + for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) break; + if (insn_changes_sp(insn)) + return 0; + } + + /* Scan backward untill adjustment to stack pointer (R1). */ + for (scan_pc=pc-PPC_INSN_SIZE; scan_pc>=func_addr; scan_pc-=PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp(insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3405,8 @@ rs6000_gdbarch_init (struct gdbarch_info set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); [-- Attachment #2: dump.typescript --] [-- Type: text/plain, Size: 196 bytes --] Script started on Fri 02 Dec 2005 10:04:46 AM PST > objdump -xs testwatch > testwatch.objdmp > readelf -w testwatch > testwatch.readelf 2>&1 > exit Script done on Fri 02 Dec 2005 10:05:21 AM PST [-- Attachment #3: testwatch.readelf --] [-- Type: text/plain, Size: 32026 bytes --] The section .debug_aranges contains: Length: 44 Version: 2 Offset into .debug_info: 0 Pointer Size: 8 Segment Size: 0 Address Length 10000380 60 Length: 76 Version: 2 Offset into .debug_info: 115 Pointer Size: 8 Segment Size: 0 Address Length 100007c8 16 10000318 16 100003bc 68 Length: 44 Version: 2 Offset into .debug_info: 192 Pointer Size: 8 Segment Size: 0 Address Length 100004e4 232 Length: 44 Version: 2 Offset into .debug_info: 2fd Pointer Size: 8 Segment Size: 0 Address Length 100005cc 316 Length: 60 Version: 2 Offset into .debug_info: 42b Pointer Size: 8 Segment Size: 0 Address Length 100007e0 16 10000338 16 Contents of the .debug_pubnames section: Length: 33 Version: 2 Offset into .debug_info section: 134 Size of area in .debug_info section: 143 Offset Name 115 _IO_stdin_used Length: 71 Version: 2 Offset into .debug_info section: 402 Size of area in .debug_info section: 363 Offset Name 120 subr2 183 subr1 237 main 292 checkmeout 321 lookatme Length: 54 Version: 2 Offset into .debug_info section: 765 Size of area in .debug_info section: 302 Offset Name 77 __libc_csu_fini 120 __libc_csu_init The section .debug_info contains: Compilation Unit @ 0: Length: 130 Version: 2 Abbrev Offset: 0 Pointer Size: 8 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0 DW_AT_low_pc : 0x10000380 268436352 DW_AT_high_pc : 0x100003bc 268436412 DW_AT_name : ../sysdeps/powerpc/powerpc64/elf/start.S DW_AT_comp_dir : /usr/src/packages/BUILD/glibc-2.3/csu DW_AT_producer : GNU AS 2.15.90.0.1.1 DW_AT_language : 32769 (MIPS assembler) Compilation Unit @ 86: Length: 139 Version: 2 Abbrev Offset: 20 Pointer Size: 8 <0><91>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 149 DW_AT_high_pc : 0x100003bc 268436412 DW_AT_low_pc : 0x100003bc 268436412 DW_AT_name : (indirect string, offset: 0xd3): init.c DW_AT_comp_dir : (indirect string, offset: 0x21): /usr/src/packages/BUILD/glibc-2.3/csu DW_AT_producer : (indirect string, offset: 0x63): GNU C 3.3.3 (SuSE Linux) DW_AT_language : 1 (ANSI C) <1><b3>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x47): long unsigned int DW_AT_byte_size : 8 DW_AT_encoding : 7 (unsigned) <1><ba>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x13): unsigned char DW_AT_byte_size : 1 DW_AT_encoding : 8 (unsigned char) <1><c1>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x0): short unsigned int DW_AT_byte_size : 2 DW_AT_encoding : 7 (unsigned) <1><c8>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x4c): unsigned int DW_AT_byte_size : 4 DW_AT_encoding : 7 (unsigned) <1><cf>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x15): signed char DW_AT_byte_size : 1 DW_AT_encoding : 6 (signed char) <1><d6>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x59): short int DW_AT_byte_size : 2 DW_AT_encoding : 5 (signed) <1><dd>: Abbrev Number: 3 (DW_TAG_base_type) DW_AT_name : int DW_AT_byte_size : 4 DW_AT_encoding : 5 (signed) <1><e4>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x8b): long int DW_AT_byte_size : 8 DW_AT_encoding : 5 (signed) <1><eb>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x47): long unsigned int DW_AT_byte_size : 8 DW_AT_encoding : 7 (unsigned) <1><f2>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x1c): char DW_AT_byte_size : 1 DW_AT_encoding : 6 (signed char) <1><f9>: Abbrev Number: 4 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x7c): _IO_stdin_used DW_AT_decl_file : 1 DW_AT_decl_line : 25 DW_AT_type : <10f> DW_AT_external : 1 DW_AT_location : 9 byte block: 3 0 0 0 0 10 0 7 f0 (DW_OP_addr: 100007f0) <1><10f>: Abbrev Number: 5 (DW_TAG_const_type) DW_AT_type : <dd> Compilation Unit @ 115: Length: 121 Version: 2 Abbrev Offset: 86 Pointer Size: 8 <0><120>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 185 DW_AT_name : /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S DW_AT_comp_dir : /usr/src/packages/BUILD/glibc-2.3/csu DW_AT_producer : GNU AS 2.15.90.0.1.1 DW_AT_language : 32769 (MIPS assembler) Compilation Unit @ 192: Length: 359 Version: 2 Abbrev Offset: 102 Pointer Size: 8 <0><19d>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 341 DW_AT_high_pc : 0x100005cc 268436940 DW_AT_low_pc : 0x100004e4 268436708 DW_AT_name : testwatch.c DW_AT_comp_dir : /home/pgilliam/work/gdb-work/read-write/build/gdb DW_AT_producer : GNU C 3.3.3 (SuSE Linux) DW_AT_language : 1 (ANSI C) <1><20a>: Abbrev Number: 2 (DW_TAG_subprogram) DW_AT_sibling : <23c> DW_AT_external : 1 DW_AT_name : subr2 DW_AT_decl_file : 1 DW_AT_decl_line : 5 DW_AT_prototyped : 1 DW_AT_low_pc : 0x100004e4 268436708 DW_AT_high_pc : 0x10000524 268436772 DW_AT_frame_base : 1 byte block: 6f (DW_OP_reg31) <2><22b>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_name : addr DW_AT_decl_file : 1 DW_AT_decl_line : 4 DW_AT_type : <23c> DW_AT_location : 3 byte block: 91 f0 0 (DW_OP_fbreg: 112) <1><23c>: Abbrev Number: 4 (DW_TAG_pointer_type) DW_AT_byte_size : 8 DW_AT_type : <242> <1><242>: Abbrev Number: 5 (DW_TAG_base_type) DW_AT_name : int DW_AT_byte_size : 4 DW_AT_encoding : 5 (signed) <1><249>: Abbrev Number: 6 (DW_TAG_subprogram) DW_AT_sibling : <27f> DW_AT_external : 1 DW_AT_name : subr1 DW_AT_decl_file : 1 DW_AT_decl_line : 12 DW_AT_low_pc : 0x10000524 268436772 DW_AT_high_pc : 0x10000588 268436872 DW_AT_frame_base : 1 byte block: 6f (DW_OP_reg31) <2><269>: Abbrev Number: 7 (DW_TAG_variable) DW_AT_name : watchthis DW_AT_decl_file : 1 DW_AT_decl_line : 13 DW_AT_type : <242> DW_AT_location : 3 byte block: 91 f0 0 (DW_OP_fbreg: 112) <1><27f>: Abbrev Number: 8 (DW_TAG_subprogram) DW_AT_sibling : <2b6> DW_AT_external : 1 DW_AT_name : main DW_AT_decl_file : 1 DW_AT_decl_line : 23 DW_AT_type : <242> DW_AT_low_pc : 0x10000588 268436872 DW_AT_high_pc : 0x100005cc 268436940 DW_AT_frame_base : 1 byte block: 6f (DW_OP_reg31) <2><2a2>: Abbrev Number: 7 (DW_TAG_variable) DW_AT_name : ret_val DW_AT_decl_file : 1 DW_AT_decl_line : 24 DW_AT_type : <242> DW_AT_location : 3 byte block: 91 f0 0 (DW_OP_fbreg: 112) <1><2b6>: Abbrev Number: 9 (DW_TAG_variable) DW_AT_name : checkmeout DW_AT_decl_file : 1 DW_AT_decl_line : 1 DW_AT_type : <242> DW_AT_external : 1 DW_AT_location : 9 byte block: 3 0 0 0 0 10 1 b dc (DW_OP_addr: 10010bdc) <1><2d3>: Abbrev Number: 9 (DW_TAG_variable) DW_AT_name : lookatme DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type : <2ee> DW_AT_external : 1 DW_AT_location : 9 byte block: 3 0 0 0 0 10 1 8 50 (DW_OP_addr: 10010850) <1><2ee>: Abbrev Number: 4 (DW_TAG_pointer_type) DW_AT_byte_size : 8 DW_AT_type : <2f4> <1><2f4>: Abbrev Number: 5 (DW_TAG_base_type) DW_AT_name : char DW_AT_byte_size : 1 DW_AT_encoding : 8 (unsigned char) Compilation Unit @ 2fd: Length: 298 Version: 2 Abbrev Offset: 256 Pointer Size: 8 <0><308>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 413 DW_AT_high_pc : 0x10000708 268437256 DW_AT_low_pc : 0x100005cc 268436940 DW_AT_name : (indirect string, offset: 0xcf): elf-init.c DW_AT_comp_dir : (indirect string, offset: 0x21): /usr/src/packages/BUILD/glibc-2.3/csu DW_AT_producer : (indirect string, offset: 0x63): GNU C 3.3.3 (SuSE Linux) DW_AT_language : 1 (ANSI C) <1><32a>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x8b): long int DW_AT_byte_size : 8 DW_AT_encoding : 5 (signed) <1><331>: Abbrev Number: 3 (DW_TAG_typedef) DW_AT_name : (indirect string, offset: 0xa4): size_t DW_AT_decl_file : 2 DW_AT_decl_line : 213 DW_AT_type : <33c> <1><33c>: Abbrev Number: 2 (DW_TAG_base_type) DW_AT_name : (indirect string, offset: 0x47): long unsigned int DW_AT_byte_size : 8 DW_AT_encoding : 7 (unsigned) <1><343>: Abbrev Number: 4 (DW_TAG_base_type) DW_AT_name : int DW_AT_byte_size : 4 DW_AT_encoding : 5 (signed) <1><34a>: Abbrev Number: 5 (DW_TAG_subprogram) DW_AT_sibling : <375> DW_AT_external : 1 DW_AT_name : (indirect string, offset: 0x94): __libc_csu_fini DW_AT_decl_file : 1 DW_AT_decl_line : 74 DW_AT_prototyped : 1 DW_AT_low_pc : 0x100005cc 268436940 DW_AT_high_pc : 0x10000664 268437092 DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1) <2><369>: Abbrev Number: 6 (DW_TAG_variable) DW_AT_name : i DW_AT_decl_file : 1 DW_AT_decl_line : 76 DW_AT_type : <331> DW_AT_location : 1 byte block: 6f (DW_OP_reg31) <1><375>: Abbrev Number: 5 (DW_TAG_subprogram) DW_AT_sibling : <3bd> DW_AT_external : 1 DW_AT_name : (indirect string, offset: 0xeb): __libc_csu_init DW_AT_decl_file : 1 DW_AT_decl_line : 44 DW_AT_prototyped : 1 DW_AT_low_pc : 0x10000664 268437092 DW_AT_high_pc : 0x10000708 268437256 DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1) <2><394>: Abbrev Number: 7 (DW_TAG_lexical_block) DW_AT_low_pc : 0x1000067c 268437116 DW_AT_high_pc : 0x100006fc 268437244 <3><3a5>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x10e): size DW_AT_decl_file : 1 DW_AT_decl_line : 64 DW_AT_type : <3bd> <3><3b0>: Abbrev Number: 6 (DW_TAG_variable) DW_AT_name : i DW_AT_decl_file : 1 DW_AT_decl_line : 65 DW_AT_type : <331> DW_AT_location : 1 byte block: 6f (DW_OP_reg31) <1><3bd>: Abbrev Number: 9 (DW_TAG_const_type) DW_AT_type : <331> <1><3c2>: Abbrev Number: 10 (DW_TAG_array_type) DW_AT_sibling : <3cd> DW_AT_type : <3cf> <2><3cb>: Abbrev Number: 11 (DW_TAG_subrange_type) <1><3cd>: Abbrev Number: 12 (DW_TAG_subroutine_type) DW_AT_prototyped : 1 <1><3cf>: Abbrev Number: 13 (DW_TAG_pointer_type) DW_AT_byte_size : 8 DW_AT_type : <3cd> <1><3d5>: Abbrev Number: 14 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0xbc): __init_array_start DW_AT_decl_file : 1 DW_AT_decl_line : 26 DW_AT_type : <3c2> DW_AT_external : 1 DW_AT_declaration : 1 <1><3e2>: Abbrev Number: 10 (DW_TAG_array_type) DW_AT_sibling : <3ed> DW_AT_type : <3cf> <2><3eb>: Abbrev Number: 11 (DW_TAG_subrange_type) <1><3ed>: Abbrev Number: 14 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0xab): __init_array_end DW_AT_decl_file : 1 DW_AT_decl_line : 27 DW_AT_type : <3e2> DW_AT_external : 1 DW_AT_declaration : 1 <1><3fa>: Abbrev Number: 10 (DW_TAG_array_type) DW_AT_sibling : <405> DW_AT_type : <3cf> <2><403>: Abbrev Number: 11 (DW_TAG_subrange_type) <1><405>: Abbrev Number: 14 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0xfb): __fini_array_start DW_AT_decl_file : 1 DW_AT_decl_line : 28 DW_AT_type : <3fa> DW_AT_external : 1 DW_AT_declaration : 1 <1><412>: Abbrev Number: 10 (DW_TAG_array_type) DW_AT_sibling : <41d> DW_AT_type : <3cf> <2><41b>: Abbrev Number: 11 (DW_TAG_subrange_type) <1><41d>: Abbrev Number: 14 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0xda): __fini_array_end DW_AT_decl_file : 1 DW_AT_decl_line : 29 DW_AT_type : <412> DW_AT_external : 1 DW_AT_declaration : 1 Compilation Unit @ 42b: Length: 121 Version: 2 Abbrev Offset: 425 Pointer Size: 8 <0><436>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 560 DW_AT_name : /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S DW_AT_comp_dir : /usr/src/packages/BUILD/glibc-2.3/csu DW_AT_producer : GNU AS 2.15.90.0.1.1 DW_AT_language : 32769 (MIPS assembler) Contents of the .debug_abbrev section: Number TAG 1 DW_TAG_compile_unit [no children] DW_AT_stmt_list DW_FORM_data4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_name DW_FORM_string DW_AT_comp_dir DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_language DW_FORM_data2 Number TAG 1 DW_TAG_compile_unit [has children] DW_AT_stmt_list DW_FORM_data4 DW_AT_high_pc DW_FORM_addr DW_AT_low_pc DW_FORM_addr DW_AT_name DW_FORM_strp DW_AT_comp_dir DW_FORM_strp DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data1 2 DW_TAG_base_type [no children] DW_AT_name DW_FORM_strp DW_AT_byte_size DW_FORM_data1 DW_AT_encoding DW_FORM_data1 3 DW_TAG_base_type [no children] DW_AT_name DW_FORM_string DW_AT_byte_size DW_FORM_data1 DW_AT_encoding DW_FORM_data1 4 DW_TAG_variable [no children] DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_location DW_FORM_block1 5 DW_TAG_const_type [no children] DW_AT_type DW_FORM_ref4 Number TAG 1 DW_TAG_compile_unit [no children] DW_AT_stmt_list DW_FORM_data4 DW_AT_name DW_FORM_string DW_AT_comp_dir DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_language DW_FORM_data2 Number TAG 1 DW_TAG_compile_unit [has children] DW_AT_stmt_list DW_FORM_data4 DW_AT_high_pc DW_FORM_addr DW_AT_low_pc DW_FORM_addr DW_AT_name DW_FORM_string DW_AT_comp_dir DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_language DW_FORM_data1 2 DW_TAG_subprogram [has children] DW_AT_sibling DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_prototyped DW_FORM_flag DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_frame_base DW_FORM_block1 3 DW_TAG_formal_parameter [no children] DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_location DW_FORM_block1 4 DW_TAG_pointer_type [no children] DW_AT_byte_size DW_FORM_data1 DW_AT_type DW_FORM_ref4 5 DW_TAG_base_type [no children] DW_AT_name DW_FORM_string DW_AT_byte_size DW_FORM_data1 DW_AT_encoding DW_FORM_data1 6 DW_TAG_subprogram [has children] DW_AT_sibling DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_frame_base DW_FORM_block1 7 DW_TAG_variable [no children] DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_location DW_FORM_block1 8 DW_TAG_subprogram [has children] DW_AT_sibling DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_frame_base DW_FORM_block1 9 DW_TAG_variable [no children] DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_location DW_FORM_block1 Number TAG 1 DW_TAG_compile_unit [has children] DW_AT_stmt_list DW_FORM_data4 DW_AT_high_pc DW_FORM_addr DW_AT_low_pc DW_FORM_addr DW_AT_name DW_FORM_strp DW_AT_comp_dir DW_FORM_strp DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data1 2 DW_TAG_base_type [no children] DW_AT_name DW_FORM_strp DW_AT_byte_size DW_FORM_data1 DW_AT_encoding DW_FORM_data1 3 DW_TAG_typedef [no children] DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 4 DW_TAG_base_type [no children] DW_AT_name DW_FORM_string DW_AT_byte_size DW_FORM_data1 DW_AT_encoding DW_FORM_data1 5 DW_TAG_subprogram [has children] DW_AT_sibling DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_prototyped DW_FORM_flag DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT_frame_base DW_FORM_block1 6 DW_TAG_variable [no children] DW_AT_name DW_FORM_string DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_location DW_FORM_block1 7 DW_TAG_lexical_block [has children] DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr 8 DW_TAG_variable [no children] DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 9 DW_TAG_const_type [no children] DW_AT_type DW_FORM_ref4 10 DW_TAG_array_type [has children] DW_AT_sibling DW_FORM_ref4 DW_AT_type DW_FORM_ref4 11 DW_TAG_subrange_type [no children] 12 DW_TAG_subroutine_type [no children] DW_AT_prototyped DW_FORM_flag 13 DW_TAG_pointer_type [no children] DW_AT_byte_size DW_FORM_data1 DW_AT_type DW_FORM_ref4 14 DW_TAG_variable [no children] DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_type DW_FORM_ref4 DW_AT_external DW_FORM_flag DW_AT_declaration DW_FORM_flag Number TAG 1 DW_TAG_compile_unit [no children] DW_AT_stmt_list DW_FORM_data4 DW_AT_name DW_FORM_string DW_AT_comp_dir DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_language DW_FORM_data2 Dump of debug contents of section .debug_line: Length: 93 DWARF Version: 2 Prologue Length: 60 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table: ../sysdeps/powerpc/powerpc64/elf The File Name Table: Entry Dir Time Size Name 1 1 0 0 start.S Line Number Statements: Extended opcode 2: set Address to 0x10000380 Advance Line by 44 to 45 Copy Special opcode 21: advance Address by 4 to 0x10000384 and Line by 2 to 47 Special opcode 20: advance Address by 4 to 0x10000388 and Line by 1 to 48 Special opcode 20: advance Address by 4 to 0x1000038c and Line by 1 to 49 Special opcode 20: advance Address by 4 to 0x10000390 and Line by 1 to 50 Special opcode 20: advance Address by 4 to 0x10000394 and Line by 1 to 51 Special opcode 23: advance Address by 4 to 0x10000398 and Line by 4 to 55 Special opcode 22: advance Address by 4 to 0x1000039c and Line by 3 to 58 Special opcode 22: advance Address by 4 to 0x100003a0 and Line by 3 to 61 Advance PC by 28 to 100003bc Extended opcode 1: End of Sequence Length: 22 DWARF Version: 2 Prologue Length: 16 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table is empty. The File Name Table is empty. Line Number Statements: Length: 22 DWARF Version: 2 Prologue Length: 16 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table is empty. The File Name Table is empty. Line Number Statements: Length: 32 DWARF Version: 2 Prologue Length: 26 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table is empty. The File Name Table: Entry Dir Time Size Name 1 0 0 0 init.c Line Number Statements: Length: 152 DWARF Version: 2 Prologue Length: 67 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table: /usr/src/packages/BUILD/glibc-2.3/cc/csu The File Name Table: Entry Dir Time Size Name 1 1 0 0 crti.S Line Number Statements: Extended opcode 2: set Address to 0x100007c8 Advance Line by 76 to 77 Copy Special opcode 20: advance Address by 4 to 0x100007cc and Line by 1 to 78 Special opcode 20: advance Address by 4 to 0x100007d0 and Line by 1 to 79 Advance PC by 8 to 100007d8 Extended opcode 1: End of Sequence Extended opcode 2: set Address to 0x10000318 Advance Line by 53 to 54 Copy Special opcode 20: advance Address by 4 to 0x1000031c and Line by 1 to 55 Special opcode 20: advance Address by 4 to 0x10000320 and Line by 1 to 56 Special opcode 20: advance Address by 4 to 0x10000324 and Line by 1 to 57 Advance PC by 4 to 10000328 Extended opcode 1: End of Sequence Extended opcode 2: set Address to 0x100003bc Advance Line by 21 to 22 Copy Special opcode 20: advance Address by 4 to 0x100003c0 and Line by 1 to 23 Special opcode 20: advance Address by 4 to 0x100003c4 and Line by 1 to 24 Special opcode 20: advance Address by 4 to 0x100003c8 and Line by 1 to 25 Special opcode 20: advance Address by 4 to 0x100003cc and Line by 1 to 26 Special opcode 20: advance Address by 4 to 0x100003d0 and Line by 1 to 27 Special opcode 20: advance Address by 4 to 0x100003d4 and Line by 1 to 28 Special opcode 20: advance Address by 4 to 0x100003d8 and Line by 1 to 29 Special opcode 20: advance Address by 4 to 0x100003dc and Line by 1 to 30 Special opcode 20: advance Address by 4 to 0x100003e0 and Line by 1 to 31 Special opcode 20: advance Address by 4 to 0x100003e4 and Line by 1 to 32 Special opcode 20: advance Address by 4 to 0x100003e8 and Line by 1 to 33 Special opcode 20: advance Address by 4 to 0x100003ec and Line by 1 to 34 Special opcode 21: advance Address by 4 to 0x100003f0 and Line by 2 to 36 Special opcode 20: advance Address by 4 to 0x100003f4 and Line by 1 to 37 Special opcode 20: advance Address by 4 to 0x100003f8 and Line by 1 to 38 Special opcode 20: advance Address by 4 to 0x100003fc and Line by 1 to 39 Advance PC by 4 to 10000400 Extended opcode 1: End of Sequence Length: 68 DWARF Version: 2 Prologue Length: 31 Minimum Instruction Length: 4 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 10 (Pointer size: 8) Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table is empty. The File Name Table: Entry Dir Time Size Name 1 0 0 0 testwatch.c Line Number Statements: Extended opcode 2: set Address to 0x100004e4 Special opcode 9: advance Address by 0 to 0x100004e4 and Line by 4 to 5 Special opcode 62: advance Address by 16 to 0x100004f4 and Line by 1 to 6 Special opcode 48: advance Address by 12 to 0x10000500 and Line by 1 to 7 Special opcode 48: advance Address by 12 to 0x1000050c and Line by 1 to 8 Special opcode 93: advance Address by 24 to 0x10000524 and Line by 4 to 12 Special opcode 76: advance Address by 20 to 0x10000538 and Line by 1 to 13 Special opcode 35: advance Address by 8 to 0x10000540 and Line by 2 to 15 Special opcode 35: advance Address by 8 to 0x10000548 and Line by 2 to 17 Special opcode 48: advance Address by 12 to 0x10000554 and Line by 1 to 18 Special opcode 48: advance Address by 12 to 0x10000560 and Line by 1 to 19 Special opcode 34: advance Address by 8 to 0x10000568 and Line by 1 to 20 Special opcode 120: advance Address by 32 to 0x10000588 and Line by 3 to 23 Special opcode 76: advance Address by 20 to 0x1000059c and Line by 1 to 24 Special opcode 35: advance Address by 8readelf: Error: Not enough comp units for .debug_lines section to 0x100005a4 and Line by 2 to 26 Special opcode 20: advance Address by 4 to 0x100005a8 and Line by 1 to 27 Advance PC by 36 to 100005cc Extended opcode 1: End of Sequence The section .debug_frame contains: 00000000 0000000c ffffffff CIE Version: 1 Augmentation: "" Code alignment factor: 1 Data alignment factor: -8 Return address column: 65 DW_CFA_def_cfa: r1 ofs 0 00000010 0000001c 00000000 FDE cie=00000000 pc=100004e4..10000524 DW_CFA_advance_loc: 8 to 100004ec DW_CFA_def_cfa_offset: 64 DW_CFA_offset: r31 at cfa-8 DW_CFA_advance_loc: 4 to 100004f0 DW_CFA_def_cfa_reg: r31 00000030 00000024 00000000 FDE cie=00000000 pc=10000524..10000588 DW_CFA_advance_loc: 16 to 10000534 DW_CFA_def_cfa_offset: 144 DW_CFA_offset_extended_sf: r108 at cfa+16 DW_CFA_offset: r31 at cfa-8 DW_CFA_advance_loc: 4 to 10000538 DW_CFA_def_cfa_reg: r31 DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop 00000058 00000024 00000000 FDE cie=00000000 pc=10000588..100005cc DW_CFA_advance_loc: 16 to 10000598 DW_CFA_def_cfa_offset: 144 DW_CFA_offset_extended_sf: r108 at cfa+16 DW_CFA_offset: r31 at cfa-8 DW_CFA_advance_loc: 4 to 1000059c DW_CFA_def_cfa_reg: r31 DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop 00000080 0000000c ffffffff CIE Version: 1 Augmentation: "" Code alignment factor: 1 Data alignment factor: -8 Return address column: 65 DW_CFA_def_cfa: r1 ofs 0 00000090 00000024 00000080 FDE cie=00000080 pc=100005cc..10000664 DW_CFA_advance_loc: 32 to 100005ec DW_CFA_def_cfa_offset: 144 DW_CFA_offset: r29 at cfa-24 DW_CFA_offset_extended_sf: r108 at cfa+16 DW_CFA_offset: r31 at cfa-8 DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop 000000b8 00000024 00000080 FDE cie=00000080 pc=10000664..10000708 DW_CFA_advance_loc: 16 to 10000674 DW_CFA_def_cfa_offset: 128 DW_CFA_offset_extended_sf: r108 at cfa+16 DW_CFA_offset: r31 at cfa-8 DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Contents of the .debug_str section: 0x00000000 73686f72 7420756e 7369676e 65642069 short unsigned i 0x00000010 6e740075 6e736967 6e656420 63686172 nt.unsigned char 0x00000020 002f7573 722f7372 632f7061 636b6167 ./usr/src/packag 0x00000030 65732f42 55494c44 2f676c69 62632d32 es/BUILD/glibc-2 0x00000040 2e332f63 7375006c 6f6e6720 756e7369 .3/csu.long unsi 0x00000050 676e6564 20696e74 0073686f 72742069 gned int.short i 0x00000060 6e740047 4e552043 20332e33 2e332028 nt.GNU C 3.3.3 ( 0x00000070 53755345 204c696e 75782900 5f494f5f SuSE Linux)._IO_ 0x00000080 73746469 6e5f7573 6564006c 6f6e6720 stdin_used.long 0x00000090 696e7400 5f5f6c69 62635f63 73755f66 int.__libc_csu_f 0x000000a0 696e6900 73697a65 5f74005f 5f696e69 ini.size_t.__ini 0x000000b0 745f6172 7261795f 656e6400 5f5f696e t_array_end.__in 0x000000c0 69745f61 72726179 5f737461 72740065 it_array_start.e 0x000000d0 6c662d69 6e69742e 63005f5f 66696e69 lf-init.c.__fini 0x000000e0 5f617272 61795f65 6e64005f 5f6c6962 _array_end.__lib 0x000000f0 635f6373 755f696e 6974005f 5f66696e c_csu_init.__fin 0x00000100 695f6172 7261795f 73746172 74007369 i_array_start.si 0x00000110 7a6500 ze. [-- Attachment #4: testwatch --] [-- Type: application/x-executable, Size: 13825 bytes --] [-- Attachment #5: testwatch.c --] [-- Type: text/x-csrc, Size: 313 bytes --] int checkmeout = 0; char *lookatme = "I have not changed"; void subr2(int * addr) { *addr = 9; *addr = 1; } void subr1() { int watchthis = 9; subr2(&watchthis); checkmeout = 2; lookatme = "change is good"; watchthis = 2; } int main() { int ret_val = 0; subr1(); } [-- Attachment #6: testwatch.objdmp --] [-- Type: text/plain, Size: 41580 bytes --] testwatch: file format elf64-powerpc testwatch architecture: powerpc:common64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0000000010010860 Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000010000040 paddr 0x0000000010000040 align 2**3 filesz 0x0000000000000188 memsz 0x0000000000000188 flags r-x INTERP off 0x00000000000001c8 vaddr 0x00000000100001c8 paddr 0x00000000100001c8 align 2**0 filesz 0x0000000000000011 memsz 0x0000000000000011 flags r-- LOAD off 0x0000000000000000 vaddr 0x0000000010000000 paddr 0x0000000010000000 align 2**16 filesz 0x0000000000000820 memsz 0x0000000000000820 flags r-x LOAD off 0x0000000000000820 vaddr 0x0000000010010820 paddr 0x0000000010010820 align 2**16 filesz 0x0000000000000370 memsz 0x00000000000003c0 flags rw- DYNAMIC off 0x0000000000000980 vaddr 0x0000000010010980 paddr 0x0000000010010980 align 2**3 filesz 0x0000000000000170 memsz 0x0000000000000170 flags rw- NOTE off 0x00000000000001dc vaddr 0x00000000100001dc paddr 0x00000000100001dc align 2**2 filesz 0x0000000000000020 memsz 0x0000000000000020 flags r-- NOTE off 0x00000000000001fc vaddr 0x00000000100001fc paddr 0x00000000100001fc align 2**2 filesz 0x0000000000000018 memsz 0x0000000000000018 flags r-- Dynamic Section: NEEDED libc.so.6 INIT 0x10010890 FINI 0x100108a8 HASH 0x10000218 STRTAB 0x10000280 SYMTAB 0x10000238 STRSZ 0x3b SYMENT 0x18 DEBUG 0x0 PLTGOT 0x10010b90 PLTRELSZ 0x30 PLTREL 0x7 JMPREL 0x100002e8 0x70000000 0x10000794 VERNEED 0x100002c8 VERNEEDNUM 0x1 VERSYM 0x100002bc Version References: required from libc.so.6: 0x0d696913 0x00 02 GLIBC_2.3 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000011 00000000100001c8 00000000100001c8 000001c8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000020 00000000100001dc 00000000100001dc 000001dc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .note.SuSE 00000018 00000000100001fc 00000000100001fc 000001fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .hash 00000020 0000000010000218 0000000010000218 00000218 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynsym 00000048 0000000010000238 0000000010000238 00000238 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynstr 0000003b 0000000010000280 0000000010000280 00000280 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version 00000006 00000000100002bc 00000000100002bc 000002bc 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu.version_r 00000020 00000000100002c8 00000000100002c8 000002c8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rela.plt 00000030 00000000100002e8 00000000100002e8 000002e8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .init 00000030 0000000010000318 0000000010000318 00000318 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .text 0000047c 0000000010000348 0000000010000348 00000348 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .fini 00000028 00000000100007c8 00000000100007c8 000007c8 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .rodata 00000030 00000000100007f0 00000000100007f0 000007f0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .data 00000038 0000000010010820 0000000010010820 00000820 2**3 CONTENTS, ALLOC, LOAD, DATA 14 .branch_lt 00000000 0000000010010858 0000000010010858 00000858 2**3 CONTENTS, ALLOC, LOAD, DATA 15 .eh_frame 00000004 0000000010010858 0000000010010858 00000858 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .opd 00000120 0000000010010860 0000000010010860 00000860 2**3 CONTENTS, ALLOC, LOAD, DATA 17 .dynamic 00000170 0000000010010980 0000000010010980 00000980 2**3 CONTENTS, ALLOC, LOAD, DATA 18 .ctors 00000010 0000000010010af0 0000000010010af0 00000af0 2**3 CONTENTS, ALLOC, LOAD, DATA 19 .dtors 00000010 0000000010010b00 0000000010010b00 00000b00 2**3 CONTENTS, ALLOC, LOAD, DATA 20 .jcr 00000008 0000000010010b10 0000000010010b10 00000b10 2**3 CONTENTS, ALLOC, LOAD, DATA 21 .got 00000078 0000000010010b18 0000000010010b18 00000b18 2**3 CONTENTS, ALLOC, LOAD, DATA 22 .sbss 00000000 0000000010010b90 0000000010010b90 00000b90 2**0 23 .plt 00000048 0000000010010b90 0000000010010b90 00000b90 2**3 ALLOC 24 .bss 00000008 0000000010010bd8 0000000010010bd8 00000b90 2**2 ALLOC 25 .comment 000000d9 0000000000000000 0000000000000000 00000b90 2**0 CONTENTS, READONLY 26 .debug_aranges 00000120 0000000000000000 0000000000000000 00000c70 2**4 CONTENTS, READONLY, DEBUGGING 27 .debug_pubnames 000000aa 0000000000000000 0000000000000000 00000d90 2**0 CONTENTS, READONLY, DEBUGGING 28 .debug_info 000004a8 0000000000000000 0000000000000000 00000e3a 2**0 CONTENTS, READONLY, DEBUGGING 29 .debug_abbrev 000001b9 0000000000000000 0000000000000000 000012e2 2**0 CONTENTS, READONLY, DEBUGGING 30 .debug_line 000002a9 0000000000000000 0000000000000000 0000149b 2**0 CONTENTS, READONLY, DEBUGGING 31 .debug_frame 000000e0 0000000000000000 0000000000000000 00001748 2**3 CONTENTS, READONLY, DEBUGGING 32 .debug_str 00000113 0000000000000000 0000000000000000 00001828 2**0 CONTENTS, READONLY, DEBUGGING SYMBOL TABLE: 00000000100001c8 l d .interp 0000000000000000 00000000100001dc l d .note.ABI-tag 0000000000000000 00000000100001fc l d .note.SuSE 0000000000000000 0000000010000218 l d .hash 0000000000000000 0000000010000238 l d .dynsym 0000000000000000 0000000010000280 l d .dynstr 0000000000000000 00000000100002bc l d .gnu.version 0000000000000000 00000000100002c8 l d .gnu.version_r 0000000000000000 00000000100002e8 l d .rela.plt 0000000000000000 0000000010000318 l d .init 0000000000000000 0000000010000348 l d .text 0000000000000000 00000000100007c8 l d .fini 0000000000000000 00000000100007f0 l d .rodata 0000000000000000 0000000010010820 l d .data 0000000000000000 0000000010010858 l d .branch_lt 0000000000000000 0000000010010858 l d .eh_frame 0000000000000000 0000000010010860 l d .opd 0000000000000000 0000000010010980 l d .dynamic 0000000000000000 0000000010010af0 l d .ctors 0000000000000000 0000000010010b00 l d .dtors 0000000000000000 0000000010010b10 l d .jcr 0000000000000000 0000000010010b18 l d .got 0000000000000000 0000000010010b90 l d .sbss 0000000000000000 0000000010010b90 l d .plt 0000000000000000 0000000010010bd8 l d .bss 0000000000000000 0000000000000000 l d .comment 0000000000000000 0000000000000000 l d .debug_aranges 0000000000000000 0000000000000000 l d .debug_pubnames 0000000000000000 0000000000000000 l d .debug_info 0000000000000000 0000000000000000 l d .debug_abbrev 0000000000000000 0000000000000000 l d .debug_line 0000000000000000 0000000000000000 l d .debug_frame 0000000000000000 0000000000000000 l d .debug_str 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/kernel-headers/asm/unistd.h 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/kernel-headers/asm-ppc64/unistd.h 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/kernel-headers/asm/unistd.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 abi-note.S 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/abi-tag.h 0000000000000000 l df *ABS* 0000000000000000 abi-note.S 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 abi-note.S 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 abi-note.S 0000000000000000 l df *ABS* 0000000000000000 suse-note.S 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 suse-note.S 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 suse-note.S 0000000000000000 l df *ABS* 0000000000000000 init.c 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/defs.h 0000000000000000 l df *ABS* 0000000000000000 initfini.c 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S 0000000010010878 l .opd 0000000000000018 call_gmon_start 00000000100003bc l F .text 0000000000000000 .call_gmon_start 0000000000000000 l df *ABS* 0000000000000000 crtstuff.c 0000000010010af0 l O .ctors 0000000000000000 __CTOR_LIST__ 0000000010010b00 l O .dtors 0000000000000000 __DTOR_LIST__ 0000000010010b10 l O .jcr 0000000000000000 __JCR_LIST__ 0000000010010848 l O .data 0000000000000000 p.0 0000000010010bd8 l O .bss 0000000000000001 completed.1 00000000100108c0 l .opd 0000000000000018 __do_global_dtors_aux 0000000010000400 l F .text 0000000000000000 .__do_global_dtors_aux 00000000100108d8 l .opd 0000000000000018 frame_dummy 0000000010000494 l F .text 0000000000000000 .frame_dummy 0000000000000000 l df *ABS* 0000000000000000 crtstuff.c 0000000010010af8 l O .ctors 0000000000000000 __CTOR_END__ 0000000010010b08 l O .dtors 0000000000000000 __DTOR_END__ 0000000010010858 l O .eh_frame 0000000000000000 __FRAME_END__ 0000000010010b10 l O .jcr 0000000000000000 __JCR_END__ 0000000010010968 l .opd 0000000000000018 __do_global_ctors_aux 0000000010000708 l F .text 0000000000000000 .__do_global_ctors_aux 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/defs.h 0000000000000000 l df *ABS* 0000000000000000 initfini.c 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/config.h 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 /usr/src/packages/BUILD/glibc-2.3/cc/csu/crtn.S 0000000000000000 l df *ABS* 0000000000000000 testwatch.c 0000000000000000 l df *ABS* 0000000000000000 elf-init.c 0000000000000000 l df *ABS* 0000000000000000 crtsavres.S 0000000000000000 l df *ABS* 0000000000000000 include/ppc-asm.h 0000000000000000 l df *ABS* 0000000000000000 crtsavres.asm 0000000000000000 l df *ABS* 0000000000000000 crtsavres.S 0000000000000000 l df *ABS* 0000000000000000 <command line> 0000000000000000 l df *ABS* 0000000000000000 <built-in> 0000000000000000 l df *ABS* 0000000000000000 crtsavres.S 00000000100007c8 g F .fini 0000000000000000 ._fini 0000000010010980 g O .dynamic 0000000000000000 _DYNAMIC 00000000100005cc g F .text 0000000000000098 .__libc_csu_fini 00000000100004e4 g F .text 0000000000000040 .subr2 0000000010010820 g *ABS* 0000000000000000 __fini_array_end 0000000010000364 g .text 0000000000000000 .__libc_start_main 0000000010010840 g O .data 0000000000000000 .hidden __dso_handle 0000000010010938 g F .opd 0000000000000018 __libc_csu_fini 0000000010010850 g O .data 0000000000000008 lookatme 0000000010010890 g F .opd 0000000000000018 _init 00000000100108f0 g F .opd 0000000000000018 subr2 0000000010010860 g F .opd 0000000000000018 _start 0000000010010908 g F .opd 0000000000000018 subr1 0000000010000380 g F .text 000000000000003c ._start 0000000010010820 g *ABS* 0000000000000000 __fini_array_start 0000000010010950 g F .opd 0000000000000018 __libc_csu_init 0000000010010b90 g *ABS* 0000000000000000 __bss_start 0000000010010920 g F .opd 0000000000000018 main 0000000000000000 F *UND* 0000000000000018 __libc_start_main@@GLIBC_2.3 0000000010010820 g *ABS* 0000000000000000 __init_array_end 0000000010000588 g F .text 0000000000000044 .main 0000000010010820 w .data 0000000000000000 data_start 0000000000000000 *UND* 0000000000000000 .__data_start 00000000100108a8 g F .opd 0000000000000018 _fini 0000000010000524 g F .text 0000000000000064 .subr1 0000000010010b90 g *ABS* 0000000000000000 _edata 0000000010000664 g F .text 00000000000000a4 .__libc_csu_init 0000000010000348 g .text 0000000000000000 ._Jv_RegisterClasses 0000000010010be0 g *ABS* 0000000000000000 _end 0000000010010820 g *ABS* 0000000000000000 __init_array_start 00000000100007f0 g O .rodata 0000000000000004 _IO_stdin_used 0000000010000318 g F .init 0000000000000000 ._init 0000000010010820 g .data 0000000000000000 __data_start 0000000000000000 w *UND* 0000000000000000 _Jv_RegisterClasses 0000000000000000 w *UND* 0000000000000000 __gmon_start__ 0000000010010bdc g O .bss 0000000000000004 checkmeout Contents of section .interp: 100001c8 2f6c6962 36342f6c 6436342e 736f2e31 /lib64/ld64.so.1 100001d8 00 . Contents of section .note.ABI-tag: 100001dc 00000004 00000010 00000001 474e5500 ............GNU. 100001ec 00000000 00000002 00000004 00000015 ................ Contents of section .note.SuSE: 100001fc 00000005 00000002 00000001 53755345 ............SuSE 1000020c 00000000 09010000 ........ Contents of section .hash: 10000218 00000003 00000003 00000002 00000001 ................ 10000228 00000000 00000000 00000000 00000000 ................ Contents of section .dynsym: 10000238 00000000 00000000 00000000 00000000 ................ 10000248 00000000 00000000 0000000b 12000000 ................ 10000258 00000000 00000000 00000000 00000018 ................ 10000268 0000001d 20000000 00000000 00000000 .... ........... 10000278 00000000 00000000 ........ Contents of section .dynstr: 10000280 006c6962 632e736f 2e36005f 5f6c6962 .libc.so.6.__lib 10000290 635f7374 6172745f 6d61696e 005f4a76 c_start_main._Jv 100002a0 5f526567 69737465 72436c61 73736573 _RegisterClasses 100002b0 00474c49 42435f32 2e3300 .GLIBC_2.3. Contents of section .gnu.version: 100002bc 00000002 0000 ...... Contents of section .gnu.version_r: 100002c8 00010001 00000001 00000010 00000000 ................ 100002d8 0d696913 00000002 00000031 00000000 .ii........1.... Contents of section .rela.plt: 100002e8 00000000 10010ba8 00000001 00000015 ................ 100002f8 00000000 00000000 00000000 10010bc0 ................ 10000308 00000002 00000015 00000000 00000000 ................ Contents of section .init: 10000318 7c0802a6 f8010010 f821ff91 48000099 |........!..H... 10000328 4800016d 60000000 480003d9 60000000 H..m`...H...`... 10000338 38210070 e8010010 7c0803a6 4e800020 8!.p....|...N.. Contents of section .text: 10000348 3d820000 f8410028 e96c80a8 e84c80b0 =....A.(.l...L.. 10000358 7d6903a6 e96c80b8 4e800420 3d820000 }i...l..N.. =... 10000368 f8410028 e96c8090 e84c8098 7d6903a6 .A.(.l...L..}i.. 10000378 e96c80a0 4e800420 7c290b78 782106e4 .l..N.. |).xx!.. 10000388 38000000 f821ff81 7c0803a6 f8010000 8....!..|....... 10000398 e9028008 4bffffc8 e8410028 00000000 ....K....A.(.... 100003a8 000c2040 00000000 00000024 00065f73 .. @.......$.._s 100003b8 74617274 7c0802a6 f8010010 f821ff91 tart|........!.. 100003c8 e9228010 2fa90000 419e0020 e8090000 ."../...A.. .... 100003d8 7c0903a6 f8410028 e8490008 e9690010 |....A.(.I...i.. 100003e8 4e800421 e8410028 38210070 e8010010 N..!.A.(8!.p.... 100003f8 7c0803a6 4e800020 7c0802a6 e9628018 |...N.. |....b.. 10000408 fbe1fff8 f8010010 f821ff81 880b0000 .........!...... 10000418 2f800000 409e0064 ebe28020 e93f0000 /...@..d... .?.. 10000428 e9490000 2faa0000 40be000c 48000044 .I../...@...H..D 10000438 ebe28020 e93f0000 39290008 f93f0000 ... .?..9)...?.. 10000448 e80a0000 f8410028 e96a0010 7c0903a6 .....A.(.j..|... 10000458 e84a0008 4e800421 e8410028 e93f0000 .J..N..!.A.(.?.. 10000468 e9490000 2faa0000 409effc8 e9628018 .I../...@....b.. 10000478 38000001 980b0000 38210080 e8010010 8.......8!...... 10000488 ebe1fff8 7c0803a6 4e800020 7c0802a6 ....|...N.. |... 10000498 e8628028 f8010010 f821ff91 e8030000 .b.(.....!...... 100004a8 2fa00000 419e0010 e8028030 2fa00000 /...A......0/... 100004b8 409e0014 38210070 e8010010 7c0803a6 @...8!.p....|... 100004c8 4e800020 4bfffe7d e8410028 38210070 N.. K..}.A.(8!.p 100004d8 e8010010 7c0803a6 4e800020 fbe1fff8 ....|...N.. .... 100004e8 f821ffc1 7c3f0b78 f87f0070 e93f0070 .!..|?.x...p.?.p 100004f8 38000009 90090000 e93f0070 38000001 8........?.p8... 10000508 90090000 e8210000 ebe1fff8 4e800020 .....!......N.. 10000518 00000000 00000000 80010001 7c0802a6 ............|... 10000528 fbe1fff8 f8010010 f821ff71 7c3f0b78 .........!.q|?.x 10000538 38000009 901f0070 387f0070 4bffffa1 8......p8..pK... 10000548 e9228038 38000002 90090000 e9228040 .".88........".@ 10000558 c8028048 d8090000 38000002 901f0070 ...H....8......p 10000568 e8210000 e8010010 7c0803a6 ebe1fff8 .!......|....... 10000578 4e800020 00000000 00000001 80010001 N.. ............ 10000588 7c0802a6 fbe1fff8 f8010010 f821ff71 |............!.q 10000598 7c3f0b78 38000000 901f0070 4bffff81 |?.x8......pK... 100005a8 7c030378 e8210000 e8010010 7c0803a6 |..x.!......|... 100005b8 ebe1fff8 4e800020 00000000 00000001 ....N.. ........ 100005c8 80010001 7c0802a6 e9628058 fbe1fff8 ....|....b.X.... 100005d8 f8010010 e8028050 fba1ffe8 7c0b0050 .......P....|..P 100005e8 f821ff71 7c1f1e74 2fbf0000 3bffffff .!.q|..t/...;... 100005f8 40be000c 4800003c e9628058 7be91f24 @...H..<.b.X{..$ 10000608 7ffdfb78 7d49582a 3bffffff e80a0000 ...x}IX*;....... 10000618 f8410028 7c0903a6 e96a0010 e84a0008 .A.(|....j...J.. 10000628 4e800421 e8410028 2fbd0000 409effcc N..!.A.(/...@... 10000638 48000191 60000000 38210090 e8010010 H...`...8!...... 10000648 eba1ffe8 7c0803a6 ebe1fff8 4e800020 ....|.......N.. 10000658 00000000 00000001 80030000 7c0802a6 ............|... 10000668 fbe1fff8 f8010010 f821ff81 4bfffca5 .........!..K... 10000678 60000000 3be00000 e8028060 e9628068 `...;......`.b.h 10000688 7c0b0050 7809e8c3 40820018 38210080 |..Px...@...8!.. 10000698 e8010010 ebe1fff8 7c0803a6 4e800020 ........|...N.. 100006a8 7be91f24 3bff0001 7d49582a e80a0000 {..$;...}IX*.... 100006b8 f8410028 7c0903a6 e96a0010 e84a0008 .A.(|....j...J.. 100006c8 4e800421 e8410028 e8028060 e9628068 N..!.A.(...`.b.h 100006d8 7c0b0050 7c001e74 7fbf0040 419cffc4 |..P|..t...@A... 100006e8 38210080 e8010010 ebe1fff8 7c0803a6 8!..........|... 100006f8 4e800020 00000000 00000001 80010000 N.. ............ 10000708 7c0802a6 e9228070 fbe1fff8 f8010010 |....".p........ 10000718 3be9fff8 f821ff81 e809fff8 2fa0ffff ;....!....../... 10000728 419e0034 7c090378 e8090000 f8410028 A..4|..x.....A.( 10000738 7c0903a6 e9690010 e8490008 4e800421 |....i...I..N..! 10000748 e8410028 e81ffff9 2fa0ffff 7c090378 .A.(..../...|..x 10000758 409effd8 38210080 e8010010 ebe1fff8 @...8!.......... 10000768 7c0803a6 4e800020 4e800020 7d8902a6 |...N.. N.. }... 10000778 780b1f24 34408000 7d8b6050 7c42fe76 x..$4@..}.`P|B.v 10000788 780b1764 7c425838 7d8b6050 7d8c1214 x..d|BX8}.`P}... 10000798 3d8c0001 e96c03dc 398c03dc e84c0008 =....l..9....L.. 100007a8 7d6903a6 e96c0010 4e800420 38000000 }i...l..N.. 8... 100007b8 4bffffbc 38000001 4bffffb4 K...8...K... Contents of section .fini: 100007c8 7c0802a6 f8010010 f821ff91 60000000 |........!..`... 100007d8 4bfffc29 60000000 38210070 e8010010 K..)`...8!.p.... 100007e8 7c0803a6 4e800020 |...N.. Contents of section .rodata: 100007f0 00020001 00000000 49206861 7665206e ........I have n 10000800 6f742063 68616e67 65640000 00000000 ot changed...... 10000810 6368616e 67652069 7320676f 6f640000 change is good.. Contents of section .data: 10010820 00000000 00000000 00000000 10010920 ............... 10010830 00000000 10010950 00000000 10010938 .......P.......8 10010840 00000000 00000000 00000000 10010b08 ................ 10010850 00000000 100007f8 ........ Contents of section .eh_frame: 10010858 00000000 .... Contents of section .opd: 10010860 00000000 10000380 00000000 10018b18 ................ 10010870 00000000 00000000 00000000 100003bc ................ 10010880 00000000 10018b18 00000000 00000000 ................ 10010890 00000000 10000318 00000000 10018b18 ................ 100108a0 00000000 00000000 00000000 100007c8 ................ 100108b0 00000000 10018b18 00000000 00000000 ................ 100108c0 00000000 10000400 00000000 10018b18 ................ 100108d0 00000000 00000000 00000000 10000494 ................ 100108e0 00000000 10018b18 00000000 00000000 ................ 100108f0 00000000 100004e4 00000000 10018b18 ................ 10010900 00000000 00000000 00000000 10000524 ...............$ 10010910 00000000 10018b18 00000000 00000000 ................ 10010920 00000000 10000588 00000000 10018b18 ................ 10010930 00000000 00000000 00000000 100005cc ................ 10010940 00000000 10018b18 00000000 00000000 ................ 10010950 00000000 10000664 00000000 10018b18 .......d........ 10010960 00000000 00000000 00000000 10000708 ................ 10010970 00000000 10018b18 00000000 00000000 ................ Contents of section .dynamic: 10010980 00000000 00000001 00000000 00000001 ................ 10010990 00000000 0000000c 00000000 10010890 ................ 100109a0 00000000 0000000d 00000000 100108a8 ................ 100109b0 00000000 00000004 00000000 10000218 ................ 100109c0 00000000 00000005 00000000 10000280 ................ 100109d0 00000000 00000006 00000000 10000238 ...............8 100109e0 00000000 0000000a 00000000 0000003b ...............; 100109f0 00000000 0000000b 00000000 00000018 ................ 10010a00 00000000 00000015 00000000 00000000 ................ 10010a10 00000000 00000003 00000000 10010b90 ................ 10010a20 00000000 00000002 00000000 00000030 ...............0 10010a30 00000000 00000014 00000000 00000007 ................ 10010a40 00000000 00000017 00000000 100002e8 ................ 10010a50 00000000 70000000 00000000 10000794 ....p........... 10010a60 00000000 6ffffffe 00000000 100002c8 ....o........... 10010a70 00000000 6fffffff 00000000 00000001 ....o........... 10010a80 00000000 6ffffff0 00000000 100002bc ....o........... 10010a90 00000000 00000000 00000000 00000000 ................ 10010aa0 00000000 00000000 00000000 00000000 ................ 10010ab0 00000000 00000000 00000000 00000000 ................ 10010ac0 00000000 00000000 00000000 00000000 ................ 10010ad0 00000000 00000000 00000000 00000000 ................ 10010ae0 00000000 00000000 00000000 00000000 ................ Contents of section .ctors: 10010af0 ffffffff ffffffff 00000000 00000000 ................ Contents of section .dtors: 10010b00 ffffffff ffffffff 00000000 00000000 ................ Contents of section .jcr: 10010b10 00000000 00000000 ........ Contents of section .got: 10010b18 00000000 10018b18 00000000 10010820 ............... 10010b28 00000000 00000000 00000000 10010bd8 ................ 10010b38 00000000 10010848 00000000 10010b10 .......H........ 10010b48 00000000 00000000 00000000 10010bdc ................ 10010b58 00000000 10010850 00000000 10000810 .......P........ 10010b68 00000000 10010820 00000000 10010820 ....... ....... 10010b78 00000000 10010820 00000000 10010820 ....... ....... 10010b88 00000000 10010af8 ........ Contents of section .comment: 0000 00474343 3a202847 4e552920 332e332e .GCC: (GNU) 3.3. 0010 33202853 75534520 4c696e75 78290000 3 (SuSE Linux).. 0020 4743433a 2028474e 55292033 2e332e33 GCC: (GNU) 3.3.3 0030 20285375 5345204c 696e7578 29000047 (SuSE Linux)..G 0040 43433a20 28474e55 2920332e 332e3320 CC: (GNU) 3.3.3 0050 28537553 45204c69 6e757829 00004743 (SuSE Linux)..GC 0060 433a2028 474e5529 20332e33 2e332028 C: (GNU) 3.3.3 ( 0070 53755345 204c696e 75782900 00474343 SuSE Linux)..GCC 0080 3a202847 4e552920 332e332e 33202853 : (GNU) 3.3.3 (S 0090 75534520 4c696e75 78290000 4743433a uSE Linux)..GCC: 00a0 2028474e 55292033 2e332e33 20285375 (GNU) 3.3.3 (Su 00b0 5345204c 696e7578 29000047 43433a20 SE Linux)..GCC: 00c0 28474e55 2920332e 332e3320 28537553 (GNU) 3.3.3 (SuS 00d0 45204c69 6e757829 00 E Linux). Contents of section .debug_aranges: 0000 0000002c 00020000 00000800 00000000 ...,............ 0010 00000000 10000380 00000000 0000003c ...............< 0020 00000000 00000000 00000000 00000000 ................ 0030 0000004c 00020000 01150800 00000000 ...L............ 0040 00000000 100007c8 00000000 00000010 ................ 0050 00000000 10000318 00000000 00000010 ................ 0060 00000000 100003bc 00000000 00000044 ...............D 0070 00000000 00000000 00000000 00000000 ................ 0080 0000002c 00020000 01920800 00000000 ...,............ 0090 00000000 100004e4 00000000 000000e8 ................ 00a0 00000000 00000000 00000000 00000000 ................ 00b0 0000002c 00020000 02fd0800 00000000 ...,............ 00c0 00000000 100005cc 00000000 0000013c ...............< 00d0 00000000 00000000 00000000 00000000 ................ 00e0 0000003c 00020000 042b0800 00000000 ...<.....+...... 00f0 00000000 100007e0 00000000 00000010 ................ 0100 00000000 10000338 00000000 00000010 .......8........ 0110 00000000 00000000 00000000 00000000 ................ Contents of section .debug_pubnames: 0000 00000021 00020000 00860000 008f0000 ...!............ 0010 00735f49 4f5f7374 64696e5f 75736564 .s_IO_stdin_used 0020 00000000 00000000 47000200 00019200 ........G....... 0030 00016b00 00007873 75627232 00000000 ..k...xsubr2.... 0040 b7737562 72310000 0000ed6d 61696e00 .subr1.....main. 0050 00000124 63686563 6b6d656f 75740000 ...$checkmeout.. 0060 0001416c 6f6f6b61 746d6500 00000000 ..Alookatme..... 0070 00000036 00020000 02fd0000 012e0000 ...6............ 0080 004d5f5f 6c696263 5f637375 5f66696e .M__libc_csu_fin 0090 69000000 00785f5f 6c696263 5f637375 i....x__libc_csu 00a0 5f696e69 74000000 0000 _init..... Contents of section .debug_info: 0000 00000082 00020000 00000801 00000000 ................ 0010 00000000 10000380 00000000 100003bc ................ 0020 2e2e2f73 79736465 70732f70 6f776572 ../sysdeps/power 0030 70632f70 6f776572 70633634 2f656c66 pc/powerpc64/elf 0040 2f737461 72742e53 002f7573 722f7372 /start.S./usr/sr 0050 632f7061 636b6167 65732f42 55494c44 c/packages/BUILD 0060 2f676c69 62632d32 2e332f63 73750047 /glibc-2.3/csu.G 0070 4e552041 5320322e 31352e39 302e302e NU AS 2.15.90.0. 0080 312e3100 80010000 008b0002 00000014 1.1............. 0090 08010000 00950000 00001000 03bc0000 ................ 00a0 00001000 03bc0000 00d30000 00210000 .............!.. 00b0 00630102 00000047 08070200 00001301 .c.....G........ 00c0 08020000 00000207 02000000 4c040702 ............L... 00d0 00000015 01060200 00005902 0503696e ..........Y...in 00e0 74000405 02000000 8b080502 00000047 t..............G 00f0 08070200 00001c01 06040000 007c0119 .............|.. 0100 00000089 01090300 00000010 0007f005 ................ 0110 00000057 00000000 79000200 00005608 ...W....y.....V. 0120 01000000 b92f7573 722f7372 632f7061 ...../usr/src/pa 0130 636b6167 65732f42 55494c44 2f676c69 ckages/BUILD/gli 0140 62632d32 2e332f63 632f6373 752f6372 bc-2.3/cc/csu/cr 0150 74692e53 002f7573 722f7372 632f7061 ti.S./usr/src/pa 0160 636b6167 65732f42 55494c44 2f676c69 ckages/BUILD/gli 0170 62632d32 2e332f63 73750047 4e552041 bc-2.3/csu.GNU A 0180 5320322e 31352e39 302e302e 312e3100 S 2.15.90.0.1.1. 0190 80010000 01670002 00000066 08010000 .....g.....f.... 01a0 01550000 00001000 05cc0000 00001000 .U.............. 01b0 04e47465 73747761 7463682e 63002f68 ..testwatch.c./h 01c0 6f6d652f 7067696c 6c69616d 2f776f72 ome/pgilliam/wor 01d0 6b2f6764 622d776f 726b2f72 6561642d k/gdb-work/read- 01e0 77726974 652f6275 696c642f 67646200 write/build/gdb. 01f0 474e5520 4320332e 332e3320 28537553 GNU C 3.3.3 (SuS 0200 45204c69 6e757829 00010200 0000aa01 E Linux)........ 0210 73756272 32000105 01000000 00100004 subr2........... 0220 e4000000 00100005 24016f03 61646472 ........$.o.addr 0230 00010400 0000aa03 91f00000 04080000 ................ 0240 00b00569 6e740004 05060000 00ed0173 ...int.........s 0250 75627231 00010c00 00000010 00052400 ubr1..........$. 0260 00000010 00058801 6f077761 74636874 ........o.watcht 0270 68697300 010d0000 00b00391 f0000008 his............. 0280 00000124 016d6169 6e000117 000000b0 ...$.main....... 0290 00000000 10000588 00000000 100005cc ................ 02a0 016f0772 65745f76 616c0001 18000000 .o.ret_val...... 02b0 b00391f0 00000963 6865636b 6d656f75 .......checkmeou 02c0 74000101 000000b0 01090300 00000010 t............... 02d0 010bdc09 6c6f6f6b 61746d65 00010200 ....lookatme.... 02e0 00015c01 09030000 00001001 08500408 ..\..........P.. 02f0 00000162 05636861 72000108 00000001 ...b.char....... 0300 2a000200 00010008 01000001 9d000000 *............... 0310 00100007 08000000 00100005 cc000000 ................ 0320 cf000000 21000000 63010200 00008b08 ....!...c....... 0330 05030000 00a402d5 0000003f 02000000 ...........?.... 0340 47080704 696e7400 04050500 00007801 G...int.......x. 0350 00000094 014a0100 00000010 0005cc00 .....J.......... 0360 00000010 00066401 51066900 014c0000 ......d.Q.i..L.. 0370 0034016f 00050000 00c00100 0000eb01 .4.o............ 0380 2c010000 00001000 06640000 00001000 ,........d...... 0390 07080151 07000000 00100006 7c000000 ...Q........|... 03a0 00100006 fc080000 010e0140 000000c0 ...........@.... 03b0 06690001 41000000 34016f00 00090000 .i..A...4.o..... 03c0 00340a00 0000d000 0000d20b 000c010d .4.............. 03d0 08000000 d00e0000 00bc011a 000000c5 ................ 03e0 01010a00 0000f000 0000d20b 000e0000 ................ 03f0 00ab011b 000000e5 01010a00 00010800 ................ 0400 0000d20b 000e0000 00fb011c 000000fd ................ 0410 01010a00 00012000 0000d20b 000e0000 ...... ......... 0420 00da011d 00000115 01010000 00007900 ..............y. 0430 02000001 a9080100 0002302f 7573722f ..........0/usr/ 0440 7372632f 7061636b 61676573 2f425549 src/packages/BUI 0450 4c442f67 6c696263 2d322e33 2f63632f LD/glibc-2.3/cc/ 0460 6373752f 6372746e 2e53002f 7573722f csu/crtn.S./usr/ 0470 7372632f 7061636b 61676573 2f425549 src/packages/BUI 0480 4c442f67 6c696263 2d322e33 2f637375 LD/glibc-2.3/csu 0490 00474e55 20415320 322e3135 2e39302e .GNU AS 2.15.90. 04a0 302e312e 31008001 0.1.1... Contents of section .debug_abbrev: 0000 01110010 06110112 0103081b 08250813 .............%.. 0010 05000000 01110110 06120111 01030e1b ................ 0020 0e250e13 0b000002 2400030e 0b0b3e0b .%......$.....>. 0030 00000324 0003080b 0b3e0b00 00043400 ...$.....>....4. 0040 030e3a0b 3b0b4913 3f0c020a 00000526 ..:.;.I.?......& 0050 00491300 00000111 00100603 081b0825 .I.............% 0060 08130500 00000111 01100612 01110103 ................ 0070 081b0825 08130b00 00022e01 01133f0c ...%..........?. 0080 03083a0b 3b0b270c 11011201 400a0000 ..:.;.'.....@... 0090 03050003 083a0b3b 0b491302 0a000004 .....:.;.I...... 00a0 0f000b0b 49130000 05240003 080b0b3e ....I....$.....> 00b0 0b000006 2e010113 3f0c0308 3a0b3b0b ........?...:.;. 00c0 11011201 400a0000 07340003 083a0b3b ....@....4...:.; 00d0 0b491302 0a000008 2e010113 3f0c0308 .I..........?... 00e0 3a0b3b0b 49131101 1201400a 00000934 :.;.I.....@....4 00f0 0003083a 0b3b0b49 133f0c02 0a000000 ...:.;.I.?...... 0100 01110110 06120111 01030e1b 0e250e13 .............%.. 0110 0b000002 2400030e 0b0b3e0b 00000316 ....$.....>..... 0120 00030e3a 0b3b0b49 13000004 24000308 ...:.;.I....$... 0130 0b0b3e0b 0000052e 0101133f 0c030e3a ..>........?...: 0140 0b3b0b27 0c110112 01400a00 00063400 .;.'.....@....4. 0150 03083a0b 3b0b4913 020a0000 070b0111 ..:.;.I......... 0160 01120100 00083400 030e3a0b 3b0b4913 ......4...:.;.I. 0170 00000926 00491300 000a0101 01134913 ...&.I........I. 0180 00000b21 0000000c 1500270c 00000d0f ...!......'..... 0190 000b0b49 1300000e 3400030e 3a0b3b0b ...I....4...:.;. 01a0 49133f0c 3c0c0000 00011100 10060308 I.?.<........... 01b0 1b082508 13050000 00 ..%...... Contents of section .debug_line: 0000 0000005d 00020000 003c0401 fb0e0a00 ...].....<...... 0010 01010101 00000001 2e2e2f73 79736465 ........../sysde 0020 70732f70 6f776572 70632f70 6f776572 ps/powerpc/power 0030 70633634 2f656c66 00007374 6172742e pc64/elf..start. 0040 53000100 00000009 02000000 00100003 S............... 0050 80032c01 1f1e1e1e 1e212020 02070001 ..,......! .... 0060 01000000 16000200 00001004 01fb0e0a ................ 0070 00010101 01000000 01000000 00001600 ................ 0080 02000000 100401fb 0e0a0001 01010100 ................ 0090 00000100 00000000 20000200 00001a04 ........ ....... 00a0 01fb0e0a 00010101 01000000 0100696e ..............in 00b0 69742e63 00000000 00000000 98000200 it.c............ 00c0 00004304 01fb0e0a 00010101 01000000 ..C............. 00d0 012f7573 722f7372 632f7061 636b6167 ./usr/src/packag 00e0 65732f42 55494c44 2f676c69 62632d32 es/BUILD/glibc-2 00f0 2e332f63 632f6373 75000063 7274692e .3/cc/csu..crti. 0100 53000100 00000009 02000000 00100007 S............... 0110 c803cc00 011e1e02 02000101 00090200 ................ 0120 00000010 00031803 35011e1e 1e020100 ........5....... 0130 01010009 02000000 00100003 bc031501 ................ 0140 1e1e1e1e 1e1e1e1e 1e1e1e1e 1f1e1e1e ................ 0150 02010001 01000000 44000200 00001f04 ........D....... 0160 01fb0e0a 00010101 01000000 01007465 ..............te 0170 73747761 7463682e 63000000 00000009 stwatch.c....... 0180 02000000 00100004 e413483a 3a67562d ..........H::gV- 0190 2d3a3a2c 82562d1e 02090001 01000000 -::,.V-......... 01a0 8f000200 00006004 01fb0e0a 00010101 ......`......... 01b0 01000000 012f7573 722f6c69 6236342f ...../usr/lib64/ 01c0 6763632d 6c69622f 706f7765 72706336 gcc-lib/powerpc6 01d0 342d7375 73652d6c 696e7578 2f332e33 4-suse-linux/3.3 01e0 2e332f69 6e636c75 64650000 656c662d .3/include..elf- 01f0 696e6974 2e630000 00007374 64646566 init.c....stddef 0200 2e680001 00000000 09020000 00001000 .h.............. 0210 05cc03c9 00011f1b 2d1b1f1b 1f1e56c8 ........-.....V. 0220 035ba903 104731aa 1c1e7e02 0e000101 .[...G1...~..... 0230 00000075 00020000 00430401 fb0e0a00 ...u.....C...... 0240 01010101 00000001 2f757372 2f737263 ......../usr/src 0250 2f706163 6b616765 732f4255 494c442f /packages/BUILD/ 0260 676c6962 632d322e 332f6363 2f637375 glibc-2.3/cc/csu 0270 00006372 746e2e53 00010000 00000902 ..crtn.S........ 0280 00000000 100007e0 0314011e 1e1e0201 ................ 0290 00010100 09020000 00001000 03380309 .............8.. 02a0 011e1e1e 02010001 01 ......... Contents of section .debug_frame: 0000 0000000c ffffffff 01000178 410c0100 ...........xA... 0010 0000001c 00000000 00000000 100004e4 ................ 0020 00000000 00000040 480e409f 01440d1f .......@H.@..D.. 0030 00000024 00000000 00000000 10000524 ...$...........$ 0040 00000000 00000064 500e9001 116c7e9f .......dP....l~. 0050 01440d1f 00000000 00000024 00000000 .D.........$.... 0060 00000000 10000588 00000000 00000044 ...............D 0070 500e9001 116c7e9f 01440d1f 00000000 P....l~..D...... 0080 0000000c ffffffff 01000178 410c0100 ...........xA... 0090 00000024 00000080 00000000 100005cc ...$............ 00a0 00000000 00000098 600e9001 9d03116c ........`......l 00b0 7e9f0100 00000000 00000024 00000080 ~..........$.... 00c0 00000000 10000664 00000000 000000a4 .......d........ 00d0 500e8001 116c7e9f 01000000 00000000 P....l~......... Contents of section .debug_str: 0000 73686f72 7420756e 7369676e 65642069 short unsigned i 0010 6e740075 6e736967 6e656420 63686172 nt.unsigned char 0020 002f7573 722f7372 632f7061 636b6167 ./usr/src/packag 0030 65732f42 55494c44 2f676c69 62632d32 es/BUILD/glibc-2 0040 2e332f63 7375006c 6f6e6720 756e7369 .3/csu.long unsi 0050 676e6564 20696e74 0073686f 72742069 gned int.short i 0060 6e740047 4e552043 20332e33 2e332028 nt.GNU C 3.3.3 ( 0070 53755345 204c696e 75782900 5f494f5f SuSE Linux)._IO_ 0080 73746469 6e5f7573 6564006c 6f6e6720 stdin_used.long 0090 696e7400 5f5f6c69 62635f63 73755f66 int.__libc_csu_f 00a0 696e6900 73697a65 5f74005f 5f696e69 ini.size_t.__ini 00b0 745f6172 7261795f 656e6400 5f5f696e t_array_end.__in 00c0 69745f61 72726179 5f737461 72740065 it_array_start.e 00d0 6c662d69 6e69742e 63005f5f 66696e69 lf-init.c.__fini 00e0 5f617272 61795f65 6e64005f 5f6c6962 _array_end.__lib 00f0 635f6373 755f696e 6974005f 5f66696e c_csu_init.__fin 0100 695f6172 7261795f 73746172 74007369 i_array_start.si 0110 7a6500 ze. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam @ 2005-12-02 20:28 ` Mark Kettenis 2005-12-02 21:19 ` Daniel Jacobowitz 2005-12-03 4:53 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) Paul Gilliam 2005-12-02 21:44 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner 2005-12-02 22:19 ` Jim Blandy 2 siblings, 2 replies; 39+ messages in thread From: Mark Kettenis @ 2005-12-02 20:28 UTC (permalink / raw) To: pgilliam; +Cc: jimb, gdb-patches > From: Paul Gilliam <pgilliam@us.ibm.com> > Date: Fri, 2 Dec 2005 11:20:22 -0800 > > And here is the revised patch: > > 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > and put it into the architecture vector. Paul, There are a couple of problems with your patch. Please read read the GNU condig standards http://www.gnu.org/prep/standards/. Here are a fuw issues: * Please put a space before the ( that starts the functions arguments. * ins_changes_sp contains unused variables. Please configure gdb with --enable-gdb-build-warnings=,-Werror, this'll prevent them from slipping through. * Please don't make your lines too long. The emacs default fill-column is 72, but in general we tolerate lines that are a bit longer. But make sure the line ends before column 79/80. * "break" should be put on a line of its own. * Always surround =, -=, etc. with spaces. I think your patch should go in. But it's really Andrew Cagney's and Kevin Buettner's call. Mark ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 20:28 ` Mark Kettenis @ 2005-12-02 21:19 ` Daniel Jacobowitz 2005-12-02 21:21 ` Mark Kettenis 2005-12-03 4:53 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) Paul Gilliam 1 sibling, 1 reply; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 21:19 UTC (permalink / raw) To: Mark Kettenis; +Cc: pgilliam, jimb, gdb-patches On Fri, Dec 02, 2005 at 08:56:05PM +0100, Mark Kettenis wrote: > * ins_changes_sp contains unused variables. Please configure gdb > with --enable-gdb-build-warnings=,-Werror, this'll prevent them > from slipping through. We turn off unused warnings, IIRC. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 21:19 ` Daniel Jacobowitz @ 2005-12-02 21:21 ` Mark Kettenis 0 siblings, 0 replies; 39+ messages in thread From: Mark Kettenis @ 2005-12-02 21:21 UTC (permalink / raw) To: drow; +Cc: pgilliam, jimb, gdb-patches > Date: Fri, 2 Dec 2005 15:16:50 -0500 > From: Daniel Jacobowitz <drow@false.org> > > On Fri, Dec 02, 2005 at 08:56:05PM +0100, Mark Kettenis wrote: > > * ins_changes_sp contains unused variables. Please configure gdb > > with --enable-gdb-build-warnings=,-Werror, this'll prevent them > > from slipping through. > > We turn off unused warnings, IIRC. Oops, sorry. Must have been doing too much OpenBSD hacking lately (where we do have it turned on). Mark ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) 2005-12-02 20:28 ` Mark Kettenis 2005-12-02 21:19 ` Daniel Jacobowitz @ 2005-12-03 4:53 ` Paul Gilliam 2005-12-03 5:43 ` Paul Gilliam 1 sibling, 1 reply; 39+ messages in thread From: Paul Gilliam @ 2005-12-03 4:53 UTC (permalink / raw) To: gdb-patches; +Cc: Mark Kettenis, jimb, gdb-patches On Friday 02 December 2005 11:56, Mark Kettenis wrote: > > From: Paul Gilliam <pgilliam@us.ibm.com> > > Date: Fri, 2 Dec 2005 11:20:22 -0800 > > > > And here is the revised patch: > > > > 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > Paul, > > There are a couple of problems with your patch. Please read read the > GNU condig standards http://www.gnu.org/prep/standards/. Here are a > few issues: OK. > * Please put a space before the ( that starts the functions arguments. OK > * ins_changes_sp contains unused variables. Please configure gdb > with --enable-gdb-build-warnings=,-Werror, this'll prevent them > from slipping through. The unused variables where on purpose. They show the complete 'cracking' of the types of instructions we are interested in. But I guess a comment will work as well. > * Please don't make your lines too long. The emacs default > fill-column is 72, but in general we tolerate lines that are a bit > longer. But make sure the line ends before column 79/80. I am not sure which line you are refering to: the longest lines end in column 79. But I'll sorten them. > * "break" should be put on a line of its own. OK > * Always surround =, -=, etc. with spaces. OK > I think your patch should go in. But it's really Andrew Cagney's and > Kevin Buettner's call. > > Mark > Thank you, Mark. The 'GNU Coding Standards' is a good start, but there is nothing like to voice of experiance. So if my revised patch below addresses your concerns, I'll check it in as per Kevin Buettner's message: > On Friday 02 December 2005 12:32, Kevin Buettner wrote: > > On Fri, 2 Dec 2005 11:20:22 -0800 > > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > > and put it into the architecture vector. > > > > Your patch is okay to commit after you address Mark's concerns. > > > > Kevin > > > > -=# Paul #=- PS: I also fixed a typo or two. Revised Patch: 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -p -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 2 Dec 2005 23:08:10 -0000 @@ -502,6 +502,74 @@ rs6000_skip_prologue (CORE_ADDR pc) return pc; } +static int +insn_changes_sp (unsigned long insn) +{ + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + /* b = (insn>>11) & 0x01f */ + int subcode = (insn>> 1) & 0x3ff; + /* rc = insn & 0x001 */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_addr, func_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits. */ + if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + return 0; + + /* Get the current frame. This may be cheap, since we might have + just called it in watchpoint_check, before calling + gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward untill next 'blr'. */ + for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp (insn)) + return 0; + } + + /* Scan backward untill adjustment to stack pointer (R1). */ + for (scan_pc = pc-PPC_INSN_SIZE; + scan_pc >= func_addr; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3409,8 @@ rs6000_gdbarch_init (struct gdbarch_info set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) 2005-12-03 4:53 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) Paul Gilliam @ 2005-12-03 5:43 ` Paul Gilliam 0 siblings, 0 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-03 5:43 UTC (permalink / raw) To: gdb-patches; +Cc: Mark Kettenis, jimb, gdb-patches On Friday 02 December 2005 11:56, Mark Kettenis wrote: > > From: Paul Gilliam <pgilliam@us.ibm.com> > > Date: Fri, 2 Dec 2005 11:20:22 -0800 > > > > And here is the revised patch: > > > > 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > Paul, > > There are a couple of problems with your patch. Please read read the > GNU condig standards http://www.gnu.org/prep/standards/. Here are a > few issues: OK. > * Please put a space before the ( that starts the functions arguments. OK > * ins_changes_sp contains unused variables. Please configure gdb > with --enable-gdb-build-warnings=,-Werror, this'll prevent them > from slipping through. The unused variables where on purpose. They show the complete 'cracking' of the types of instructions we are interested in. But I guess a comment will work as well. > * Please don't make your lines too long. The emacs default > fill-column is 72, but in general we tolerate lines that are a bit > longer. But make sure the line ends before column 79/80. I am not sure which line you are refering to: the longest lines end in column 79. But I'll sorten them. > * "break" should be put on a line of its own. OK > * Always surround =, -=, etc. with spaces. OK > I think your patch should go in. But it's really Andrew Cagney's and > Kevin Buettner's call. > > Mark > Thank you, Mark. The 'GNU Coding Standards' is a good start, but there is nothing like to voice of experiance. So if my revised patch below addresses your concerns, I'll check it in as per Kevin Buettner's message: > On Friday 02 December 2005 12:32, Kevin Buettner wrote: > > On Fri, 2 Dec 2005 11:20:22 -0800 > > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > > and put it into the architecture vector. > > > > Your patch is okay to commit after you address Mark's concerns. > > > > Kevin > > > > -=# Paul #=- PS: I also fixed a typo or two. Revised Patch: 2005-12-02 Paul Gilliam <pgilliam@us.ibm.com> * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -p -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 2 Dec 2005 23:08:10 -0000 @@ -502,6 +502,74 @@ rs6000_skip_prologue (CORE_ADDR pc) return pc; } +static int +insn_changes_sp (unsigned long insn) +{ + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + /* b = (insn>>11) & 0x01f */ + int subcode = (insn>> 1) & 0x3ff; + /* rc = insn & 0x001 */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_addr, func_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits. */ + if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + return 0; + + /* Get the current frame. This may be cheap, since we might have + just called it in watchpoint_check, before calling + gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward untill next 'blr'. */ + for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp (insn)) + return 0; + } + + /* Scan backward untill adjustment to stack pointer (R1). */ + for (scan_pc = pc-PPC_INSN_SIZE; + scan_pc >= func_addr; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3409,8 @@ rs6000_gdbarch_init (struct gdbarch_info set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam 2005-12-02 20:28 ` Mark Kettenis @ 2005-12-02 21:44 ` Kevin Buettner 2005-12-06 15:20 ` Paul Gilliam 2006-01-11 17:44 ` Paul Gilliam 2005-12-02 22:19 ` Jim Blandy 2 siblings, 2 replies; 39+ messages in thread From: Kevin Buettner @ 2005-12-02 21:44 UTC (permalink / raw) To: gdb-patches On Fri, 2 Dec 2005 11:20:22 -0800 Paul Gilliam <pgilliam@us.ibm.com> wrote: > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > and put it into the architecture vector. Your patch is okay to commit after you address Mark's concerns. Kevin ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 21:44 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner @ 2005-12-06 15:20 ` Paul Gilliam 2005-12-06 15:15 ` Paul Gilliam 2005-12-08 4:42 ` Kevin Buettner 2006-01-11 17:44 ` Paul Gilliam 1 sibling, 2 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-06 15:20 UTC (permalink / raw) To: gdb-patches Cc: Kevin Buettner, gdb-patches, Mark Kettenis, Daniel Jacobowitz, Jim Blandy On Friday 02 December 2005 12:32, Kevin Buettner wrote: > On Fri, 2 Dec 2005 11:20:22 -0800 > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > Your patch is okay to commit after you address Mark's concerns. > > Kevin > > Kevin, I made the changes to address Mark's concerns. But because of the interest this has drawn, I thought I better ask again before I commited the patch. It's not perfect and will not work under all conditions. But it doesn't make things worse and does help out in many if not most coditions. I just want to place this band-aid on the bug and address all the concerns the 'right' way and CFI, etc. for later. SO, Can I Commit? -=# Paul #=- 2005-12-05 Paul Gilliam <pgilliam@us.ibm.com> * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -p -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 2 Dec 2005 23:08:10 -0000 @@ -502,6 +502,74 @@ rs6000_skip_prologue (CORE_ADDR pc) return pc; } +static int +insn_changes_sp (unsigned long insn) +{ + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + /* b = (insn>>11) & 0x01f */ + int subcode = (insn>> 1) & 0x3ff; + /* rc = insn & 0x001 */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_addr, func_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits. */ + if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + return 0; + + /* Get the current frame. This may be cheap, since we might have + just called it in watchpoint_check, before calling + gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward untill next 'blr'. */ + for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp (insn)) + return 0; + } + + /* Scan backward untill adjustment to stack pointer (R1). */ + for (scan_pc = pc-PPC_INSN_SIZE; + scan_pc >= func_addr; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3409,8 @@ rs6000_gdbarch_init (struct gdbarch_info set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-06 15:20 ` Paul Gilliam @ 2005-12-06 15:15 ` Paul Gilliam 2005-12-08 4:42 ` Kevin Buettner 1 sibling, 0 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-06 15:15 UTC (permalink / raw) To: gdb-patches Cc: Kevin Buettner, gdb-patches, Mark Kettenis, Daniel Jacobowitz, Jim Blandy On Friday 02 December 2005 12:32, Kevin Buettner wrote: > On Fri, 2 Dec 2005 11:20:22 -0800 > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > Your patch is okay to commit after you address Mark's concerns. > > Kevin > > Kevin, I made the changes to address Mark's concerns. But because of the interest this has drawn, I thought I better ask again before I commited the patch. It's not perfect and will not work under all conditions. But it doesn't make things worse and does help out in many if not most coditions. I just want to place this band-aid on the bug and address all the concerns the 'right' way and CFI, etc. for later. SO, Can I Commit? -=# Paul #=- 2005-12-05 Paul Gilliam <pgilliam@us.ibm.com> * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -p -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 2 Dec 2005 23:08:10 -0000 @@ -502,6 +502,74 @@ rs6000_skip_prologue (CORE_ADDR pc) return pc; } +static int +insn_changes_sp (unsigned long insn) +{ + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + /* b = (insn>>11) & 0x01f */ + int subcode = (insn>> 1) & 0x3ff; + /* rc = insn & 0x001 */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_addr, func_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits. */ + if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end)) + return 0; + + /* Get the current frame. This may be cheap, since we might have + just called it in watchpoint_check, before calling + gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward untill next 'blr'. */ + for (scan_pc = pc; scan_pc < func_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp (insn)) + return 0; + } + + /* Scan backward untill adjustment to stack pointer (R1). */ + for (scan_pc = pc-PPC_INSN_SIZE; + scan_pc >= func_addr; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3409,8 @@ rs6000_gdbarch_init (struct gdbarch_info set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-06 15:20 ` Paul Gilliam 2005-12-06 15:15 ` Paul Gilliam @ 2005-12-08 4:42 ` Kevin Buettner 1 sibling, 0 replies; 39+ messages in thread From: Kevin Buettner @ 2005-12-08 4:42 UTC (permalink / raw) To: gdb-patches On Mon, 5 Dec 2005 11:00:51 -0800 Paul Gilliam <pgilliam@us.ibm.com> wrote: > I made the changes to address Mark's concerns. You missed adding spaces around at least one of the operators. The one that I noticed was the `-' in: + for (scan pc = pc-PPC INSN SIZE; Also, regarding the following bit: + int opcode = (insn>>26) & 0x03f; + int sd = (insn>>21) & 0x01f; + int a = (insn>>16) & 0x01f; + /* b = (insn>>11) & 0x01f */ + int subcode = (insn>> 1) & 0x3ff; + /* rc = insn & 0x001 */ I like the use of indentation to line things up, but our coding standard is to remove extraneous spaces. (Because that's what GNU indent would do. Yeah, I agree it's lame...) Ah, I just noticed that you missed the spaces around the >> operators too. > But because of the interest this has drawn, I thought I better ask > again before I commited the patch. Thanks for asking again. It was indeed useful to reread the other comments. Could I ask you to make the following modifications to your patch? 1) Abort a forward scan (and return 0) if any control transfer instruction other than blr is found. 2) Abort a backward scan (and return 0) if any control transfer instruction is found. 3) Place a hard limit on the number of instructions scanned both forwards and backwards. Epilogues are typically not very big and scanning to the ends of a large function starting at the middle seems rather wasteful. Kevin ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 21:44 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner 2005-12-06 15:20 ` Paul Gilliam @ 2006-01-11 17:44 ` Paul Gilliam 2006-01-12 0:12 ` Paul Gilliam 1 sibling, 1 reply; 39+ messages in thread From: Paul Gilliam @ 2006-01-11 17:44 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Mark Kettenis Kevin and Mark, I kind of lost track of this. Here is a link to the revised patch. It should address Mark's concerns, but I thought, sense it's been a while, I should run it by you again. http://sourceware.org/ml/gdb-patches/2005-12/msg00072.html OK to commit? -=# Paul #=- On Friday 02 December 2005 12:32, Kevin Buettner wrote: > On Fri, 2 Dec 2005 11:20:22 -0800 > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > Your patch is okay to commit after you address Mark's concerns. > > Kevin > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-11 17:44 ` Paul Gilliam @ 2006-01-12 0:12 ` Paul Gilliam 2006-01-12 23:53 ` Paul Gilliam 0 siblings, 1 reply; 39+ messages in thread From: Paul Gilliam @ 2006-01-12 0:12 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Mark Kettenis I see that I had not incorporated Kevin's last set of comments. Let me do that and post again.... -=# Paul #=- On Wednesday 11 January 2006 10:13, Paul Gilliam wrote: > Kevin and Mark, > > I kind of lost track of this. Here is a link to the revised patch. It should address Mark's concerns, > but I thought, sense it's been a while, I should run it by you again. > > http://sourceware.org/ml/gdb-patches/2005-12/msg00072.html > > OK to commit? > > -=# Paul #=- > > On Friday 02 December 2005 12:32, Kevin Buettner wrote: > > On Fri, 2 Dec 2005 11:20:22 -0800 > > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > > and put it into the architecture vector. > > > > Your patch is okay to commit after you address Mark's concerns. > > > > Kevin > > > > > > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-12 0:12 ` Paul Gilliam @ 2006-01-12 23:53 ` Paul Gilliam 2006-01-13 21:05 ` Mark Kettenis 0 siblings, 1 reply; 39+ messages in thread From: Paul Gilliam @ 2006-01-12 23:53 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Mark Kettenis [-- Attachment #1: Type: text/plain, Size: 985 bytes --] [I am reposting this because it did not show up in the mail-list archive] On Wednesday 11 January 2006 10:13, Paul Gilliam wrote: > Kevin and Mark, > > I kind of lost track of this. Here is a link to the revised patch. It should address Mark's concerns, > but I thought, sense it's been a while, I should run it by you again. > > http://sourceware.org/ml/gdb-patches/2005-12/msg00072.html > > OK to commit? > > -=# Paul #=- > > On Friday 02 December 2005 12:32, Kevin Buettner wrote: > > On Fri, 2 Dec 2005 11:20:22 -0800 > > Paul Gilliam <pgilliam@us.ibm.com> wrote: > > > > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > > and put it into the architecture vector. > > > > Your patch is okay to commit after you address Mark's concerns. > > > > Kevin > > > > > > > I found I had a more up-to-date version of the patch that should address both Mark's concerns and Kevin's OK to commit? [-- Attachment #2: watch-locals.patch --] [-- Type: text/x-diff, Size: 5107 bytes --] 2006-01-11 Paul Gilliam <pgilliam@us.ibm.com> * ppc-tdep.h: Add a define for the hard limit used when scanning an epilogue. * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' and put it into the architecture vector. Index: ppc-tdep.h =================================================================== RCS file: /cvs/src/src/gdb/ppc-tdep.h,v retrieving revision 1.48 diff -a -u -r1.48 ppc-tdep.h --- ppc-tdep.h 28 Oct 2005 18:23:32 -0000 1.48 +++ ppc-tdep.h 11 Jan 2006 23:03:43 -0000 @@ -384,4 +384,7 @@ /* Instruction size. */ #define PPC_INSN_SIZE 4 +/* Estimate for the maximum number of instrctions in a function epilogue. */ +#define PPC_MAX_EPILOGUE_INSTRUCTIONS 52 + #endif /* ppc-tdep.h */ Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 11 Jan 2006 23:03:43 -0000 @@ -502,6 +502,114 @@ return pc; } +static int +insn_changes_sp_or_jumps (unsigned long insn) +{ + int opcode = (insn >> 26) & 0x03f; + int sd = (insn >> 21) & 0x01f; + int a = (insn >> 16) & 0x01f; + /* b = (insn >> 11) & 0x01f */ + int subcode = (insn >> 1) & 0x3ff; + /* rc = insn & 0x001 */ + + /* Changes the stack pointer. */ + + /* NOTE: There are many ways to change the value of a given register. + The ways below are those used when the register is R1, the SP, + in a funtion's epilogue. */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + /* Transfers control. */ + + if (opcode == 18) + return 1; /* b */ + if (opcode == 16) + return 1; /* bc */ + if (opcode == 19 && subcode == 16) + return 1; /* bclr */ + if (opcode == 19 && subcode == 528) + return 1; /* bcctr */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. + + 1) scan forward from the point of execution: + a) If you find an instruction that modifies the stack pointer + or transfers control (except a return), execution is not in + an epilogue, return. + b) Stop scanning if you find a return instruction or reach the + end of the function or reach the hard limit for the size of + an epilogue. + 2) scan backward from the point of execution: + a) If you find an instruction that modifies the stack pointer, + execution *is* in an epilogue, return. + b) Stop scanning if you reach an instruction that transfers + control or the beginning of the function or reach the hard + limit for the size of an epilogue. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_start, func_end, epilogue_start, epilogue_end; + unsigned long insn; + struct frame_info *fr; + + /* Find the search limits based on function boundaries and hard limit. */ + + if (!find_pc_partial_function (pc, NULL, &func_start, &func_end)) + return 0; + + epilogue_start = pc - PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; + if (epilogue_start < func_start) epilogue_start = func_start; + + epilogue_end = pc + PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; + if (epilogue_end > func_end) epilogue_end = func_end; + + /* Get the current frame. This may be cheap, since we might have + just called it in watchpoint_check, before calling + gdbarch_in_function_epilogue_p. */ + + fr = get_current_frame (); + + /* Scan forward until next 'blr'. */ + + for (scan_pc = pc; scan_pc < epilogue_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp_or_jumps (insn)) + return 0; + } + + /* Scan backward until adjustment to stack pointer (R1). */ + + for (scan_pc = pc - PPC_INSN_SIZE; + scan_pc >= epilogue_start; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp_or_jumps (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3450,8 @@ set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-12 23:53 ` Paul Gilliam @ 2006-01-13 21:05 ` Mark Kettenis 2006-01-17 3:46 ` Paul Gilliam 0 siblings, 1 reply; 39+ messages in thread From: Mark Kettenis @ 2006-01-13 21:05 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches, kevinb > From: Paul Gilliam <pgilliam@us.ibm.com> > Date: Thu, 12 Jan 2006 16:23:15 -0800 [ Bleah, I'd really wish people stopped sending MIME mail, especially with that stupid quoted-printable encoding. I hate editing out all those gratuitous equal signs. ] > > I kind of lost track of this. Here is a link to the revised > > patch. It should address Mark's concerns, Unfortunately it doesn't. > 2006-01-11 Paul Gilliam <pgilliam@us.ibm.com> > > * ppc-tdep.h: Add a define for the hard limit used when scanning an > epilogue. > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > and put it into the architecture vector. It's probably your stupid mailer that converts tabs into spaces or something, but please make sure the indentation of your Changelog entry is ok. Actually the whole entry is wrong. Please *do* read the GNU coding standards. Your changelog should probably read like this: 2006-01-11 Paul Gilliam <pgilliam@us.ibm.com> * ppc-tdep.h (PPC_MAX_EPILOGUE_INSTRUCTIONS): New define. * rs6000-tdep.c (insn_changes_sp_or_jumps) (rs6000_in_function_epilogue_p): New functions. (rs6000_gdbarch_init): Set in_function_epilogue_p. Also see a few comments in the code below. > Index: rs6000-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v > retrieving revision 1.248 > diff -a -u -r1.248 rs6000-tdep.c > --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 > +++ rs6000-tdep.c 11 Jan 2006 23:03:43 -0000 > @@ -502,6 +502,114 @@ > return pc; > } > > +static int > +insn_changes_sp_or_jumps (unsigned long insn) > +{ > + int opcode = (insn >> 26) & 0x03f; > + int sd = (insn >> 21) & 0x01f; > + int a = (insn >> 16) & 0x01f; > + /* b = (insn >> 11) & 0x01f */ > + int subcode = (insn >> 1) & 0x3ff; > + /* rc = insn & 0x001 */ Please remove these comments. > +/* Return true if we are in the function's epilogue, i.e. after the > + instruction that destroyed the function's stack frame. > + > + 1) scan forward from the point of execution: > + a) If you find an instruction that modifies the stack pointer > + or transfers control (except a return), execution is not in > + an epilogue, return. > + b) Stop scanning if you find a return instruction or reach the > + end of the function or reach the hard limit for the size of > + an epilogue. > + 2) scan backward from the point of execution: > + a) If you find an instruction that modifies the stack pointer, > + execution *is* in an epilogue, return. > + b) Stop scanning if you reach an instruction that transfers > + control or the beginning of the function or reach the hard > + limit for the size of an epilogue. */ > + > +static int > +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) > +{ > + bfd_byte insn_buf[PPC_INSN_SIZE]; > + CORE_ADDR scan_pc, func_start, func_end, epilogue_start, epilogue_end; > + unsigned long insn; > + struct frame_info *fr; Could you name this variable frame instead of the cryptic fr? > + /* Find the search limits based on function boundaries and hard limit. */ > + > + if (!find_pc_partial_function (pc, NULL, &func_start, &func_end)) > + return 0; > + > + epilogue_start = pc - PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; > + if (epilogue_start < func_start) epilogue_start = func_start; > + > + epilogue_end = pc + PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; > + if (epilogue_end > func_end) epilogue_end = func_end; > + > + /* Get the current frame. This may be cheap, since we might have > + just called it in watchpoint_check, before calling > + gdbarch_in_function_epilogue_p. */ I don't think this comment is actually adding any useful information, so I'd prefer it if you dropped it. > + fr = get_current_frame (); > + > + /* Scan forward until next 'blr'. */ > + > + for (scan_pc = pc; scan_pc < epilogue_end; scan_pc += PPC_INSN_SIZE) > + { > + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) > + return 0; > + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); > + if (insn == 0x4e800020) > + break; > + if (insn_changes_sp_or_jumps (insn)) > + return 0; > + } > + > + /* Scan backward until adjustment to stack pointer (R1). */ > + > + for (scan_pc = pc - PPC_INSN_SIZE; > + scan_pc >= epilogue_start; > + scan_pc -= PPC_INSN_SIZE) > + { > + if (!safe_frame_unwind_memory (fr, scan_pc, insn_buf, PPC_INSN_SIZE)) > + return 0; > + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); > + if (insn_changes_sp_or_jumps (insn)) > + return 1; > + } > + > + return 0; > +} > + > > /* Fill in fi->saved_regs */ With those changes, this is ok. Mark ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-13 21:05 ` Mark Kettenis @ 2006-01-17 3:46 ` Paul Gilliam 2006-01-17 19:29 ` Mark Kettenis 2006-02-09 17:46 ` Kevin Buettner 0 siblings, 2 replies; 39+ messages in thread From: Paul Gilliam @ 2006-01-17 3:46 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb-patches, kevinb [-- Attachment #1: Type: text/plain, Size: 1726 bytes --] Mark, I have made the modifications you asked for. I would have committed the patch, but I wanted to give you a chance to see if my new variable name was ok: fr became curfrm. It's still a little criptic, but I was trying to avoid making the condition of an 'if' statement be on two lines. OK to commit? I am also concerned about this: > [ Bleah, I'd really wish people stopped sending MIME mail, especially > with that stupid quoted-printable encoding. I hate editing out all > those gratuitous equal signs. ] > > > 2006-01-11 Paul Gilliam <pgilliam@us.ibm.com> > > > > * ppc-tdep.h: Add a define for the hard limit used when scanning an > > epilogue. > > * rs6000-tdep.c: Add new subroutine, 'rs6000_in_function_epilogue_p()' > > and put it into the architecture vector. > > It's probably your stupid mailer that converts tabs into spaces or > something, but please make sure the indentation of your Changelog > entry is ok. > The mailer I am using is 'kmail'. Here is what I get if I say 'kmail -v': Qt: 3.3.1 KDE: 3.2.1 KMail: 1.6.2 I viewed the source of my previous message and I have to agree: Bleah!! What mailer whould you suggest? What mailer do you use? In the Settings, I see I have a choice between "Allow 8-bit" or "MIME Compliant (Quoted Printable)". For this message I used "Allow 8-bit". I hope this does a better job. If not, I'll have to change mailers. I thought MIME was the standard though. Is that not the case? Also, the attachment on my previous message claims to be "text/x-diff". I changed this one to "text/plain". Did that make any difference for you? I really appreciate your help in getting all this stuff 'right'. -=# Paul #=- [-- Attachment #2: watch-locals.patch --] [-- Type: text/plain, Size: 4912 bytes --] 2006-01-16 Paul Gilliam <pgilliam@us.ibm.com> * ppc-tdep.h (PPC_MAX_EPILOGUE_INSTRUCTIONS): New define. * rs6000-tdep.c (insn_changes_sp_or_jumps) (rs6000_in_function_epilogue_p): New functions. (rs6000_gdbarch_init): Set in_function_epilogue_p. Index: ppc-tdep.h =================================================================== RCS file: /cvs/src/src/gdb/ppc-tdep.h,v retrieving revision 1.48 diff -a -u -r1.48 ppc-tdep.h --- ppc-tdep.h 28 Oct 2005 18:23:32 -0000 1.48 +++ ppc-tdep.h 17 Jan 2006 02:14:16 -0000 @@ -384,4 +384,7 @@ /* Instruction size. */ #define PPC_INSN_SIZE 4 +/* Estimate for the maximum number of instrctions in a function epilogue. */ +#define PPC_MAX_EPILOGUE_INSTRUCTIONS 52 + #endif /* ppc-tdep.h */ Index: rs6000-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v retrieving revision 1.248 diff -a -u -r1.248 rs6000-tdep.c --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 +++ rs6000-tdep.c 17 Jan 2006 02:14:21 -0000 @@ -502,6 +502,108 @@ return pc; } +static int +insn_changes_sp_or_jumps (unsigned long insn) +{ + int opcode = (insn >> 26) & 0x03f; + int sd = (insn >> 21) & 0x01f; + int a = (insn >> 16) & 0x01f; + int subcode = (insn >> 1) & 0x3ff; + + /* Changes the stack pointer. */ + + /* NOTE: There are many ways to change the value of a given register. + The ways below are those used when the register is R1, the SP, + in a funtion's epilogue. */ + + if (opcode == 31 && subcode == 444 && a == 1) + return 1; /* mr R1,Rn */ + if (opcode == 14 && sd == 1) + return 1; /* addi R1,Rn,simm */ + if (opcode == 58 && sd == 1) + return 1; /* ld R1,ds(Rn) */ + + /* Transfers control. */ + + if (opcode == 18) + return 1; /* b */ + if (opcode == 16) + return 1; /* bc */ + if (opcode == 19 && subcode == 16) + return 1; /* bclr */ + if (opcode == 19 && subcode == 528) + return 1; /* bcctr */ + + return 0; +} + +/* Return true if we are in the function's epilogue, i.e. after the + instruction that destroyed the function's stack frame. + + 1) scan forward from the point of execution: + a) If you find an instruction that modifies the stack pointer + or transfers control (except a return), execution is not in + an epilogue, return. + b) Stop scanning if you find a return instruction or reach the + end of the function or reach the hard limit for the size of + an epilogue. + 2) scan backward from the point of execution: + a) If you find an instruction that modifies the stack pointer, + execution *is* in an epilogue, return. + b) Stop scanning if you reach an instruction that transfers + control or the beginning of the function or reach the hard + limit for the size of an epilogue. */ + +static int +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) +{ + bfd_byte insn_buf[PPC_INSN_SIZE]; + CORE_ADDR scan_pc, func_start, func_end, epilogue_start, epilogue_end; + unsigned long insn; + struct frame_info *curfrm; + + /* Find the search limits based on function boundaries and hard limit. */ + + if (!find_pc_partial_function (pc, NULL, &func_start, &func_end)) + return 0; + + epilogue_start = pc - PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; + if (epilogue_start < func_start) epilogue_start = func_start; + + epilogue_end = pc + PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; + if (epilogue_end > func_end) epilogue_end = func_end; + + curfrm = get_current_frame (); + + /* Scan forward until next 'blr'. */ + + for (scan_pc = pc; scan_pc < epilogue_end; scan_pc += PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (curfrm, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn == 0x4e800020) + break; + if (insn_changes_sp_or_jumps (insn)) + return 0; + } + + /* Scan backward until adjustment to stack pointer (R1). */ + + for (scan_pc = pc - PPC_INSN_SIZE; + scan_pc >= epilogue_start; + scan_pc -= PPC_INSN_SIZE) + { + if (!safe_frame_unwind_memory (curfrm, scan_pc, insn_buf, PPC_INSN_SIZE)) + return 0; + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); + if (insn_changes_sp_or_jumps (insn)) + return 1; + } + + return 0; +} + /* Fill in fi->saved_regs */ @@ -3342,6 +3444,8 @@ set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); + set_gdbarch_inner_than (gdbarch, core_addr_lessthan); set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-17 3:46 ` Paul Gilliam @ 2006-01-17 19:29 ` Mark Kettenis 2006-02-09 17:46 ` Kevin Buettner 1 sibling, 0 replies; 39+ messages in thread From: Mark Kettenis @ 2006-01-17 19:29 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches, kevinb > From: Paul Gilliam <pgilliam@us.ibm.com> > Date: Mon, 16 Jan 2006 19:15:54 -0800 > > --Boundary-00=_qFGzDDhs5oqznk3 > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Mark, > > I have made the modifications you asked for. > > I would have committed the patch, but I wanted to give you a chance > to see if my new variable name was ok: fr became curfrm. > > It's still a little criptic, but I was trying to avoid making the > condition of an 'if' statement be on two lines. Ah, that's a good reason not too make variables and function names overly long. Personally I'd just named the varible "frame" (that actually would make the function future safe, since it really should work for any frame, and take a frame argument instead of a pc, but that's not your fault.) > OK to commit? I'll leave it up to you to change curfrm into frame as suggested above. So, yes. Thanks! > I am also concerned about this: > > > [ Bleah, I'd really wish people stopped sending MIME mail, especially > > with that stupid quoted-printable encoding. I hate editing out all > > those gratuitous equal signs. ] > > > > The mailer I am using is 'kmail'. Here is what I get if I say 'kmail -v': > Qt: 3.3.1 > KDE: 3.2.1 > KMail: 1.6.2 IMHO KMail is trying to emulate too many bad things from Windows mailers. > I viewed the source of my previous message and I have to agree: Bleah!! > > What mailer whould you suggest? What mailer do you use? Ah, well, I use emacs; it's really convenient to be able to read your mail and edit source code from within the same application. But please use whatever you're comfortable with. > In the Settings, I see I have a choice between "Allow 8-bit" or > "MIME Compliant (Quoted Printable)". For this message I used "Allow > 8-bit". I hope this does a better job. If not, I'll have to change > mailers. Yes it is. And it seems most MTA's are 8-bit clean these days. It's a bit sad you don't get offered the possibility to use 7-bit ASCII :( > I thought MIME was the standard though. Is that not the case? Sort of. But I think it should only used for binary attachments; not simple text messages. > Also, the attachment on my previous message claims to be > "text/x-diff". I changed this one to "text/plain". Did that make > any difference for you? Yup; it's much more readable that way. > I really appreciate your help in getting all this stuff 'right'. Thnaks for putting up with me ;-). I'm sure you get it more "right" from the start next time. Mark ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2006-01-17 3:46 ` Paul Gilliam 2006-01-17 19:29 ` Mark Kettenis @ 2006-02-09 17:46 ` Kevin Buettner 1 sibling, 0 replies; 39+ messages in thread From: Kevin Buettner @ 2006-02-09 17:46 UTC (permalink / raw) To: gdb-patches Paul, I apologize for taking so long to get back to this. You're patch is okay to check in so long as a few changes to the formatting are made. See below. There's no need to ask for further approval on your updated patch, but do post the patch that you end up committing. Thanks, Kevin On Mon, 16 Jan 2006 19:15:54 -0800 Paul Gilliam <pgilliam@us.ibm.com> wrote: > 2006-01-16 Paul Gilliam <pgilliam@us.ibm.com> > > * ppc-tdep.h (PPC_MAX_EPILOGUE_INSTRUCTIONS): New define. > * rs6000-tdep.c (insn_changes_sp_or_jumps) > (rs6000_in_function_epilogue_p): New functions. > (rs6000_gdbarch_init): Set in_function_epilogue_p. > > Index: ppc-tdep.h > =================================================================== > RCS file: /cvs/src/src/gdb/ppc-tdep.h,v > retrieving revision 1.48 > diff -a -u -r1.48 ppc-tdep.h > --- ppc-tdep.h 28 Oct 2005 18:23:32 -0000 1.48 > +++ ppc-tdep.h 17 Jan 2006 02:14:16 -0000 > @@ -384,4 +384,7 @@ > /* Instruction size. */ > #define PPC_INSN_SIZE 4 > > +/* Estimate for the maximum number of instrctions in a function epilogue. */ > +#define PPC_MAX_EPILOGUE_INSTRUCTIONS 52 > + > #endif /* ppc-tdep.h */ > Index: rs6000-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v > retrieving revision 1.248 > diff -a -u -r1.248 rs6000-tdep.c > --- rs6000-tdep.c 1 Nov 2005 19:32:36 -0000 1.248 > +++ rs6000-tdep.c 17 Jan 2006 02:14:21 -0000 > @@ -502,6 +502,108 @@ > return pc; > } > > +static int > +insn_changes_sp_or_jumps (unsigned long insn) > +{ > + int opcode = (insn >> 26) & 0x03f; > + int sd = (insn >> 21) & 0x01f; > + int a = (insn >> 16) & 0x01f; > + int subcode = (insn >> 1) & 0x3ff; > + > + /* Changes the stack pointer. */ > + > + /* NOTE: There are many ways to change the value of a given register. > + The ways below are those used when the register is R1, the SP, > + in a funtion's epilogue. */ > + > + if (opcode == 31 && subcode == 444 && a == 1) > + return 1; /* mr R1,Rn */ > + if (opcode == 14 && sd == 1) > + return 1; /* addi R1,Rn,simm */ > + if (opcode == 58 && sd == 1) > + return 1; /* ld R1,ds(Rn) */ > + > + /* Transfers control. */ > + > + if (opcode == 18) > + return 1; /* b */ > + if (opcode == 16) > + return 1; /* bc */ > + if (opcode == 19 && subcode == 16) > + return 1; /* bclr */ > + if (opcode == 19 && subcode == 528) > + return 1; /* bcctr */ > + > + return 0; > +} > + > +/* Return true if we are in the function's epilogue, i.e. after the > + instruction that destroyed the function's stack frame. > + > + 1) scan forward from the point of execution: > + a) If you find an instruction that modifies the stack pointer > + or transfers control (except a return), execution is not in > + an epilogue, return. > + b) Stop scanning if you find a return instruction or reach the > + end of the function or reach the hard limit for the size of > + an epilogue. > + 2) scan backward from the point of execution: > + a) If you find an instruction that modifies the stack pointer, > + execution *is* in an epilogue, return. > + b) Stop scanning if you reach an instruction that transfers > + control or the beginning of the function or reach the hard > + limit for the size of an epilogue. */ > + > +static int > +rs6000_in_function_epilogue_p (struct gdbarch *gdbarch, CORE_ADDR pc) > +{ > + bfd_byte insn_buf[PPC_INSN_SIZE]; > + CORE_ADDR scan_pc, func_start, func_end, epilogue_start, epilogue_end; > + unsigned long insn; > + struct frame_info *curfrm; I see that Mark suggested using the name `frame' instead of `curfrm'. This is okay with me. As Mark indicates, naming it `frame' will make it easy to revise this function in the future in the event that a frame is passed in instead of a pc value. > + > + /* Find the search limits based on function boundaries and hard limit. */ > + > + if (!find_pc_partial_function (pc, NULL, &func_start, &func_end)) > + return 0; > + > + epilogue_start = pc - PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; > + if (epilogue_start < func_start) epilogue_start = func_start; Please put `epilogue_start = func_start;' on its own line indented two spaces from the column of the `if'. > + > + epilogue_end = pc + PPC_MAX_EPILOGUE_INSTRUCTIONS * PPC_INSN_SIZE; > + if (epilogue_end > func_end) epilogue_end = func_end; Likewise here. > + > + curfrm = get_current_frame (); > + > + /* Scan forward until next 'blr'. */ > + > + for (scan_pc = pc; scan_pc < epilogue_end; scan_pc += PPC_INSN_SIZE) > + { > + if (!safe_frame_unwind_memory (curfrm, scan_pc, insn_buf, PPC_INSN_SIZE)) > + return 0; > + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); > + if (insn == 0x4e800020) > + break; > + if (insn_changes_sp_or_jumps (insn)) > + return 0; > + } > + > + /* Scan backward until adjustment to stack pointer (R1). */ > + > + for (scan_pc = pc - PPC_INSN_SIZE; > + scan_pc >= epilogue_start; > + scan_pc -= PPC_INSN_SIZE) > + { > + if (!safe_frame_unwind_memory (curfrm, scan_pc, insn_buf, PPC_INSN_SIZE)) > + return 0; > + insn = extract_signed_integer (insn_buf, PPC_INSN_SIZE); > + if (insn_changes_sp_or_jumps (insn)) > + return 1; > + } > + > + return 0; > +} > + > > /* Fill in fi->saved_regs */ > > @@ -3342,6 +3444,8 @@ > set_gdbarch_deprecated_extract_struct_value_address (gdbarch, rs6000_extract_struct_value_address); > > set_gdbarch_skip_prologue (gdbarch, rs6000_skip_prologue); > + set_gdbarch_in_function_epilogue_p (gdbarch, rs6000_in_function_epilogue_p); > + > set_gdbarch_inner_than (gdbarch, core_addr_lessthan); > set_gdbarch_breakpoint_from_pc (gdbarch, rs6000_breakpoint_from_pc); ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam 2005-12-02 20:28 ` Mark Kettenis 2005-12-02 21:44 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner @ 2005-12-02 22:19 ` Jim Blandy 2005-12-02 22:28 ` Daniel Jacobowitz 2005-12-03 12:48 ` Paul Gilliam 2 siblings, 2 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-02 22:19 UTC (permalink / raw) To: pgilliam; +Cc: gdb-patches > > Whatever we do immediately, the underlying cause here is that > > unwinding isn't working at every instruction. If it were, then the > > call to frame_find_by_id would find the frame containing the watched > > variable, and watchpoint_check would correctly conclude that the > > variable was still in scope. > > > > Paul, does your test program have Dwarf CFI for the functions in question? > > > I have attached a couple of dumps (and a typescript show how they where made), the executable, and the source. Okay, thanks. I don't have a ppc64 toolchain handy; could you post the output from objdump -d testwatch? The readelf dump that I wanted was 'readelf -wF' or '-wf'; but since you provided the executable, that's fine. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 22:19 ` Jim Blandy @ 2005-12-02 22:28 ` Daniel Jacobowitz 2005-12-02 23:20 ` Jim Blandy 2005-12-03 12:48 ` Paul Gilliam 1 sibling, 1 reply; 39+ messages in thread From: Daniel Jacobowitz @ 2005-12-02 22:28 UTC (permalink / raw) To: Jim Blandy; +Cc: pgilliam, gdb-patches On Fri, Dec 02, 2005 at 01:19:28PM -0800, Jim Blandy wrote: > > > Whatever we do immediately, the underlying cause here is that > > > unwinding isn't working at every instruction. If it were, then the > > > call to frame_find_by_id would find the frame containing the watched > > > variable, and watchpoint_check would correctly conclude that the > > > variable was still in scope. > > > > > > Paul, does your test program have Dwarf CFI for the functions in question? > > > > > I have attached a couple of dumps (and a typescript show how they where made), the executable, and the source. > > Okay, thanks. I don't have a ppc64 toolchain handy; could you post > the output from objdump -d testwatch? The readelf dump that I wanted > was 'readelf -wF' or '-wf'; but since you provided the executable, > that's fine. We don't even use CFI for PowerPC, still, because of the debacle with incorrect register numbers recently fixed in GCC. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 22:28 ` Daniel Jacobowitz @ 2005-12-02 23:20 ` Jim Blandy 0 siblings, 0 replies; 39+ messages in thread From: Jim Blandy @ 2005-12-02 23:20 UTC (permalink / raw) To: Jim Blandy, pgilliam, gdb-patches On 12/2/05, Daniel Jacobowitz <drow@false.org> wrote: > We don't even use CFI for PowerPC, still, because of the debacle with > incorrect register numbers recently fixed in GCC. Oh! That scotches that idea, then. Never mind, Paul. The "Right Fix" for that bug would be to make the unwinding more reliable. But pre-CFI we've never really been able to unwind very well within epilogues. Daniel had aesthetic concerns about the patch, but it seems like the in_function_epilogue method is the only practical fix, whatever qualities its actual definition might have. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) 2005-12-02 22:19 ` Jim Blandy 2005-12-02 22:28 ` Daniel Jacobowitz @ 2005-12-03 12:48 ` Paul Gilliam 1 sibling, 0 replies; 39+ messages in thread From: Paul Gilliam @ 2005-12-03 12:48 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 942 bytes --] On Friday 02 December 2005 13:19, Jim Blandy wrote: > > > Whatever we do immediately, the underlying cause here is that > > > unwinding isn't working at every instruction. If it were, then the > > > call to frame_find_by_id would find the frame containing the watched > > > variable, and watchpoint_check would correctly conclude that the > > > variable was still in scope. > > > > > > Paul, does your test program have Dwarf CFI for the functions in question? > > > > > I have attached a couple of dumps (and a typescript show how they where made), the executable, and the source. > > Okay, thanks. I don't have a ppc64 toolchain handy; could you post > the output from objdump -d testwatch? The readelf dump that I wanted > was 'readelf -wF' or '-wf'; but since you provided the executable, > that's fine. > > OK. I have attached the output from "objdump -d testwatch" Please ignore this if it's no longer relevent. -=# Paul #=- [-- Attachment #2: testwatch.objdump-d --] [-- Type: text/plain, Size: 13417 bytes --] testwatch: file format elf64-powerpc Disassembly of section .init: 0000000010000318 <._init>: 10000318: 7c 08 02 a6 mflr r0 1000031c: f8 01 00 10 std r0,16(r1) 10000320: f8 21 ff 91 stdu r1,-112(r1) 10000324: 48 00 00 99 bl 100003bc <.call_gmon_start> 10000328: 48 00 01 6d bl 10000494 <.frame_dummy> 1000032c: 60 00 00 00 nop 10000330: 48 00 03 d9 bl 10000708 <.__do_global_ctors_aux> 10000334: 60 00 00 00 nop 10000338: 38 21 00 70 addi r1,r1,112 1000033c: e8 01 00 10 ld r0,16(r1) 10000340: 7c 08 03 a6 mtlr r0 10000344: 4e 80 00 20 blr Disassembly of section .text: 0000000010000348 <._Jv_RegisterClasses>: 10000348: 3d 82 00 00 addis r12,r2,0 1000034c: f8 41 00 28 std r2,40(r1) 10000350: e9 6c 80 a8 ld r11,-32600(r12) 10000354: e8 4c 80 b0 ld r2,-32592(r12) 10000358: 7d 69 03 a6 mtctr r11 1000035c: e9 6c 80 b8 ld r11,-32584(r12) 10000360: 4e 80 04 20 bctr 0000000010000364 <.__libc_start_main>: 10000364: 3d 82 00 00 addis r12,r2,0 10000368: f8 41 00 28 std r2,40(r1) 1000036c: e9 6c 80 90 ld r11,-32624(r12) 10000370: e8 4c 80 98 ld r2,-32616(r12) 10000374: 7d 69 03 a6 mtctr r11 10000378: e9 6c 80 a0 ld r11,-32608(r12) 1000037c: 4e 80 04 20 bctr 0000000010000380 <._start>: 10000380: 7c 29 0b 78 mr r9,r1 10000384: 78 21 06 e4 rldicr r1,r1,0,59 10000388: 38 00 00 00 li r0,0 1000038c: f8 21 ff 81 stdu r1,-128(r1) 10000390: 7c 08 03 a6 mtlr r0 10000394: f8 01 00 00 std r0,0(r1) 10000398: e9 02 80 08 ld r8,-32760(r2) 1000039c: 4b ff ff c8 b 10000364 <.__libc_start_main> 100003a0: e8 41 00 28 ld r2,40(r1) 100003a4: 00 00 00 00 .long 0x0 100003a8: 00 0c 20 40 .long 0xc2040 100003ac: 00 00 00 00 .long 0x0 100003b0: 00 00 00 24 .long 0x24 100003b4: 00 06 5f 73 .long 0x65f73 100003b8: 74 61 72 74 andis. r1,r3,29300 00000000100003bc <.call_gmon_start>: 100003bc: 7c 08 02 a6 mflr r0 100003c0: f8 01 00 10 std r0,16(r1) 100003c4: f8 21 ff 91 stdu r1,-112(r1) 100003c8: e9 22 80 10 ld r9,-32752(r2) 100003cc: 2f a9 00 00 cmpdi cr7,r9,0 100003d0: 41 9e 00 20 beq- cr7,100003f0 <.call_gmon_start+0x34> 100003d4: e8 09 00 00 ld r0,0(r9) 100003d8: 7c 09 03 a6 mtctr r0 100003dc: f8 41 00 28 std r2,40(r1) 100003e0: e8 49 00 08 ld r2,8(r9) 100003e4: e9 69 00 10 ld r11,16(r9) 100003e8: 4e 80 04 21 bctrl 100003ec: e8 41 00 28 ld r2,40(r1) 100003f0: 38 21 00 70 addi r1,r1,112 100003f4: e8 01 00 10 ld r0,16(r1) 100003f8: 7c 08 03 a6 mtlr r0 100003fc: 4e 80 00 20 blr 0000000010000400 <.__do_global_dtors_aux>: 10000400: 7c 08 02 a6 mflr r0 10000404: e9 62 80 18 ld r11,-32744(r2) 10000408: fb e1 ff f8 std r31,-8(r1) 1000040c: f8 01 00 10 std r0,16(r1) 10000410: f8 21 ff 81 stdu r1,-128(r1) 10000414: 88 0b 00 00 lbz r0,0(r11) 10000418: 2f 80 00 00 cmpwi cr7,r0,0 1000041c: 40 9e 00 64 bne- cr7,10000480 <.__do_global_dtors_aux+0x80> 10000420: eb e2 80 20 ld r31,-32736(r2) 10000424: e9 3f 00 00 ld r9,0(r31) 10000428: e9 49 00 00 ld r10,0(r9) 1000042c: 2f aa 00 00 cmpdi cr7,r10,0 10000430: 40 be 00 0c bne+ cr7,1000043c <.__do_global_dtors_aux+0x3c> 10000434: 48 00 00 44 b 10000478 <.__do_global_dtors_aux+0x78> 10000438: eb e2 80 20 ld r31,-32736(r2) 1000043c: e9 3f 00 00 ld r9,0(r31) 10000440: 39 29 00 08 addi r9,r9,8 10000444: f9 3f 00 00 std r9,0(r31) 10000448: e8 0a 00 00 ld r0,0(r10) 1000044c: f8 41 00 28 std r2,40(r1) 10000450: e9 6a 00 10 ld r11,16(r10) 10000454: 7c 09 03 a6 mtctr r0 10000458: e8 4a 00 08 ld r2,8(r10) 1000045c: 4e 80 04 21 bctrl 10000460: e8 41 00 28 ld r2,40(r1) 10000464: e9 3f 00 00 ld r9,0(r31) 10000468: e9 49 00 00 ld r10,0(r9) 1000046c: 2f aa 00 00 cmpdi cr7,r10,0 10000470: 40 9e ff c8 bne+ cr7,10000438 <.__do_global_dtors_aux+0x38> 10000474: e9 62 80 18 ld r11,-32744(r2) 10000478: 38 00 00 01 li r0,1 1000047c: 98 0b 00 00 stb r0,0(r11) 10000480: 38 21 00 80 addi r1,r1,128 10000484: e8 01 00 10 ld r0,16(r1) 10000488: eb e1 ff f8 ld r31,-8(r1) 1000048c: 7c 08 03 a6 mtlr r0 10000490: 4e 80 00 20 blr 0000000010000494 <.frame_dummy>: 10000494: 7c 08 02 a6 mflr r0 10000498: e8 62 80 28 ld r3,-32728(r2) 1000049c: f8 01 00 10 std r0,16(r1) 100004a0: f8 21 ff 91 stdu r1,-112(r1) 100004a4: e8 03 00 00 ld r0,0(r3) 100004a8: 2f a0 00 00 cmpdi cr7,r0,0 100004ac: 41 9e 00 10 beq- cr7,100004bc <.frame_dummy+0x28> 100004b0: e8 02 80 30 ld r0,-32720(r2) 100004b4: 2f a0 00 00 cmpdi cr7,r0,0 100004b8: 40 9e 00 14 bne- cr7,100004cc <.frame_dummy+0x38> 100004bc: 38 21 00 70 addi r1,r1,112 100004c0: e8 01 00 10 ld r0,16(r1) 100004c4: 7c 08 03 a6 mtlr r0 100004c8: 4e 80 00 20 blr 100004cc: 4b ff fe 7d bl 10000348 <._Jv_RegisterClasses> 100004d0: e8 41 00 28 ld r2,40(r1) 100004d4: 38 21 00 70 addi r1,r1,112 100004d8: e8 01 00 10 ld r0,16(r1) 100004dc: 7c 08 03 a6 mtlr r0 100004e0: 4e 80 00 20 blr 00000000100004e4 <.subr2>: 100004e4: fb e1 ff f8 std r31,-8(r1) 100004e8: f8 21 ff c1 stdu r1,-64(r1) 100004ec: 7c 3f 0b 78 mr r31,r1 100004f0: f8 7f 00 70 std r3,112(r31) 100004f4: e9 3f 00 70 ld r9,112(r31) 100004f8: 38 00 00 09 li r0,9 100004fc: 90 09 00 00 stw r0,0(r9) 10000500: e9 3f 00 70 ld r9,112(r31) 10000504: 38 00 00 01 li r0,1 10000508: 90 09 00 00 stw r0,0(r9) 1000050c: e8 21 00 00 ld r1,0(r1) 10000510: eb e1 ff f8 ld r31,-8(r1) 10000514: 4e 80 00 20 blr ... 10000520: 80 01 00 01 lwz r0,1(r1) 0000000010000524 <.subr1>: 10000524: 7c 08 02 a6 mflr r0 10000528: fb e1 ff f8 std r31,-8(r1) 1000052c: f8 01 00 10 std r0,16(r1) 10000530: f8 21 ff 71 stdu r1,-144(r1) 10000534: 7c 3f 0b 78 mr r31,r1 10000538: 38 00 00 09 li r0,9 1000053c: 90 1f 00 70 stw r0,112(r31) 10000540: 38 7f 00 70 addi r3,r31,112 10000544: 4b ff ff a1 bl 100004e4 <.subr2> 10000548: e9 22 80 38 ld r9,-32712(r2) 1000054c: 38 00 00 02 li r0,2 10000550: 90 09 00 00 stw r0,0(r9) 10000554: e9 22 80 40 ld r9,-32704(r2) 10000558: c8 02 80 48 lfd f0,-32696(r2) 1000055c: d8 09 00 00 stfd f0,0(r9) 10000560: 38 00 00 02 li r0,2 10000564: 90 1f 00 70 stw r0,112(r31) 10000568: e8 21 00 00 ld r1,0(r1) 1000056c: e8 01 00 10 ld r0,16(r1) 10000570: 7c 08 03 a6 mtlr r0 10000574: eb e1 ff f8 ld r31,-8(r1) 10000578: 4e 80 00 20 blr 1000057c: 00 00 00 00 .long 0x0 10000580: 00 00 00 01 .long 0x1 10000584: 80 01 00 01 lwz r0,1(r1) 0000000010000588 <.main>: 10000588: 7c 08 02 a6 mflr r0 1000058c: fb e1 ff f8 std r31,-8(r1) 10000590: f8 01 00 10 std r0,16(r1) 10000594: f8 21 ff 71 stdu r1,-144(r1) 10000598: 7c 3f 0b 78 mr r31,r1 1000059c: 38 00 00 00 li r0,0 100005a0: 90 1f 00 70 stw r0,112(r31) 100005a4: 4b ff ff 81 bl 10000524 <.subr1> 100005a8: 7c 03 03 78 mr r3,r0 100005ac: e8 21 00 00 ld r1,0(r1) 100005b0: e8 01 00 10 ld r0,16(r1) 100005b4: 7c 08 03 a6 mtlr r0 100005b8: eb e1 ff f8 ld r31,-8(r1) 100005bc: 4e 80 00 20 blr 100005c0: 00 00 00 00 .long 0x0 100005c4: 00 00 00 01 .long 0x1 100005c8: 80 01 00 01 lwz r0,1(r1) 00000000100005cc <.__libc_csu_fini>: 100005cc: 7c 08 02 a6 mflr r0 100005d0: e9 62 80 58 ld r11,-32680(r2) 100005d4: fb e1 ff f8 std r31,-8(r1) 100005d8: f8 01 00 10 std r0,16(r1) 100005dc: e8 02 80 50 ld r0,-32688(r2) 100005e0: fb a1 ff e8 std r29,-24(r1) 100005e4: 7c 0b 00 50 subf r0,r11,r0 100005e8: f8 21 ff 71 stdu r1,-144(r1) 100005ec: 7c 1f 1e 74 sradi r31,r0,3 100005f0: 2f bf 00 00 cmpdi cr7,r31,0 100005f4: 3b ff ff ff addi r31,r31,-1 100005f8: 40 be 00 0c bne+ cr7,10000604 <.__libc_csu_fini+0x38> 100005fc: 48 00 00 3c b 10000638 <.__libc_csu_fini+0x6c> 10000600: e9 62 80 58 ld r11,-32680(r2) 10000604: 7b e9 1f 24 rldicr r9,r31,3,60 10000608: 7f fd fb 78 mr r29,r31 1000060c: 7d 49 58 2a ldx r10,r9,r11 10000610: 3b ff ff ff addi r31,r31,-1 10000614: e8 0a 00 00 ld r0,0(r10) 10000618: f8 41 00 28 std r2,40(r1) 1000061c: 7c 09 03 a6 mtctr r0 10000620: e9 6a 00 10 ld r11,16(r10) 10000624: e8 4a 00 08 ld r2,8(r10) 10000628: 4e 80 04 21 bctrl 1000062c: e8 41 00 28 ld r2,40(r1) 10000630: 2f bd 00 00 cmpdi cr7,r29,0 10000634: 40 9e ff cc bne+ cr7,10000600 <.__libc_csu_fini+0x34> 10000638: 48 00 01 91 bl 100007c8 <._fini> 1000063c: 60 00 00 00 nop 10000640: 38 21 00 90 addi r1,r1,144 10000644: e8 01 00 10 ld r0,16(r1) 10000648: eb a1 ff e8 ld r29,-24(r1) 1000064c: 7c 08 03 a6 mtlr r0 10000650: eb e1 ff f8 ld r31,-8(r1) 10000654: 4e 80 00 20 blr 10000658: 00 00 00 00 .long 0x0 1000065c: 00 00 00 01 .long 0x1 10000660: 80 03 00 00 lwz r0,0(r3) 0000000010000664 <.__libc_csu_init>: 10000664: 7c 08 02 a6 mflr r0 10000668: fb e1 ff f8 std r31,-8(r1) 1000066c: f8 01 00 10 std r0,16(r1) 10000670: f8 21 ff 81 stdu r1,-128(r1) 10000674: 4b ff fc a5 bl 10000318 <._init> 10000678: 60 00 00 00 nop 1000067c: 3b e0 00 00 li r31,0 10000680: e8 02 80 60 ld r0,-32672(r2) 10000684: e9 62 80 68 ld r11,-32664(r2) 10000688: 7c 0b 00 50 subf r0,r11,r0 1000068c: 78 09 e8 c3 rldicl. r9,r0,61,3 10000690: 40 82 00 18 bne- 100006a8 <.__libc_csu_init+0x44> 10000694: 38 21 00 80 addi r1,r1,128 10000698: e8 01 00 10 ld r0,16(r1) 1000069c: eb e1 ff f8 ld r31,-8(r1) 100006a0: 7c 08 03 a6 mtlr r0 100006a4: 4e 80 00 20 blr 100006a8: 7b e9 1f 24 rldicr r9,r31,3,60 100006ac: 3b ff 00 01 addi r31,r31,1 100006b0: 7d 49 58 2a ldx r10,r9,r11 100006b4: e8 0a 00 00 ld r0,0(r10) 100006b8: f8 41 00 28 std r2,40(r1) 100006bc: 7c 09 03 a6 mtctr r0 100006c0: e9 6a 00 10 ld r11,16(r10) 100006c4: e8 4a 00 08 ld r2,8(r10) 100006c8: 4e 80 04 21 bctrl 100006cc: e8 41 00 28 ld r2,40(r1) 100006d0: e8 02 80 60 ld r0,-32672(r2) 100006d4: e9 62 80 68 ld r11,-32664(r2) 100006d8: 7c 0b 00 50 subf r0,r11,r0 100006dc: 7c 00 1e 74 sradi r0,r0,3 100006e0: 7f bf 00 40 cmpld cr7,r31,r0 100006e4: 41 9c ff c4 blt+ cr7,100006a8 <.__libc_csu_init+0x44> 100006e8: 38 21 00 80 addi r1,r1,128 100006ec: e8 01 00 10 ld r0,16(r1) 100006f0: eb e1 ff f8 ld r31,-8(r1) 100006f4: 7c 08 03 a6 mtlr r0 100006f8: 4e 80 00 20 blr 100006fc: 00 00 00 00 .long 0x0 10000700: 00 00 00 01 .long 0x1 10000704: 80 01 00 00 lwz r0,0(r1) 0000000010000708 <.__do_global_ctors_aux>: 10000708: 7c 08 02 a6 mflr r0 1000070c: e9 22 80 70 ld r9,-32656(r2) 10000710: fb e1 ff f8 std r31,-8(r1) 10000714: f8 01 00 10 std r0,16(r1) 10000718: 3b e9 ff f8 addi r31,r9,-8 1000071c: f8 21 ff 81 stdu r1,-128(r1) 10000720: e8 09 ff f8 ld r0,-8(r9) 10000724: 2f a0 ff ff cmpdi cr7,r0,-1 10000728: 41 9e 00 34 beq- cr7,1000075c <.__do_global_ctors_aux+0x54> 1000072c: 7c 09 03 78 mr r9,r0 10000730: e8 09 00 00 ld r0,0(r9) 10000734: f8 41 00 28 std r2,40(r1) 10000738: 7c 09 03 a6 mtctr r0 1000073c: e9 69 00 10 ld r11,16(r9) 10000740: e8 49 00 08 ld r2,8(r9) 10000744: 4e 80 04 21 bctrl 10000748: e8 41 00 28 ld r2,40(r1) 1000074c: e8 1f ff f9 ldu r0,-8(r31) 10000750: 2f a0 ff ff cmpdi cr7,r0,-1 10000754: 7c 09 03 78 mr r9,r0 10000758: 40 9e ff d8 bne+ cr7,10000730 <.__do_global_ctors_aux+0x28> 1000075c: 38 21 00 80 addi r1,r1,128 10000760: e8 01 00 10 ld r0,16(r1) 10000764: eb e1 ff f8 ld r31,-8(r1) 10000768: 7c 08 03 a6 mtlr r0 1000076c: 4e 80 00 20 blr 10000770: 4e 80 00 20 blr 10000774: 7d 89 02 a6 mfctr r12 10000778: 78 0b 1f 24 rldicr r11,r0,3,60 1000077c: 34 40 80 00 addic. r2,r0,-32768 10000780: 7d 8b 60 50 subf r12,r11,r12 10000784: 7c 42 fe 76 sradi r2,r2,63 10000788: 78 0b 17 64 rldicr r11,r0,2,61 1000078c: 7c 42 58 38 and r2,r2,r11 10000790: 7d 8b 60 50 subf r12,r11,r12 10000794: 7d 8c 12 14 add r12,r12,r2 10000798: 3d 8c 00 01 addis r12,r12,1 1000079c: e9 6c 03 dc ld r11,988(r12) 100007a0: 39 8c 03 dc addi r12,r12,988 100007a4: e8 4c 00 08 ld r2,8(r12) 100007a8: 7d 69 03 a6 mtctr r11 100007ac: e9 6c 00 10 ld r11,16(r12) 100007b0: 4e 80 04 20 bctr 100007b4: 38 00 00 00 li r0,0 100007b8: 4b ff ff bc b 10000774 <.__do_global_ctors_aux+0x6c> 100007bc: 38 00 00 01 li r0,1 100007c0: 4b ff ff b4 b 10000774 <.__do_global_ctors_aux+0x6c> Disassembly of section .fini: 00000000100007c8 <._fini>: 100007c8: 7c 08 02 a6 mflr r0 100007cc: f8 01 00 10 std r0,16(r1) 100007d0: f8 21 ff 91 stdu r1,-112(r1) 100007d4: 60 00 00 00 nop 100007d8: 4b ff fc 29 bl 10000400 <.__do_global_dtors_aux> 100007dc: 60 00 00 00 nop 100007e0: 38 21 00 70 addi r1,r1,112 100007e4: e8 01 00 10 ld r0,16(r1) 100007e8: 7c 08 03 a6 mtlr r0 100007ec: 4e 80 00 20 blr ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2006-02-09 17:46 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-11-30 23:56 [PATCH] add 'rs6000_in_function_epilogue_p()' Paul Gilliam 2005-12-01 5:21 ` Jim Blandy 2005-12-01 18:27 ` Paul Gilliam 2005-12-01 20:14 ` Paul Gilliam 2005-12-02 1:13 ` Jim Blandy 2005-12-02 1:23 ` Daniel Jacobowitz 2005-12-02 20:12 ` Paul Gilliam 2005-12-02 20:17 ` Paul Gilliam 2005-12-03 3:05 ` Jim Blandy 2005-12-02 23:38 ` Jim Blandy 2005-12-04 20:19 ` Daniel Jacobowitz 2005-12-04 18:59 ` Daniel Jacobowitz 2005-12-04 20:48 ` Jim Blandy 2005-12-04 21:12 ` Jim Blandy 2005-12-04 21:16 ` Daniel Jacobowitz 2005-12-04 21:22 ` Jim Blandy 2005-12-02 4:02 ` Joel Brobecker 2005-12-02 18:44 ` Mark Kettenis 2005-12-02 19:15 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Paul Gilliam 2005-12-02 20:28 ` Mark Kettenis 2005-12-02 21:19 ` Daniel Jacobowitz 2005-12-02 21:21 ` Mark Kettenis 2005-12-03 4:53 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised, again) Paul Gilliam 2005-12-03 5:43 ` Paul Gilliam 2005-12-02 21:44 ` [PATCH] add 'rs6000_in_function_epilogue_p()' (Revised) Kevin Buettner 2005-12-06 15:20 ` Paul Gilliam 2005-12-06 15:15 ` Paul Gilliam 2005-12-08 4:42 ` Kevin Buettner 2006-01-11 17:44 ` Paul Gilliam 2006-01-12 0:12 ` Paul Gilliam 2006-01-12 23:53 ` Paul Gilliam 2006-01-13 21:05 ` Mark Kettenis 2006-01-17 3:46 ` Paul Gilliam 2006-01-17 19:29 ` Mark Kettenis 2006-02-09 17:46 ` Kevin Buettner 2005-12-02 22:19 ` Jim Blandy 2005-12-02 22:28 ` Daniel Jacobowitz 2005-12-02 23:20 ` Jim Blandy 2005-12-03 12:48 ` Paul Gilliam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox