DWARFv5 by default in clang?

Should we change Clang’s default to DWARFv5?

(I’m motivated by having fixed a bug because I only tested with v4 - I should’ve tested with v5, but got me thinking about maybe v5 is just a better default at this point)

Google’s been using v5 as the default for the better part of a year at this point - not the most debugger usage, but we validated GDB and LLDB for v5 pretty well & haven’t encountered major issues since the switch.

On Darwin, we still have a sizeable number of test failures to go until we’re there: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/

– adrian

On Darwin, we still have a sizeable number of test failures to go until we’re there: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/

I’m not sure what/where/how to read that - could you give me some pointers?

In any case, as I recall, Darwin had a different default for quite a while after we switched the default on other platforms to v4, so I guess we could do the same thing for v5.

On Darwin, we still have a sizeable number of test failures to go until we’re there: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/

I’m not sure what/where/how to read that - could you give me some pointers?

Click on any successful runs in the DWARF5 column and then on “Logs”.

In any case, as I recall, Darwin had a different default for quite a while after we switched the default on other platforms to v4, so I guess we could do the same thing for v5.

Yes. I think we need to make this decision on a per-platform basis. On some platforms it may be even more nuanced. For example, when we moved macOS from DWARF v2 → DWARF v4, we only enabled DWARF v4 on target triples with a deployment target of *-apple-macosx10.11 and higher, since various tools in the OS need to be able to understand the format. I don’t know if other platforms have similar restrictions.

– adrian

The default DWARF version is target-dependent, it’s a hook in ToolChain.h (GetDefaultDwarfVersion). In the base class this returns 4; Darwin currently picks 2 for OS X 10.10 / iOS 8 or previous, and 4 otherwise.

Some targets already pick 5. It’s the ones that don’t explicitly pick that would be affected, of course. PS4 among them, of course, but I think we know what to do about it. :blush:

–paulr

On Darwin, we still have a sizeable number of test failures to go until we’re there: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/

I’m not sure what/where/how to read that - could you give me some pointers?

Click on any successful runs in the DWARF5 column and then on “Logs”.

In any case, as I recall, Darwin had a different default for quite a while after we switched the default on other platforms to v4, so I guess we could do the same thing for v5.

Yes. I think we need to make this decision on a per-platform basis. On some platforms it may be even more nuanced. For example, when we moved macOS from DWARF v2 → DWARF v4, we only enabled DWARF v4 on target triples with a deployment target of *-apple-macosx10.11 and higher, since various tools in the OS need to be able to understand the format. I don’t know if other platforms have similar restrictions.

Agree that this is a per-platform decision.

