cgo: malformed DWARF TagVariable entry #53000
Comments
mknyszek
added
the
NeedsInvestigation
|
I looked over the Phabricator change. It appears that the main goal is to emit DWARF entries for constant strings, e.g. if you do something like
clang will now emit a DW_TAG_variable DIE for the string constant "foo" (including type and source line, etc). This is so that if the string constant is involves somehow with an ASAN error, ASAN can report its source location. The business about having a DW_TAG_variable DIE without a name seems to be mostly that they want to save space in the DWARF (no name => DWARF gets smaller). My 2 cents: while I am sure this is legal DWARF according to the standard, this is going to lead to a never-ending stream of weird bugs and errors from downstream DWARF consumers that are all written to assume that variable DIEs have names (as in the case for cgo). Should be easy to fix however; we can just teach CGO to ignore nameless variables. I'll look into that. |
|
@ilovepi could you possibly let me know the specific C compiler command line options for your failing build? Clang has a number of different options/flavors/settings, it would be good to know which one triggers this. |
|
@thanm I already have a quick fix out https://go-review.googlesource.com/c/go/+/406816 |
|
Well I'm not 100% sure this is super helpful. There aren't really any exotic flags we're passing but maybe this will help you. I'm leaving everything in for compleness, but the majority are simply include directories. |
|
Change https://go.dev/cl/406816 mentions this issue: |
dmitshur
added
NeedsFix
|
@gopherbot please backport to 1.18. |
|
Backport issue(s) opened: #57044 (for 1.18). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
^^ to add some context: We started running into this issue after the official docker golang alpine image updated to alpine 3.17, which comes with a newer version of clang (see moby/moby#44570); With alpine 3.16: docker run -it --rm golang:1.18.8-alpine3.16 sh -c 'apk add --quiet --no-cache clang && clang --version'
Alpine clang version 13.0.1
Target: aarch64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/binWith alpine 3.17: docker run -it --rm golang:1.18.8-alpine3.17 sh -c 'apk add --quiet --no-cache clang && clang --version'
Alpine clang version 15.0.6
Target: aarch64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/binIf you have docker installed, the issue can be reproduced with this Dockerfile; ARG ALPINE_VERSION
FROM golang:1.18.8-alpine${ALPINE_VERSION} AS golatest
RUN apk add --no-cache clang lld git musl-dev gcc
WORKDIR /containerd
RUN set -ex \
&& git clone https://github.com/containerd/containerd.git . \
&& git fetch origin \
&& git checkout -q v1.5.11 \
&& CGO_ENABLED=1 CC=clang go build -tags no_btrfs ./cmd/containerdWith alpine 3.16 (clang 13), it passes; docker build -t example --build-arg ALPINE_VERSION=3.16 .
...And with alpine 3.17 (clang 15), it fails: docker build -t example --build-arg ALPINE_VERSION=3.17 .
...
> [4/4] RUN set -ex && git clone https://github.com/containerd/containerd.git . && git fetch origin && git checkout -q v1.5.11 && CGO_ENABLED=1 CC=clang go build -tags no_btrfs ./cmd/containerd:
#8 0.261 + git clone https://github.com/containerd/containerd.git .
#8 0.271 Cloning into '.'...
#8 15.91 + git fetch origin
#8 16.44 + git checkout -q v1.5.11
#8 17.02 + CGO_ENABLED=1 CC=clang go build -tags no_btrfs ./cmd/containerd
#8 28.33 # github.com/miekg/pkcs11
#8 28.33 cgo: malformed DWARF TagVariable entry
------
process "/bin/sh -c set -ex && git clone https://github.com/containerd/containerd.git . && git fetch origin && git checkout -q v1.5.11 && CGO_ENABLED=1 CC=clang go build -tags no_btrfs ./cmd/containerd" did not complete successfully: exit code: 2We noticed that #53013 (https://go.dev/cl/454415 ) was accepted to be backported, which seems related, so we would like to request https://go.dev/cl/406816 to be backported as well. |
https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's that don't have a DW_AT_name. This is allowed in the DWARF standard. It is adding DIE's for string literals for better symbolization on buffer overlows etc on these strings. They no associated name because they are not user provided variables. Fixes golang#57044 Updates golang#53000 Change-Id: I2cf063160508687067c7672cef0517bccd707d7b Reviewed-on: https://go-review.googlesource.com/c/go/+/406816 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit e66f895)
|
Change https://go.dev/cl/455055 mentions this issue: |
|
Change https://go.dev/cl/455056 mentions this issue: |
https://reviews.llvm.org/D123534 is emitting DW_TAG_variable's that don't have a DW_AT_name. This is allowed in the DWARF standard. It is adding DIE's for string literals for better symbolization on buffer overlows etc on these strings. They no associated name because they are not user provided variables. Fixes #57044 Updates #53000 Change-Id: I2cf063160508687067c7672cef0517bccd707d7b Reviewed-on: https://go-review.googlesource.com/c/go/+/406816 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit e66f895) Change-Id: I2cf063160508687067c7672cef0517bccd707d7b GitHub-Last-Rev: 32208e4 GitHub-Pull-Request: #57067 Reviewed-on: https://go-review.googlesource.com/c/go/+/455055 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
When building Fuchsia we ran into a build error from
cgofrom malformed DWARF tags.What did you expect to see?
I expected the build to complete without error
What did you see instead?
build failure
Fuchsia compiles using ToT LLVM. Recently, LLVM has made some changes to some of the DWARF it emits. In particular, the new change emits debug info for variables it didn't previously, and cgo fails when it encounters a
DW_TAG_variablethat doesn't have a name, which is allowed by the DWARF standard.Since this is legal in DWARF, the compiler should be able to handle the change to debug info.
You can find our failed build at: https://luci-milo.appspot.com/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.arm64-debug/b8813791771110373825/overview
Unfortunately, I don't have a smaller reproducer. But this should become more common as other consumers of LLVM update their toolchains.
There is an ongoing discussion on the original change on Phabricator you can find here: https://reviews.llvm.org/D123534
The text was updated successfully, but these errors were encountered: