johannes added a comment.
Thanks for the very useful feedback! Now I can finally see why this is
happening.
Below is the relevant excerpt of the input DWARF:
one of the DW_AT_low_pc attributes is NULL, which does not happen when I link
with GNU ld.
clang lldb/test/Shell/Expr/Inputs/function-address-{main,lib}.cpp -g
-fuse-ld=lld -o - |
llvm-dwarfdump -debug-info /dev/stdin
0x00000203: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000201940)
DW_AT_high_pc (0x000000000020194f)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_object_pointer (0x0000021a)
DW_AT_specification (0x00000069
"_ZNK14llvm_namespace10TinyVector4fourEv")
0x0000021a: DW_TAG_formal_parameter
DW_AT_location (DW_OP_fbreg -8)
DW_AT_name ("this")
DW_AT_type (0x0000027a "const TinyVector*")
DW_AT_artificial (true)
0x00000226: NULL
0x0000053a: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000000000)
DW_AT_high_pc (0x000000000000000f)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_object_pointer (0x00000551)
DW_AT_specification (0x00000309
"_ZNK14llvm_namespace10TinyVector4fourEv")
0x00000551: DW_TAG_formal_parameter
DW_AT_location (DW_OP_fbreg -8)
DW_AT_name ("this")
DW_AT_type (0x00000563 "const TinyVector*")
DW_AT_artificial (true)
0x0000055d: NULL
I think I found how GDB handles this case:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/dwarf2read.c;h=ecfae68427716333ab060ef1c44b3a25df9d7ac0;hb=HEAD#l14756
Now I have a rough implementation of the same idea.
I can probably come up with a unit test in `SymbolFileDWARFTests` that
checks that the function address is correct after parsing above DWARF.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71487/new/
https://reviews.llvm.org/D71487
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
