Actually, thinking further, the fix is for a consequence of the incorrect placement of the breakpoint right after the branch.
I remember hitting the problem described too, but i didn't pursue a fix for that (yet). Luis On Tue, 2009-07-21 at 10:50 -0300, Luis Machado wrote: > Hi, > > Yes, this is exactly what i was chasing some time ago. The GCC fix i had > in mind (it just changes the ordering of statements) didn't get through > since it dealt with arch-independent code and there was fear that this > would break architectures other than PPC (or have the potential to do > so). > > The breakpoint is placed at the wrong place due to the branch > instruction in the prologue. GDB just assumes that the second BB is real > code (not prologue anymore) since GCC never provided any useful > information on where exactly the prologue ends. > > Original thread is here: > http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01213.html > > A fix on GDB's side proved to be harder than in GCC's side (since we're > already assuming things, it would just be another workaround). > > Luis > > On Tue, 2009-07-21 at 08:38 -0500, Peter Bergner wrote: > > On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote: > > > I've tracked down a failure in gdb to hit a breakpoint > > > set at printf to the the breakpoint being placed incorrectly. > > > > > > Here is the code generated for printf with -mhard-float: > > > > > > .loc 1 29 0 > > > .cfi_startproc > > > .LVL0: > > > mflr 0 > > > stwu 1,-112(1) > > > .LCFI0: > > > .cfi_def_cfa_offset 112 > > > stw 5,24(1) > > > stw 0,116(1) > > > stw 6,28(1) > > > stw 7,32(1) > > > stw 8,36(1) > > > stw 9,40(1) > > > stw 10,44(1) > > > bne- 1,.L2 <<< - 1 > > > .cfi_offset 65, 4 > > > .loc 1 29 0 <<< - 2 > > > stfd 1,48(1) <<< - 3 > > > stfd 2,56(1) > > > stfd 3,64(1) > > > stfd 4,72(1) > > > stfd 5,80(1) > > > stfd 6,88(1) > > > stfd 7,96(1) > > > stfd 8,104(1) > > > .L2: > > > .loc 1 34 0 > > > > > > Gdb places a breakpoint at printf() at the stfd instruction (3). > > > This appears to be because of the .loc at (2). When the code is > > > executed, the branch (1) is taken, jumping over the the breakpoint. > > > I think that the .loc at (2) should not be generated, since it is > > > in the middle of the prologue code. > > > > Luis, isn't there a bugzilla regarding this? This seems to me to > > be similar to what you had been looking at. > > > > Peter > > > > > > >