For clang::driver::toolChains::Generic_GCC, we can define GetDefaultDwarfVersion() to 5 to match GCC 11’s switch (https://gcc.gnu.org/gcc-11/changes.html).

For targets that produce DWARF debugging information GCC now defaults to DWARF version 5 (with the exception of VxWorks and Darwin/Mac OS X which default to version 2 and AIX which defaults to version 4). This can produce up to 25% more compact debug information compared to earlier versions.

Generic_GCC has many (indirect) derived classes (FreeBSD/OpenBSD/Solaris) which override the base GetDefaultDwarfVersion().

The Generic_GCC change will affect Haiku/Hurd/Linux/NetBSD/PS4CPU/etc. I have CC’d these folks: if your platform is not ready for DWARF v5, you can override GetDefaultDwarfVersion() in your toolchain.

Generic_GCC has many (indirect) derived classes
(FreeBSD/OpenBSD/Solaris) which override the base
GetDefaultDwarfVersion().
The Generic_GCC change will affect
Haiku/Hurd/Linux/NetBSD/PS4CPU/etc. I have CC'd these folks: if
your platform is not ready for DWARF v5, you can override
GetDefaultDwarfVersion() in your toolchain.

PS4 updated to set v4 explicitly as of
https://github.com/llvm/llvm-project/commit/b8e03be88dc87303f7401ea7b9906947ac67a6db
--paulr

> Generic_GCC has many (indirect) derived classes
> (FreeBSD/OpenBSD/Solaris) which override the base
> GetDefaultDwarfVersion().
> The Generic_GCC change will affect
> Haiku/Hurd/Linux/NetBSD/PS4CPU/etc. I have CC'd these folks: if
> your platform is not ready for DWARF v5, you can override
> GetDefaultDwarfVersion() in your toolchain.

We have been using v5 in yocto with clang13 onwards as well [1] and
have not seen any blockers.

[1] https://github.com/kraj/meta-clang/blob/master/recipes-devtools/clang/clang/0027-clang-Switch-defaults-to-dwarf-5-debug-info-on-Linux.patch

Hey Stephen,

I see you added a test to ensure Android uses DWARFv4 here: https://reviews.llvm.org/D60238

Is that still the case? I can figure out how to ensure that’s the case as we transition the default to DWARFv5 for platforms that haven’t opted out.

Well, made the switch to DWARFv5 by default in d3b26dea16108c427b19b5480c9edc76edf8f5b4 and included a change to keep DWARFv4 as the default for linux-androideabi (at least I think I made that change in the right place). If it needs to be more generic (apply to non-linux toolchains, but I don’t think so?) or can be removed because Android’s OK with DWARFv5 - should be simple to make that change.

Heh, I actually just moved the Android platform build to DWARFv5 last week (https://android-review.googlesource.com/c/platform/build/soong/+/1954424). We had previously tried this but had to revert it due to some issues with libabigail. I’ll move upstream LLVM to default to DWARFv5 for Android more generally soon. Thanks for reminding me to do so.

Thanks,
Steve

Heh, I actually just moved the Android platform build to DWARFv5 last week (https://android-review.googlesource.com/c/platform/build/soong/+/1954424). We had previously tried this but had to revert it due to some issues with libabigail. I’ll move upstream LLVM to default to DWARFv5 for Android more generally soon. Thanks for reminding me to do so.

Thanks for making platforms more aligned with the modern standard :slight_smile:

Thanks,
Steve

Well, made the switch to DWARFv5 by default in d3b26dea16108c427b19b5480c9edc76edf8f5b4 and included a change to keep DWARFv4 as the default for linux-androideabi (at least I think I made that change in the right place). If it needs to be more generic (apply to non-linux toolchains, but I don’t think so?) or can be removed because Android’s OK with DWARFv5 - should be simple to make that change.

Congratulations to the switch!

(I was thinking whether we’d need a CMake variable, hopefully we won’t need it.)

Heh, I actually just moved the Android platform build to DWARFv5 last week (https://android-review.googlesource.com/c/platform/build/soong/+/1954424). We had previously tried this but had to revert it due to some issues with libabigail. I’ll move upstream LLVM to default to DWARFv5 for Android more generally soon. Thanks for reminding me to do so.

Awesome :slight_smile:

Heh, I actually just moved the Android platform build to DWARFv5 last week (https://android-review.googlesource.com/c/platform/build/soong/+/1954424). We had previously tried this but had to revert it due to some issues with libabigail. I’ll move upstream LLVM to default to DWARFv5 for Android more generally soon. Thanks for reminding me to do so.

Thanks for making platforms more aligned with the modern standard :slight_smile:

Thanks,
Steve

Well, made the switch to DWARFv5 by default in d3b26dea16108c427b19b5480c9edc76edf8f5b4 and included a change to keep DWARFv4 as the default for linux-androideabi (at least I think I made that change in the right place). If it needs to be more generic (apply to non-linux toolchains, but I don’t think so?) or can be removed because Android’s OK with DWARFv5 - should be simple to make that change.

Congratulations to the switch!

(I was thinking whether we’d need a CMake variable, hopefully we won’t need it.)

Yeah, fingers crossed Few curious things in compiler-rt tests I need to followup on.