[RFC][DebugInfo/DWARF] Refactor into to lower- and higher-level libraries

LLVM Project
,
1

I need to use dwarf expressions from MC, but depending on libDebugInfoDWARF from MC creates a layering violation. The error most easily seen from bazel builds, but it shows up as link-errors under cmake as well:

@@llvm-project//llvm:MC 
.-> @@llvm-project//llvm:MC
|   @@llvm-project//llvm:DebugInfoDWARF 
|   @@llvm-project//llvm:Object 
|   @@llvm-project//llvm:MCParser 
`-- @@llvm-project//llvm:MC

The code already supports not having an object file or section at runtime by checking for null pointers. For example, DWARFDataExtractor::getRelocatedValue. But they still have this build time dependency.

Splitting it up isn’t difficult (list of patches below). But what should the final result look like? One possible solution would be to move these low-level pieces into a new library llvm/DebugInfo/DWARF/LowLevel, with some forwarding headers so that clients that don’t care can continue to work without modification, and clients that want low-level only can depend just on the low level portions.

Any thoughts?

2

With no responses, I’m going to assume no one has a strong opinion, and will proceed.

3

I think in the new governance model, it’s the responsibility of the relevant area team to identify next steps. I think we have a fancy new alias to send notifications, so let me see if it works: @llvm-area-team

4

My two cents here is that this is a pretty low level code organization question, and basically up to reviewer discretion. If DWARF reviewers are happy with the new code organization, I am happy with the new code organization :slight_smile:

It looks like most of the preliminary changes for this have already been approved and landed, and what is left now is [NFC][DebugInfo][DWARF] Create new low-level dwarf library by Sterling-Augustine · Pull Request #145081 · llvm/llvm-project · GitHub.

1 Like
5

Just to close the loop here, this has been completed since 777d6b5de90b7e0d1ceaa1424c6da4590539c007