Incorrect line info in printf for powerpc-eabisim -mhard-foat

Incorrect line info in printf for powerpc-eabisim -mhard-foat

[Michael Eager]

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_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.

I'll file a bug report unless someone already has done so.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat

[Peter Bergner]

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

Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat

[Luis Machado]

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
> 
> 
> 

Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat

[Luis Machado]

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
> > 
> > 
> > 
> 

Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat

[Michael Eager]

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 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
>>
>>
>>
> 
> 


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077