[Bug debug/94474] Incorrect DWARF range information for inlined function

["bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474

--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Andrew,

(In reply to Andrew Burgess from comment #10)
> Further, I've seen no mention of exit views anywhere, and I think they
> would also be needed.
> 

Yes, that is also my idea, when I say the dwarf2 spec needs to
be fixed.

> With the addition of these two features we would be able to support (I
> believe) fully merged callers and callees, with lines marked as
> is-stmt from both the caller and callee appearing at the same address.
> 
> For now, without this, I think GCC needs to restrict itself when
> inlining.  When an address represents a line from both the caller and
> callee, then that address should only be is-stmt true for EITHER lines
> from the caller, or lines from the callee.  If the address is is-stmt
> true for a line from the caller, then the address should NOT be within
> the callee's range(s), and if the address is is-stmt true for a line
> from the callee, then the address MUST be within the callee's
> range(s).
> 

I tried to do something similar, in my original gcc-patch,
which was unfortunately not accepted.

But what I learned from writing the patch is that gcc cannot
easily tell if a range will be empty or not.  That is because
the assembler does emit the line info and the views,
and the assembler decides how many bytes if any a certain
construct will take in the binary representation.

That is why this empty range appears, because that was
supposed to be the start of the inline function, but
instructions from the function prologue were moved in there.
What causes the problem is the is-stmt line info which
is the only remaining thing from the original plan.
But on the other hand, it is not a big issue for gdb to
ignore those artefacts, when they rarely occur.
My gdb-patch does this, by changing the is-stmt bit of
this line info.

> On a final note.  These are just my personal thoughts from the
> perspective of a debug consumer, though I use words like "must" or
> "should" above this reflects my thoughts on how I believe the debug
> should appear, and is not an attempt to prescribe how GCC should
> be.  I know there are limitations to what GCC can achieve, and also, I
> could be totally wrong in my understanding of DWARF.  I'm always happy
> to be corrected!

Yeah, that is true for myself as well.

Ping, Alexandre Oliva, are you still with us?
I would be curious to know what you think, about this how
should we proceed?


Thanks
Bernd.