On 11/22/2017 12:56 PM, Simon Marchi wrote:
Hi,
I had an email discussion some time ago with some gcc developers
(Nathan Sidwell,
Richard Biener, Jason Merill). I though I would post the important
parts here,
to act as a reference.
Richard said:
I think the lexical block is just the function scope itself and the
inliner
inserts this BLOCK which then corresponds to the
DW_TAG_inlined_subroutine.
I suppose we should avoid emitting that BLOCK itself as a
DW_TAG_lexical_block
but use the emitted DW_TAG_inlined_subroutine for that.
Not sure if I remember the details correctly.
I don't think the DWARF is invalid btw, with early LTO debug we have
plenty of
abstract origins where source and destination context don't match
1:1. We're
just using it as a "get some more info from this DIE" link which I
think is
all that is documented as semantics (though the 'inline' term pops up
too
often there and the relation to DW_AT_specification is unclear to me
though
the latter is restricted to DW_TAG_subroutine AFAIR).
Jason said (replying to Richard):
I think the lexical block is just the function scope itself and the
inliner
inserts this BLOCK which then corresponds to the
DW_TAG_inlined_subroutine.
I suppose we should avoid emitting that BLOCK itself as a
DW_TAG_lexical_block
but use the emitted DW_TAG_inlined_subroutine for that.
Agreed. It's curious that we would generate the lexical block in the
inlined instance and not the abstract.
I don't think the DWARF is invalid btw, with early LTO debug we
have plenty of
abstract origins where source and destination context don't match
1:1. We're
just using it as a "get some more info from this DIE" link which I
think is
all that is documented as semantics (though the 'inline' term pops
up too
often there and the relation to DW_AT_specification is unclear to
me though
the latter is restricted to DW_TAG_subroutine AFAIR).
Also agreed, GDB ought to be able to handle this situation.
So, bugs on both sides...
So the conclusion seems to be that the lexical block might be useless,
but it
doesn't make the DWARF invalid, and GDB should be able to cope with
it.
I think that the DWARF is invalid.
In the abstract instance, the DWARF describes the source as
int func1 (...)
{
int array[];
...
}
The concrete instance describes a different source:
int func1 (...)
{
{
int array[];
...
}
}
These are not the same source trees and the second one does not in
fact accurately describe the actual source. I don't recall if there
is a requirement in the DWARF Spec that the concrete and abstract
instance descriptions need to match each other. If not, I think that
there should be.
I'd like to see an example (as Jason mentioned) where abstract and
concrete instances do not match and where this appears to be correct.
If LLVM is using abstract origin to mean "get info from this DIE", and
not to mean "this is a concrete instance of this abstract definition",
then we (on the DWARF side) need to look at how abstract origin is
defined and whether this use is compatible with its intended use.