No DW_AT_abstract_origin emitted for a DW_TAG_lexical_block in an inlined function

[barisaktemur]

Bugzilla Link	49953
Version	11.0
OS	Linux
CC	@dwblaikie,@JDevlieghere,@jmorse,@walkerkd,@pogo59,@zygoloid

Extended Description

Suppose we have

attribute((always_inline))
static void aFunction() {
int a = 42;
if(a > 2) {
int value = a;
value += 10;
}
}

The debug info for the concrete inlined instance of this function does not
contain DW_AT_abstract_origin attributes in the DW_TAG_lexical_block
entries. E.g. the DIE of the inlined function above is

0x00000087: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0000002a "aFunction")
DW_AT_low_pc (0x00000000004004b2)
DW_AT_high_pc (0x00000000004004d2)
DW_AT_call_file ("/tmp/test.c")
DW_AT_call_line (11)
DW_AT_call_column (0x03)

0x0000009b: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -4)
DW_AT_abstract_origin (0x00000032 "a")

0x000000a3: DW_TAG_lexical_block
DW_AT_low_pc (0x00000000004004c3)
DW_AT_high_pc (0x00000000004004d2)

0x000000b0: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -8)
DW_AT_abstract_origin (0x0000003e "value")

whereas the abstract DIE is

0x0000002a: DW_TAG_subprogram
DW_AT_name ("aFunction")
DW_AT_decl_file ("/tmp/test.c")
DW_AT_decl_line (2)
DW_AT_inline (DW_INL_inlined)

0x00000032: DW_TAG_variable
DW_AT_name ("a")
DW_AT_decl_file ("/tmp/test.c")
DW_AT_decl_line (3)
DW_AT_type (0x0000004b "int")

0x0000003d: DW_TAG_lexical_block

0x0000003e: DW_TAG_variable
DW_AT_name ("value")
DW_AT_decl_file ("/tmp/test.c")
DW_AT_decl_line (5)
DW_AT_type (0x0000004b "int")

I'm not 100% sure that omitting the DW_AT_abstract_origin is a bug.
However, the DWARF 5 spec states in Section 3.3.8.2 that

A concrete instance tree may contain entries which do not correspond to
entries in the abstract instance tree to describe new entities that are specific to
a particular inlined expansion. In that case, they will not have associated
entries in the abstract instance tree, do not contain DW_AT_abstract_origin
attributes, and must contain all their own attributes directly.

If I read this backward, I interpret that an entry without a DW_AT_abstract_origin
attribute denotes an entry that does not exist in the abstract instance tree.
This makes me believe that Clang's behavior is a bug.

When the DW_AT_abstract_origin attribute is missing, a consumer may try
to find the corresponding abstract origin, but this may not be a bullet-proof
process in general. If Clang emitted it explicitly, the association could be
done with precision.

[pogo59]

Moving to libraries/DebugInfo, as inlining is handled by LLVM.

A concrete instance tree may contain entries which do not correspond to
entries in the abstract instance tree to describe new entities that are
specific to
a particular inlined expansion. In that case, they will not have
associated
entries in the abstract instance tree, do not contain
DW_AT_abstract_origin
attributes, and must contain all their own attributes directly.

If I read this backward, I interpret that an entry without a
DW_AT_abstract_origin
attribute denotes an entry that does not exist in the abstract instance tree.
This makes me believe that Clang's behavior is a bug.

Two possibilities: (1) we never thought about it, (2) we did think about
it and concluded that it's unnecessary because the abstract instance has
no attributes.

I tend to be pretty pedantic when it comes to interpreting DWARF, but
I'm not sure what benefit we'd gain from having this abstract_origin.

When the DW_AT_abstract_origin attribute is missing, a consumer may try
to find the corresponding abstract origin, but this may not be a bullet-proof
process in general.

If the attribute is missing, particularly from a lexical_block, I don't
see why a consumer would try to find an abstract origin. The concrete
lexical block has all the attributes of interest on it, and DWARF does not
promise there is an abstract lexical block to find.

Is there a consumer that is having trouble because of this?

[dwblaikie]

One reason that'd be good to have this would be for llvm-dwarfdump statistics.

If you have a variable that's fully optimized out, but its scope is not - having the abstract_origin of the scope would let us determine how many instructions were uncovered by the variable.

It'd also be useful for name lookup in a debugger:

void f1() {
int a = 3; // this could be a global or some other case of shadowing
{
int a = 8;
func();
}
}

So if you inline that, both 'a' get optimized away, when you're evaluating 'func' you don't know that 'a' is in scope (because you don't know which scope you're in - let's say there were more than one lexical scope in f1, so there's ambiguity).

[barisaktemur]

If the attribute is missing, particularly from a lexical_block, I don't
see why a consumer would try to find an abstract origin. The concrete
lexical block has all the attributes of interest on it, and DWARF does not
promise there is an abstract lexical block to find.

Is there a consumer that is having trouble because of this?

Not having the abstract origin confuses the scopes of local variables
in GDB. I proposed a fix for it here:
https://sourceware.org/pipermail/gdb-patches/2021-February/176203.html