Hi --
I don't think that a fix in GDB would be appropriate.
GDB is doing exactly what it should -- it places a breakpoint
at the first line in the function.
GCC should not output a line entry in the middle of the prologue.
Luis Machado wrote:
Hi,
Yes, this is exactly what i was chasing some
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
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).
Th
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:
>
Hi --
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_cf
