Re: Possible problem with debugging info on new abi constructors

[Jason Merrill <jason at redhat dot com>]

>>>>> "Daniel" == Daniel Berlin <dberlin@redhat.com> writes:

> It appears that both are getting marked as having the same location and
> line info, yet they really don't, so that setting a breakpoint on one may
> miss some construction cases.

They should have the same line info, as they are two copies of the same
function.  This is equivalent to the function cloning optimization done by
SGI's highly optimizing compiler.

> They can't *both* be line and 5 and 6 if you want GDB to work.
> We can't handle multiple physical locations for one line of code.

Then IMO that needs to be fixed.  This would also be useful if we want to
try to set breakpoints on inlined functions at some point.

> There needs to be a common code label that both constructors call.
> and a location emitted for that place, as if it was the constructor.

> That way, you can breakpoint the constructor as that.

That would certainly be one way to implement the ABI.  I was somewhat
surprised that Mark chose to clone the entire function instead, but it
probably makes sense given how much ports vary in their handling of
function beginnings; there's really no way to express that sort of thing
to the current backend.

> Regardless, the object file claims:
>  Extended opcode 2: set Address to 0x0
>   Special opcode 9: advance Address by 0 to 0x0 and Line by 4 to 5
>   Special opcode 48: advance Address by 12 to 0xc and Line by 1 to 6
>   Special opcode 34: advance Address by 8 to 0x14 and Line by 1 to 7
>   Advance PC by 16 to 24
>   Extended opcode 1: End of Sequence

> <...>
>   Extended opcode 2: set Address to 0x0
>   Special opcode 9: advance Address by 0 to 0x0 and Line by 4 to 5
>   Special opcode 48: advance Address by 12 to 0xc and Line by 1 to 6
>   Special opcode 34: advance Address by 8 to 0x14 and Line by 1 to 7
>   Advance PC by 16 to 24
>   Extended opcode 1: End of Sequence

> Which can't be right, unless there is some magic here going on that i'm
> not aware of.

> They certainly both have different physical locations.

Certainly.  I think the problem is that you're looking at the unrelocated
object file, so both relocs show up as address 0x0.  If you link the
program and look at the line info again, they should have different
addresses.

They will, of course, still have the same source locations.

Jason