[Driver] Default to DWARF 4 on Linux/sparc64

[ro]

Summary

During a build on Debian 11/sparc64, several binaries fail to link with

/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x23

/usr/bin/ld is GNU ld (GNU Binutils for Debian) 2.38.50.20220707. 0x23 is DW_FORM_rnglistx` which isn't handled even by GNU binutils master. Building with -gdwarf-4 avoids this.

Tested on sparc64-unknown-linux-gnu.

For comparison's sake, I've tried a build on Ubuntu 20.04/x86_64 with GNU ld 2.38.90, which isn't affected.

[glaubitz]

Interesting and thanks for catching this! How did you discover this issue? Is there any particular program that fails to build due to this issue?

[ro]

In D130566#3679480, @glaubitz wrote:

Interesting and thanks for catching this! How did you discover this issue? Is there any particular program that fails to build due to this issue?

Sure: many programs fail to link during ninja check-all for this problem.

[MaskRay]

Consider creating a minimum reproduce and filing a bug on https://sourceware.org/bugzilla/buglist.cgi

[dblaikie]

During a build on Debian 11/sparc64, several binaries fail to link with

/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x23

What's the linker doing parsing DWARF? Any idea what feature this is? And why is it SPARC-specific? Or is it true of other targets on the same Debian version?

[ro]

In D130566#3681129, @dblaikie wrote:

During a build on Debian 11/sparc64, several binaries fail to link with

/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x23

What's the linker doing parsing DWARF? Any idea what feature this is? And why is it SPARC-specific? Or is it true of other targets on the same Debian version?

I have no idea, actually. The code in question is bfd/dwarf2.c (read_attribute_value), who's comment states:

/* Read and fill in the value of attribute ATTR as described by FORM.
   Read data starting from INFO_PTR, but never at or beyond INFO_PTR_END.
   Returns an updated INFO_PTR taking into account the amount of data read.  */

So far, I had only seen it with the GNU ld 2.38.50 bundled with Debian 11/sparc64, but couldn't reproduce on Ubuntu 20.04/x86_64 (neither bundled GNU ld 2.34, nor self-compiled 2.38.90). Things got even weirder when I tried to create a minimal testcase for a binutils bug report: I'd initially seen the error when linking Sanitizer-sparc-Test. However, at that time the link also failed due to D130571. I got the unhandled FORM value error several times, probably for several different input objects. However, when adding -latomic to the link, the link did succeed without issues.

I've since ran a full build with all pending patches, just without this one, and didn't see the DWARF error again. This is all extremely weird, but until the error shows up again, I'll put this patch on hold (not yet abandoning since there seems to be no way to unabandon if necessary).

[dblaikie]

This is all extremely weird, but until the error shows up again, I'll put this patch on hold (not yet abandoning since there seems to be no way to unabandon if necessary).

You can abandon and then "reclaim" the revision to reopen it and continue work.

[MaskRay]

I accepted this because this seems a major showstopper and we want to resolve it for the upcoming major release
But I just recall that clang 14.0.0 has defaulted to DWARF v5 for most ELF operating systems on all architectures, including Sparc.
I think we need more justification to downgrade the DWARV version.

So far, I had only seen it with the GNU ld 2.38.50 bundled with Debian 11/sparc64, but couldn't reproduce on Ubuntu 20.04/x86_64 (neither bundled GNU ld 2.34, nor self-compiled 2.38.90)

Thanks for the additional note. Seems worth investigating whether it is an issue which should be addressed on GNU ld side.
binutils 2.39 will be released on 2022-08-06 (https://sourceware.org/pipermail/binutils/2022-July/121656.html) and such a regression style issue should be worked on quickly.
The binutils code does suggest it doesn't handle the DWARF v5 features, but I am curious why older releases don't have the problem.

[dblaikie]

I'll flag this as "request changes" so we're clear the issue isn't fully understood nor fully reproducible - so once there's some more data on the scope/impact/cause/timeline for linker fixes/etc we can access what sort of solution is suitable.

[ro]

In D130566#3682923, @dblaikie wrote:

This is all extremely weird, but until the error shows up again, I'll put this patch on hold (not yet abandoning since there seems to be no way to unabandon if necessary).

You can abandon and then "reclaim" the revision to reopen it and continue work.

Ah, I missed that: the reclaim action is only offered for abandoned patches, I assume. Thanks.

In D130566#3683174, @MaskRay wrote:

I accepted this because this seems a major showstopper and we want to resolve it for the upcoming major release
But I just recall that clang 14.0.0 has defaulted to DWARF v5 for most ELF operating systems on all architectures, including Sparc.
I think we need more justification to downgrade the DWARV version.

Fully agreed. However, clang 14.0.0 was in a way worse shape on Debian/sparc64 (wouldn't even build), so we wouldn't have noticed. Solaris/sparcv9 wouldn't notice either since it uses the native linker, not GNU ld.

So far, I had only seen it with the GNU ld 2.38.50 bundled with Debian 11/sparc64, but couldn't reproduce on Ubuntu 20.04/x86_64 (neither bundled GNU ld 2.34, nor self-compiled 2.38.90)

Thanks for the additional note. Seems worth investigating whether it is an issue which should be addressed on GNU ld side.
binutils 2.39 will be released on 2022-08-06 (https://sourceware.org/pipermail/binutils/2022-July/121656.html) and such a regression style issue should be worked on quickly.

Indeed. However, I won't be able to spend much time on this: Linux/sparc64 is only tangential to my work (as a vehicle to test SPARC patches where I want to make sure they don't break that target). I've got enough to do testing binutils 2.39 on Solaris ;-)

That said, I've now filed binutils PR binutils PR ld/29424. The binutils maintainers can now decide what the want to do about this, if anything.

The binutils code does suggest it doesn't handle the DWARF v5 features, but I am curious why older releases don't have the problem.

They might if one tried. However, the bundled GNU ld is already 2.38.50.

[ro]

Nick Clifton just commited a fix both to the binutils 2.39 branch and master. So the workaround certainly isn't necessary.

clang/lib/Driver/ToolChains/Linux.cpp

 
 ToolChain::RuntimeLibType Linux::GetDefaultRuntimeLibType() const {
   if (getTriple().isAndroid())
     return ToolChain::RLT_CompilerRT;
   return Generic_ELF::GetDefaultRuntimeLibType();
 }
 
 unsigned Linux::GetDefaultDwarfVersion() const {
-  if (getTriple().isAndroid())
+  if (getTriple().isAndroid() || getTriple().isSPARC())
     return 4;
   return ToolChain::GetDefaultDwarfVersion();
 }
 
 ToolChain::CXXStdlibType Linux::GetDefaultCXXStdlibType() const {
   if (getTriple().isAndroid())
     return ToolChain::CST_Libcxx;
   return ToolChain::CST_Libstdcxx;