This is an archive of the discontinued LLVM Phabricator instance.

[DWARFLinker][DWARFv5] Add handling of DW_OP_addrx and DW_OP_constx expression operands.
ClosedPublic

Authored by avl on Mar 28 2023, 10:19 AM.

Details

Summary

This patch adds handling of DW_OP_addrx and DW_OP_constx expression operands.
In --update case these operands are preserved as is. Otherwise they are
converted into the DW_OP_addr and DW_OP_const[*]u correspondingly.

Diff Detail

Event Timeline

avl created this revision.Mar 28 2023, 10:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2023, 10:19 AM
avl requested review of this revision.Mar 28 2023, 10:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2023, 10:19 AM
avl added a comment.Apr 10 2023, 2:56 AM

friendly ping.

JDevlieghere added inline comments.Apr 14 2023, 10:36 AM
llvm/include/llvm/DWARFLinker/DWARFLinkerCompileUnit.h
58–72

Instead of wrapping PatchLocation in another struct, would it make sense to add the RelocAdjustment to the PatchLocation itself?

llvm/lib/DWARFLinker/DWARFLinker.cpp
1216
1235
1249
llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
1022–1060

The code to parse the exprloc here is very similar to that in the dsymutil variant. Any chance we could hoist some of this logic into the DWARFLinker?

avl updated this revision to Diff 515295.Apr 20 2023, 5:47 AM

addressed comments. Deleted PatchWithRelocAdjustment. Refactored code parsing the exprloc.

avl updated this revision to Diff 519377.May 4 2023, 1:07 AM

rebased.

avl added a comment.May 8 2023, 10:17 AM

friendly ping :-)

This revision is now accepted and ready to land.May 15 2023, 2:54 PM
This revision was landed with ongoing or failed builds.May 16 2023, 10:27 AM
This revision was automatically updated to reflect the committed changes.
amyk added a subscriber: amyk.May 16 2023, 9:35 PM

Hi, it appears that this patch is causing some failures on the big endian PPC bots, such as:
https://lab.llvm.org/buildbot/#/builders/93/builds/14929
https://lab.llvm.org/buildbot/#/builders/231/builds/11866

If you're able to help take a look at this, that would be greatly appreciated.

avl added a comment.May 17 2023, 2:06 AM

Thank you for reporting the issue, the https://reviews.llvm.org/rGddf5bfd6e6e2fc5b94718a29e718b4f821a3b853 should fix it.

avl added a comment.May 17 2023, 3:28 AM

Thank you for reporting the issue, the https://reviews.llvm.org/rGddf5bfd6e6e2fc5b94718a29e718b4f821a3b853 should fix it.

It did not fix the problem. Will look more.

amyk added a comment.May 17 2023, 10:21 AM

Thanks so much for the fix! Greatly appreciate it.

Michael137 added a subscriber: Michael137.EditedJun 14 2023, 4:16 AM

Looks like this broke the lldb matrix bots for DWARFv2: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/6580/execution/node/54/log/

********************
Failed Tests (2):
  lldb-api :: lang/c/tls_globals/TestTlsGlobals.py
  lldb-api :: lang/cpp/thread_local/TestThreadLocal.py

The problem is that dsymutil strips out thread_local variables when the binary is compiled with -gdwarf-2.

Reproducer:

int storage = 45;                          
thread_local int tl_global_int = 123;      
thread_local int *tl_global_ptr = &storage;
                                           
int main(int argc, char **argv) {          
  thread_local int tl_local_int = 321;     
  thread_local int *tl_local_ptr = nullptr;
  tl_local_ptr = &tl_local_int;            
  tl_local_int++;                          
  return 0; // Set breakpoint here         
}                                          

clang++ -g -O0 -gdwarf-2 -c main.cpp -o main.o -std=c++2a
clang++ main.o -o a.out
dsymutil a.out
dwarfdump a.out.dSYM --find tl_global_ptr

Observe that there is no entry for tl_global_ptr anymore. Compiling with -gdwarf-4 doesn't behave this way.

avl added a comment.Jun 14 2023, 4:27 AM

Looks like this broke the lldb matrix bots for DWARFv2: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/6580/execution/node/54/log/

********************
Failed Tests (2):
  lldb-api :: lang/c/tls_globals/TestTlsGlobals.py
  lldb-api :: lang/cpp/thread_local/TestThreadLocal.py

The problem is that dsymutil strips out thread_local variables when the binary is compiled with -gdwarf-2.

Reproducer:

int storage = 45;                          
thread_local int tl_global_int = 123;      
thread_local int *tl_global_ptr = &storage;
                                           
int main(int argc, char **argv) {          
  thread_local int tl_local_int = 321;     
  thread_local int *tl_local_ptr = nullptr;
  tl_local_ptr = &tl_local_int;            
  tl_local_int++;                          
  return 0; // Set breakpoint here         
}                                          

clang++ -g -O0 -gdwarf-2 -c main.cpp -o main.o -std=c++2a
clang++ main.o -o a.out
dsymutil a.out
dwarfdump a.out.dSYM --find tl_global_ptr

Observe that there is no entry for tl_global_ptr anymore. Compiling with -gdwarf-4 doesn't behave this way.

Thank you for reporting the issue. Will take a look.

FWIW, depending on what the actual problem is, you don't need to go out of your way to fix TLS on dwarf 2. I'd be fine with marking these tests as requiring DWARF 4+ in the LLDB test suite if that makes sense.