This is an archive of the discontinued LLVM Phabricator instance.

[DWARFLinker][NFC] Set the target DWARF version explicitly.
ClosedPublic

Authored by avl on Aug 26 2022, 12:27 PM.

Details

Summary

Currently, DWARFLinker determines the target DWARF version internally.
It examines incoming object files, detects maximal
DWARF version and uses that version for the output file.
This patch allows explicitly setting output DWARF version by the consumer
of DWARFLinker. So that DWARFLinker uses a specified version instead
of autodetected one. It allows consumers to use different logic for
setting the target DWARF version. f.e. instead of the maximally used version
someone could set a higher version to convert from DWARFv4 to DWARFv5
(This possibility is not supported yet, but it would be good if
the interface will support it). Or another variant is to set the target
version through the command line. This patch moves the autodetection into the
consumers(DwarfLinkerForBinary.cpp, DebugInfoLinker.cpp).

Diff Detail

Event Timeline

avl created this revision.Aug 26 2022, 12:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 12:27 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
avl requested review of this revision.Aug 26 2022, 12:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 12:27 PM

However, as they're built with the same compiler and flags, it is safe to assume that they will follow the decision made here.

When using static libraries, that's far from a guarantee.

avl added a comment.Aug 26 2022, 12:41 PM

However, as they're built with the same compiler and flags, it is safe to assume that they will follow the decision made here.

When using static libraries, that's far from a guarantee.

That assumption is currently used in DWARFLinker. If we would like to remove it and use another - I will prepare separate review which will also examine modules.

avl updated this revision to Diff 457856.Sep 4 2022, 7:08 AM

rebased. Returned check for modules version back.

avl edited the summary of this revision. (Show Details)Sep 5 2022, 7:32 AM

What's the motivation for this, exactly? It seems weird to use this tool as a way to upgrade DWARF (& sort of weird to upgrade DWARF after-the-fact anyway, why not generate the desired DWARF in the first place?)

avl added a comment.Sep 8 2022, 1:14 PM

What's the motivation for this, exactly?

The main motivation is to have the possibility to set conversion options explicitly. f.e. currently, Target dwarf version is detected by DWARFLinker internally, type of accelerator table is also detected internally. The caller of DWARFLinker does not know the state of these options. So it is hard to implement handling depending on these implicit options. f.e. If the caller would like to set "Apple" accelerator table for DWARFv4 and "DebugNames" for DWARFv5 - it could not be done as the caller does not know the target version. It is also not good to put that handling(setting type of accelerator table based on DWARF version) inside DWARFLinker as different callers of DWARFLinker may have different requirements. So the main motivation for that change is to set options explicitly, to have a possibility to implement different behaviors in different callers.

It seems weird to use this tool as a way to upgrade DWARF (& sort of weird to upgrade DWARF after-the-fact anyway, why not generate the desired DWARF in the first place?)

It looks to me, that feature of converting to different DWARF versions might be good. We can have a backup of binaries compiled with DWARF4. It might be useful to convert them into the DWARF5 without recompiling. That feature is not supported by the current DWARFLinker, but it might be useful. This interface change makes it possible to implement that behavior in the future. Though it is not the main motivation.

Mixed feelings, but the indexing situation's somewhat motivational - though I think it'd be OK for it to be an error if you asked for DWARFv5 accelerator tables but the contents was producing DWARFv4 (or to have the request for DWARFv5 accelerator tables to up the version to DWARFv5 - though that wouldn't need a user-visible option to explicitly ask for DWARFv5)

But don't mind me - was curious, but not a blocker.

avl added a comment.Sep 9 2022, 7:25 AM

Mixed feelings, but the indexing situation's somewhat motivational - though I think it'd be OK for it to be an error if you asked for DWARFv5 accelerator tables but the contents was producing DWARFv4 (or to have the request for DWARFv5 accelerator tables to up the version to DWARFv5 - though that wouldn't need a user-visible option to explicitly ask for DWARFv5)

The good thing about interface changes from this patch is that it allows implementing any strategy(since option is set explicitly). It may be done "OK for it to be an error if you asked for DWARFv5 accelerator tables but the contents was producing DWARFv4", or it could be done "request for DWARFv5 accelerator tables to up the version to DWARFv5", or "set Apple for DWARFv4, set DebugNames for DWARF5 ", or anything else.

Mixed feelings, but the indexing situation's somewhat motivational - though I think it'd be OK for it to be an error if you asked for DWARFv5 accelerator tables but the contents was producing DWARFv4 (or to have the request for DWARFv5 accelerator tables to up the version to DWARFv5 - though that wouldn't need a user-visible option to explicitly ask for DWARFv5)

But don't mind me - was curious, but not a blocker.

This support exists because dsymutil has the ability to upgrade the accelerator tables. IIRC Greg added this when he designed the Apple accelerator tables. I extended that support when we added support for .debug_names and used that to test LLDB. So this is definitely intentional.

Things are easy when the user explicitly asked for a given accelerator type. I think the same thing makes sense for the DWARF version which is what this patch is doing.

This revision is now accepted and ready to land.Sep 14 2022, 8:50 AM
avl added a comment.Sep 15 2022, 6:11 AM

Thank you for the review!

This revision was automatically updated to reflect the committed changes.