Dwarf - 5 features in clang and llvm

Project Infrastructure LLVM Dev List Archives
1

Hello All,

I was working on some dwarf-5 features and debugging optimized code support in clang and llvm.

Noticed that, DW_TAG_call_site is supported in llvm middle-end. but clang is not emitting these.

I was hoping, if someone could provide current status of these features and current status of dwarf-5 features in clang and llvm.
That will be immensely helpful.

Thanks!
Sourabh.

2

Hi Sourabh,

Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end.
Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to
the DW_AT_call_all_calls.

There is also support for call-site-parameter (DW_TAG_call_site_parameter) and the debug entry values
(DW_OP_entry_value) related DWARF 5 symbols, but it is restricted by the CC1 option ‘-femit-debug-entry-values’,
since the LLDB is still missing support for that.

Best regards,
Djordje

3

Hi Sourabh,

Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end.
Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to
the DW_AT_call_all_calls.

There is also support for call-site-parameter (DW_TAG_call_site_parameter) and the debug entry values
(DW_OP_entry_value) related DWARF 5 symbols, but it is restricted by the CC1 option ‘-femit-debug-entry-values’,
since the LLDB is still missing support for that.

Not for too long :wink:

See https://reviews.llvm.org/D67410 & https://reviews.llvm.org/D67376

best,
vedant

4

Great to see this! :slight_smile:

Best,
Djordje

5

Hello Djordje, Vedant,

Thanks a lot for sharing information.

I have a doubt, please consider the following simple test case-
#include
int func(int* ptr){
std::cout << ptr;
return ptr + 5;
}
int main(int argc, char argv){
int a = 4;
int* ptr_a = &a;
int b = func(ptr_a);
return 0;

}
commandline used –
bash$ clang++ -Xclang -femit-debug-entry-values -O2 -ggdb test.cpp

For this case-- these Tags are not emitted
DW_TAG_call_site, DW_TAG_call_site_paramter …
only DW_AT_GNU_all_call_sites attribute is present.

  • @Djorde DW_TAG_call_site are supported using late MIR approach, are the new Call Site related development will be supported via MIR. or their will be a frontend level debug metadata support will be added.

Thanks!
Sourabh.

6

Hi Sourabh,

#include <iostream>
int func(int* ptr){
        std::cout << *ptr;
        return *ptr + 5;
}
int main(int argc, char** argv){
        int a = 4;
        int* ptr_a = &a;
        int b = func(ptr_a);
        return 0;
}

The 'func()' gets inlined, so according to the DWARF standard the call-site debug info should not be created for calls to inlined functions.

@Djorde DW_TAG_call_site are supported using late MIR approach, are the new Call Site related development will be supported via MIR. or their will be a frontend level debug metadata support will be added.

The new work is also implemented on the MIR level.

Best,
Djordje

7

Hi Djordje,

The ‘func()’ gets inlined, so according to the DWARF standard the call-site debug info should not be created for calls to inlined functions

Thanks for sharing this, Now the real problem is getting values of this optimized parameter “ptr” since func is inlined, variable ptr has location in debug_loc section {assuming DWARF-4}.
but for CLANG compiled binaries, gdb is reporting optimized out.

Reading symbols from test1_clang_O2…
(gdb) b func(int*)
Breakpoint 1 at 0x2010f4: func(int*). (2 locations)
(gdb) r
Starting program: /doc/test1_clang_O2

Breakpoint 1, func (ptr=) at test1.cpp:4
4 std::cout << *ptr;
(gdb) print *ptr
value has been optimized out

For GCC-9.2 compiled binaries, I’m able to print this optimized out the value of optimized out “ptr” variable.
Please note that GCC-9.2 is also emitting an extra DW_OP_GNU_implicit_poitner along with DW_OP_GNU_entry_value, DW_OP_stack_value. DW_OP_GNU_implicit_pointer is not emitted by CLANG.

The new work is also implemented on the MIR level.

Thanks for clarifying this.

Thanks!
Sourabh.

8

The 'func()' gets inlined, so according to the DWARF standard the call-site debug info >should not be created for calls to inlined functions.

While it is true that DW_TAG_call_site is not appropriate for an inlined
call, it is worth noting that the occurrence of inlined code should
(can) be described by DW_TAG_inlined_subroutine (see section 3.3 and
especially 3.3.8.2 Concrete Instances of the DWARF V5 standard). It is
the intent of the standard that when stopped at code in an inlined
function that a debugger be able to provide a more-or-less "normal" call
stack traceback reflecting the logical presence of the call. Assuming
the compiler has provided a full description, of course. (If the call is
completely optimized away then there is nothing to describe so neither
DW_TAG_call_site nor DW_TAG_inlined_subroutine is appropriate.)

Ron Brender, Editor
DWARF Standard Committee

9

Thanks for investigating. Could you file a report on bugs.llvm.org so that we can track this issue?

vedant (sent from my iPhone)