profile
viewpoint
Than McIntosh thanm Google Cambridge, Massachusetts compiler guy

thanm/dragongo 15

LLVM IR generation "middle end" for LLVM-based go compiler.

thanm/go-read-a-dex 2

Toy appication written in Go to read/examine Android DEX/APK files

thanm/analyze-stacksplit 1

tool to analyze gccgo/gollvm binary stack-split prolog characteristics

thanm/cabi-testgen 1

Go test generator for C ABI handling

thanm/dwarf-check 1

DWARF checker. Looks for and reports insanities in DWARF info.

thanm/grvutils 1

graphviz utilities

thanm/CourseMaterialsFall2018 0

TEALS supplementary course materials.

thanm/devel-scripts 0

Grab-bag of python + bash development scripts

thanm/gccgo-demangler 0

Experimental demangler for gccgo mangled names

thanm/gccgo-export-dumper 0

Reads objects/archives built by gccgo, dumps export data

issue commentgolang/go

gollvm: runtime and runtime/pprof packages test failed

I'll take a look

erifan

comment created time in 3 days

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

I should add that Go 1.12.5 does not contain the release for this bug, you will need Go 1.12.7 or later.

bolenzhang

comment created time in 7 days

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

@itsmontoya the fix for this problem has been in Go1.13 since 1.13.1 -- can you please verify that you are indeed using the correct version? Several other folks have posted similarly and in each case the problem was a stale Go version. Thanks.

bolenzhang

comment created time in 7 days

issue commentgolang/go

cmd/compile: no closure inlining even in the simple case?

Setting aside the original example and looking at this one (passing function f to method E):

  • the inliner currently won't inline any function that contains a for+range loop (you can see this in the -m output, "unhandled op RANGE")

  • given that 'E' is not inlined into main, then at that point the body of E has an indirect call. The Go compiler currently only inlines direct calls; there is no special magic to analyze the program and determine the possible set of indirect call targets. In particular, in the general case this requires interprocedural analysis (build a call graph, etc).

In your second example you've replaced the indirect call with a direct call; the Go compiler has no problems with inlining those as long as the callee is small enough (and various other criteria are met).

Hope this helps.

ivoras

comment created time in 9 days

issue closedgolang/go

gollvm build fails: ‘Serializer’ is not a member of ‘llvm::remarks’

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.7 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/martins/.cache/go-build" GOENV="/home/martins/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/martins/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/lib/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build237274221=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

I followed the official instructions given here: https://go.googlesource.com/gollvm/ . Also, I had the bug with $SHELL, which I solved by setting the SHELL env variable and running commands under the new shell (/bin/sh). <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

It compiles.

What did you see instead?

sh-5.0$ ninja gollvm
[1/1200] Building CXX object tools/gollvm/driver/CMakeFiles/LLVMDriverUtils.dir/CompileGo.cpp.o
FAILED: tools/gollvm/driver/CMakeFiles/LLVMDriverUtils.dir/CompileGo.cpp.o
/usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/driver -I/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver -I/usr/include/libxml2 -Iinclude -I/home/martins/Projects/workarea/llvm-project/llvm/include -I/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go -I/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/bridge -I/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/passes -Itools/gollvm/external/install/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -g    -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/gollvm/driver/CMakeFiles/LLVMDriverUtils.dir/CompileGo.cpp.o -MF tools/gollvm/driver/CMakeFiles/LLVMDriverUtils.dir/CompileGo.cpp.o.d -o tools/gollvm/driver/CMakeFiles/LLVMDriverUtils.dir/CompileGo.cpp.o -c /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp
In file included from /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp:45:
/usr/include/llvm/IR/RemarkStreamer.h:33:28: error: ‘Serializer’ is not a member of ‘llvm::remarks’; did you mean ‘MetaSerializer’?
   33 |   std::unique_ptr<remarks::Serializer> Serializer;
      |                            ^~~~~~~~~~
      |                            MetaSerializer
/usr/include/llvm/IR/RemarkStreamer.h:33:28: error: ‘Serializer’ is not a member of ‘llvm::remarks’; did you mean ‘MetaSerializer’?
   33 |   std::unique_ptr<remarks::Serializer> Serializer;
      |                            ^~~~~~~~~~
      |                            MetaSerializer
/usr/include/llvm/IR/RemarkStreamer.h:33:38: error: template argument 1 is invalid
   33 |   std::unique_ptr<remarks::Serializer> Serializer;
      |                                      ^
/usr/include/llvm/IR/RemarkStreamer.h:33:38: error: template argument 2 is invalid
/usr/include/llvm/IR/RemarkStreamer.h:42:43: error: ‘Serializer’ is not a member of ‘llvm::remarks’; did you mean ‘MetaSerializer’?
   42 |                  std::unique_ptr<remarks::Serializer> Serializer);
      |                                           ^~~~~~~~~~
      |                                           MetaSerializer
/usr/include/llvm/IR/RemarkStreamer.h:42:43: error: ‘Serializer’ is not a member of ‘llvm::remarks’; did you mean ‘MetaSerializer’?
   42 |                  std::unique_ptr<remarks::Serializer> Serializer);
      |                                           ^~~~~~~~~~
      |                                           MetaSerializer
/usr/include/llvm/IR/RemarkStreamer.h:42:53: error: template argument 1 is invalid
   42 |                  std::unique_ptr<remarks::Serializer> Serializer);
      |                                                     ^
/usr/include/llvm/IR/RemarkStreamer.h:42:53: error: template argument 2 is invalid
/usr/include/llvm/IR/RemarkStreamer.h:48:12: error: ‘Serializer’ in namespace ‘llvm::remarks’ does not name a type; did you mean ‘MetaSerializer’?
   48 |   remarks::Serializer &getSerializer() { return *Serializer; }
      |            ^~~~~~~~~~
      |            MetaSerializer
/usr/include/llvm/IR/RemarkStreamer.h: In member function ‘llvm::raw_ostream& llvm::RemarkStreamer::getStream()’:
/usr/include/llvm/IR/RemarkStreamer.h:46:47: error: base operand of ‘->’ is not a pointer
   46 |   raw_ostream &getStream() { return Serializer->OS; }
      |                                               ^~
/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp: In member function ‘bool gollvm::driver::CompileGoImpl::setup()’:
/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp:448:16: error: ‘class llvm::LLVMContext’ has no member named ‘setRemarkStreamer’; did you mean ‘setMainRemarkStreamer’?
  448 |       context_.setRemarkStreamer(std::make_unique<llvm::RemarkStreamer>(
      |                ^~~~~~~~~~~~~~~~~
      |                setMainRemarkStreamer
In file included from /usr/include/c++/9.2.0/memory:80,
                 from /home/martins/Projects/workarea/llvm-project/llvm/include/llvm/ADT/SmallVector.h:30,
                 from /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/Tool.h:16,
                 from /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.h:1 ,
                 from /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp:13:
/usr/include/c++/9.2.0/bits/unique_ptr.h: In instantiation of ‘typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with _Tp = llvm::RemarkStreamer; _Args = {std::unique_ptr<llvm::remarks::YAMLRemarkSerializer, std::default_delete<llvm::remarks::YAMLRemarkSerializer> >, llvm::StringRef&}; typename std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<llvm::RemarkStreamer, std::default_delete<llvm::RemarkStreamer> >]’:
/home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp:452:16:   required from here
/usr/include/c++/9.2.0/bits/unique_ptr.h:849:30: error: no matching function for call to ‘llvm::RemarkStreamer::RemarkStreamer(std::unique_ptr<llvm::remarks::YAMLRemarkSerializer, std::default_delete<llvm::remarks::YAMLRemarkSerializer> >, llvm::StringRef&)’
  849 |     { return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
      |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/martins/Projects/workarea/llvm-project/llvm/tools/gollvm/driver/CompileGo.cpp:45:
/usr/include/llvm/IR/RemarkStreamer.h:41:3: note: candidate: ‘llvm::RemarkStreamer::RemarkStreamer(llvm::StringRef, int)’
   41 |   RemarkStreamer(StringRef Filename,
      |   ^~~~~~~~~~~~~~
/usr/include/llvm/IR/RemarkStreamer.h:41:28: note:   no known conversion for argument 1 from ‘std::unique_ptr<llvm::remarks::YAMLRemarkSerializer, std::default_delete<llvm::remarks::YAMLRemarkSerializer> >’ to ‘llvm::StringRef’
   41 |   RemarkStreamer(StringRef Filename,
      |                  ~~~~~~~~~~^~~~~~~~
/usr/include/llvm/IR/RemarkStreamer.h:27:7: note: candidate: ‘llvm::RemarkStreamer::RemarkStreamer(const llvm::RemarkStreamer&)’
   27 | class RemarkStreamer {
      |       ^~~~~~~~~~~~~~
/usr/include/llvm/IR/RemarkStreamer.h:27:7: note:   candidate expects 1 argument, 2 provided
/usr/include/llvm/IR/RemarkStreamer.h:27:7: note: candidate: ‘llvm::RemarkStreamer::RemarkStreamer(llvm::RemarkStreamer&&)’
/usr/include/llvm/IR/RemarkStreamer.h:27:7: note:   candidate expects 1 argument, 2 provided
ninja: build stopped: subcommand failed.

closed time in 16 days

sitilge

issue commentgolang/go

gollvm build fails: ‘Serializer’ is not a member of ‘llvm::remarks’

This should now be fixed. Please update your gollvm repo to head and sync your llvm-project monorepo to 31144351686 or later. Thanks.

sitilge

comment created time in 16 days

issue commentgolang/go

gollvm build fails: ‘Serializer’ is not a member of ‘llvm::remarks’

Thanks for the report. I'll see about sending a CL.

sitilge

comment created time in 16 days

issue commentianlancetaylor/libbacktrace

elf_add freeing strtab_view in fail, even though it shouldn't

It fails due to backtrace_get_view L77 -> file too short, size = 2884504395, got = 2147479552

The returned value seems suspicious to me -- it's 2^31 - 4096.

It is possible that the kernel is refusing to make a large mmap in this situation, e.g. https://www.kernel.org/doc/Documentation/vm/overcommit-accounting? What is /proc/sys/vm/overcommit_memory on your system (and/or CommitLimit setting in /proc/meminfo)?

MeFisto94

comment created time in a month

issue commentgolang/go

runtime: pclntab grows superlinearly

@jeremyfaller has also been brainstorming about this.

The concern I would have about such a scheme (putting on my devil's advocate hat) is that rodata can be shared across multiple instances of an executable across a given system, whereas if you go the BSS route, each process has to have it's own chunk of virtual memory.

On the other hand, it's not at all clear whether people care about that (who out there is running many instances of the same Go program on the same machine?).

robpike

comment created time in 2 months

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

OK, thanks for confirming that.

bolenzhang

comment created time in 2 months

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

Erm, @thanm the issue closed due to "waiting for info" and @xt0fer just posted a possible reproducer; I think it could be reopened.

OK, I built a fresh copy of Go from the go1.13 release branch on my macbook, downloaded github.com/kyleconroy/sqlc, did "cd cmd/sqlc; go build; ./sqlc", and I don't see this issue (I just get a usage message). Anything else that I am missing? My machine is running 10.14.6.

bolenzhang

comment created time in 2 months

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

Hi @xt0fer , this issue is closed -- if you are still seeing problems, please open a new issue, including details on how to reproduce (go version, etc). As mentioned previously this should have been fixed in Go 1.13.

bolenzhang

comment created time in 2 months

issue commentgolang/go

cmd/compile: minimize stack live set before a recursive call

A somewhat related problem comes up in the context of inlining-- say you have a program fragment like

<pre> func foo() int { largebuf := make([]byte, 8192) //... return expr }

func bar() { //... if somecondition { foo() } baz() } </pre>

In the Go compiler, if 'foo' is inlined into 'bar', the local variables in 'foo' get promoted into local variables in 'bar' (this is a fairly standard approach, but it means that inlining tends to drive up stack usage overall).

I worked on a C++ compiler back in the late 90's where at one point the inliner would insert alloca() and dealloca() operations around the body of an inlined function, e.g.

<pre> func bar() { //... if somecondition { stackpointer -= [size of foo's stack frame] ...body of foo... stackpointer += [size of foo's stack frame] } baz() } </pre>

This forced the use of a frame pointer and (as I understand it) made unwind-gen more complicated, but the back end had to support alloca() ops already, so it wasn't too bad.

These days I'm not aware of anything like this in either clang or GCC.

CAFxX

comment created time in 2 months

push eventthanm/devel-scripts

Than McIntosh

commit sha 741de9771e428c175789981a715a57df6b84aae3

Assorted changes to aliases. New script test-git-branch-stack.py based on explode-git-branch-stack.py.

view details

push time in 2 months

issue commentgolang/go

cmd/link: load of "ld -r" host object fails in -newobj mode

https://go-review.googlesource.com/c/go/+/209317 is causing some issues with the builders (missing import). I sent a fix.

thanm

comment created time in 2 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

@ianlancetaylor this is an interesting observation (makes sense). Is there a design or "reference" document anywhere that talks more about how relro is implemented?

laboger

comment created time in 2 months

issue closedgolang/go

cmd/link: inline and simplify dosymtype

Per @mwhudson's comment at https://go-review.googlesource.com/c/40864/5/src/cmd/link/internal/ld/data.go#1143.

closed time in 3 months

josharian

issue commentgolang/go

cmd/link: inline and simplify dosymtype

I've submitted https://golang.org/cl/209838 ... it might be a bit premature (given that the dev.link branch is not yet merged into master) but I'm going to close out the bug, with the expectation that we'll be doing the merge in the 1.15 timeframe.

josharian

comment created time in 3 months

issue commentgolang/go

cmd/link: inline and simplify dosymtype

These sorts of loops over ctxt.Syms.Allsym hunting for a specific symbol by name are one of the many things that we're trying to eliminate in the new linker. I'll send a CL on the dev.link branch.

josharian

comment created time in 3 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain

I agree with @mvdan , this change depends on other things in 1.13 -- don't think it would be easily back-portable to 1.12.

mvdan

comment created time in 3 months

issue commentgolang/go

gollvm: runc runtime error, broken pipe

I'll take a look... although not sure exactly when (I am a bit swamped with other work at the moment).

heylinn

comment created time in 3 months

issue commentgolang/go

cmd/link: load of "ld -r" host object fails in -newobj mode

Representative failures:

<pre> https://build.golang.org/log/98d47379c6065fd00edcd68aa384451c5deae722 elf_test.go:202: # elf_test loadelf: $WORK/b001/pkg.a(ldr.syso): malformed elf file: invalid elf symbol index </pre>

<pre> https://build.golang.org/log/ad7532a8bd9457571fe394269d7a017b82abe21e elf_test.go:202: # elf_test /tmp/gobuilder-mips64/tmp/go-build246906970/b001/pkg.a(ldr.syso): unknown relocation type 333831; compiled without -fpic? </pre>

thanm

comment created time in 3 months

IssuesEvent

issue commentgolang/go

cmd/link: load of "ld -r" host object fails in -newobj mode

The new testcase broke the MIPS builders -- reopening while I work on that.

thanm

comment created time in 3 months

issue commentgolang/go

cmd/link: load of "ld -r" host object fails in -newobj mode

@cherrymui , @jeremyfaller just as FYI

thanm

comment created time in 3 months

issue openedgolang/go

cmd/link: load of "ld -r" host object fails in -newobj mode

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +9c6f6409ad Wed Nov 20 15:16:17 2019 +0000 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Build a small program that links in a *.syso object that contains multiple static symbols that have the same name and section.

This is a bit elaborate, but here is a repro recipe: <pre> $ cat /tmp/c1.c static void blah() { } int c1() { return 42; } $ cat /tmp/c2.c static void blah() { } int c2() { return 42; } $ gcc -c -o c1.o /tmp/c1.c $ gcc -c -o c2.o /tmp/c2.c $ ld -r -o ldr.syso c1.o c2.o $ objdump -t ldr.syso | fgrep blah 0000000000000000 l F .text 0000000000000007 blah 0000000000000012 l F .text 0000000000000007 blah $ rm c1.o c2.o $ cat main.go package main func main() { } $ go build . $ go build -asmflags=all=-newobj -gcflags=all=-newobj -ldflags=-newobj .

...

loadelf: $WORK/b001/pkg.a(ldr.syso): duplicate symbol reference: blah in both main(.text) and main(.text) $ </pre>

What did you expect to see?

Clean build with -newobj.

What did you see instead?

loadelf error.

created time in 3 months

issue commentgolang/go

gollvm: invalid type conversion (type has no methods)

I will take a look.

heylinn

comment created time in 3 months

issue commentgolang/go

gollvm: undefined reference to C functions

This should be fixed now. @heylinn thanks for the bug report.

heylinn

comment created time in 3 months

issue closedgolang/go

gollvm: undefined reference to C functions

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.13 gollvm LLVM 10.0.0svn linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<pre> $ uname -m -v #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64

$ cat /etc/debian_version 9.4 </pre>

What did you do?

<pre> $ git clone https://github.com/opencontainers/runc.git $ cd runc $ mkdir -p .gopath/src/github.com/opencontainers/ $ ln -sf pwd pwd/.gopath/src/github.com/opencontainers/runc $ export GOPATH=pwd/.gopath $ cd .gopath/src/github.com/opencontainers/runc/ $ go build -tags "seccomp" -o runc . </pre>

What did you expect to see?

Clean compilation.

What did you see instead?

<pre> $ go build -tags "seccomp" -o runc .

github.com/opencontainers/runc

/home/chernik_e/work/gollvm/try20191114/runc/.gopath/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp.go:380: error: undefined reference to 'github.x2ecom..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.x2ecom..z2fseccomp..z2flibseccomp..z2dgolang._cgoCheckPointer' /home/chernik_e/work/gollvm/try20191114/runc/.gopath/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp.go:397: error: undefined reference to 'github.x2ecom..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.x2ecom..z2fseccomp..z2flibseccomp..z2dgolang._cgoCheckPointer' /home/chernik_e/work/gollvm/try20191114/runc/.gopath/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp.go:421: error: undefined reference to 'github.x2ecom..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.x2ecom..z2fseccomp..z2flibseccomp..z2dgolang._cgoCheckPointer' /home/chernik_e/work/gollvm/try20191114/runc/.gopath/src/github.com/opencontainers/runc/vendor/github.com/seccomp/libseccomp-golang/seccomp.go:555: error: undefined reference to 'github.x2ecom..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.x2ecom..z2fseccomp..z2flibseccomp..z2dgolang._cgoCheckPointer' cgo-generated-wrappers:76: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_ALLOW' cgo-generated-wrappers:77: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_ERRNO' cgo-generated-wrappers:78: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_KILL' cgo-generated-wrappers:79: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_LOG' cgo-generated-wrappers:80: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_TRACE' cgo-generated-wrappers:81: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ACT_TRAP' cgo-generated-wrappers:82: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_AARCH64' cgo-generated-wrappers:83: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_ARM' cgo-generated-wrappers:84: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_BAD' cgo-generated-wrappers:85: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPS' cgo-generated-wrappers:86: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPS64' cgo-generated-wrappers:87: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPS64N32' cgo-generated-wrappers:88: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPSEL' cgo-generated-wrappers:89: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPSEL64' cgo-generated-wrappers:90: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_MIPSEL64N32' cgo-generated-wrappers:91: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_NATIVE' cgo-generated-wrappers:92: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_PPC' cgo-generated-wrappers:93: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_PPC64' cgo-generated-wrappers:94: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_PPC64LE' cgo-generated-wrappers:95: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_S390' cgo-generated-wrappers:96: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_S390X' cgo-generated-wrappers:97: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_X32' cgo-generated-wrappers:98: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_X86' cgo-generated-wrappers:99: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ARCH_X86_64' cgo-generated-wrappers:100: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ATTRIBUTE_BADARCH' cgo-generated-wrappers:101: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ATTRIBUTE_DEFAULT' cgo-generated-wrappers:102: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ATTRIBUTE_LOG' cgo-generated-wrappers:103: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ATTRIBUTE_NNP' cgo-generated-wrappers:104: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_ATTRIBUTE_TSYNC' cgo-generated-wrappers:105: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_EQ' cgo-generated-wrappers:106: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_GE' cgo-generated-wrappers:107: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_GT' cgo-generated-wrappers:108: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_LE' cgo-generated-wrappers:109: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_LT' cgo-generated-wrappers:110: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_MASKED_EQ' cgo-generated-wrappers:111: error: undefined reference to 'github.com..z2fopencontainers..z2frunc..z2fvendor..z2fgithub.com..z2fseccomp..z2flibseccomp..z2dgolang.Cvar_C_CMP_NE' </pre>

Comment

The issue is the same as the following from 2014: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 https://gcc.gnu.org/bugzilla/attachment.cgi?id=33173

<pre> $ tar xvfz CGO_FALURE.tar.gz $ cd CGO_FALURE $ export GOPATH=pwd $ go build ./src/cgo_problem/demo.go

command-line-arguments

cgo-gccgo-export-file-prolog:27: error: undefined reference to 'cgo_problem..z2fexample.com..z2fdemo.Cgoexp_Dummy' </pre>

Workaround with renaming '.' to '_' in a package path helps to override this issue. (example.com -> example_com, github.com -> github_com) The issue is actual for runc and docker projects.

closed time in 3 months

heylinn

push eventthanm/dwarf-check

Than McIntosh

commit sha 5eedefff73848ec5903e8436b043885d1ec0d5cd

Fix up unit test.

view details

push time in 3 months

issue commentgolang/go

gollvm: undefined reference to C functions

I'll take a look.

At first blush I think maybe the fix from CL 200838 needs to be extended to cgo's gccgoPkgpathToSymbolNew() function.

heylinn

comment created time in 3 months

issue commentgolang/go

gollvm: crash llvm-goc with SIGSEGV

@heylinn Thank you for reporting this bug. I have a fix out for review.

heylinn

comment created time in 3 months

issue commentgolang/go

gollvm: crash llvm-goc with SIGSEGV

This I think is actually a front end oddity (gcc backend doesn't mind but it causes issues with gollvm).

Reduced testcase:

Package "a" <pre> package a

var Avar int

func D(_ string, _ int) (uint64, string) { return 101, "bad" } </pre>

Package "b": <pre> package b

import "a"

func F(addr string) (uint64, string) { return a.D(addr, 32) } </pre>

I will send a tentative fix shortly.

heylinn

comment created time in 3 months

issue commentgolang/go

gollvm: crash llvm-goc with SIGSEGV

I'll take a look.

heylinn

comment created time in 3 months

issue commentgolang/go

cmd/link: keep MacOS binaries compatible with Apple Notary

@andybons Are there any linker changes needed here? Let me know if I can help.

networkimprov

comment created time in 3 months

issue commentgolang/go

cmd/link: malformed mach-o image: segment __DWARF has vmsize < filesize

@bolenzhang It would be nice if we could close this bug out -- any more to do / say here?

bolenzhang

comment created time in 3 months

issue commentgolang/go

cmd/link: TestDWARF failing on windows-amd64-longtest

After taking a closer look, I am not sure whether the linker is actually doing the right thing for c-archive linkage in the first place.

The c-archive build mode is suppose to be generating a relocatable object inside an archive wrapper. However looking at the linker code, it appears to be doing essentially the same thing for c-archive that it does for a regular executable.

At ld/pe.go line 1000 it writes the optional headers for the PE. These headers include things like the image base, which I am pretty sure we don't want to be specifying if we're generating a relocatable object. For example, when you compile some C files into objects (using x86_64 Win64 mingw or equivalent), run "ld -r" on the result, then wrap the result in an archive, you definitely don't get a PE file with the optional headers (which makes sense).

A second concern: in the linux/elf case when you fire up the debug/dwarf reader on a relocatable object, it goes to significant lengths to apply relocations [or at least "enough" of the relocations] to make the DWARF comprehensible. None of this code has been written for PE as far as I can tell, which leads me to believe that having tests that verify the correctness of DWARF for windows/c-archive is a questionable exercise.

I am sure that someone (presumably someone who knows Windows well) could come along and revamp things, e.g. make sure the linker is doing the right thing, and the debug/pe code lays the groundwork for reading DWARF from relocatable PE objects, but until these things are taken care of I don't see much point in running this kind of DWARF test.

With this in mind, I am going to disable the TestDWARF linker testpoint for Windows + c-archive.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link: TestDWARF failing on windows-amd64-longtest

Well, this does look like an actual bug at this point, although I am not really all that sure what the root cause is.

The test is invoking the dwarf reader's SeekPC method, which is running through the ranges associated with each comp unit.

In the (passing non-c-archive) here's what the compilation unit DIE looks like:

<pre> <0><929bf>: Abbrev Number: 1 (DW_TAG_compile_unit) <929c0> DW_AT_name : main <929c5> DW_AT_language : 22 (Go) <929c6> DW_AT_stmt_list : 0x43f33 <929ca> DW_AT_low_pc : 0x4d1ba0 <929d2> DW_AT_ranges : 0x780 <929d6> DW_AT_comp_dir : . <929d8> DW_AT_producer : Go cmd/compile devel gomote.XXXXX <929fa> Unknown AT value: 2905: main` </pre>

and the portion of .debug_ranges pointed to looks like:

<pre> 00000780 00000000004d1ba0 00000000004d1c5a 00000780 00000000004d23e0 00000000004dc36a </pre>

This last range does indeed contain the address of main.main (0x4d7330), so SeekPC returns the correct unit.

In the c-archive case, here's the compilation unit:

<pre> <0><98d46>: Abbrev Number: 1 (DW_TAG_compile_unit) <98d47> DW_AT_name : main <98d4c> DW_AT_language : 22 (Go) <98d4d> DW_AT_stmt_list : 0x43f44 <98d51> DW_AT_low_pc : 0xd0c10 <98d59> DW_AT_ranges : 0x780 <98d5d> DW_AT_comp_dir : . <98d5f> DW_AT_producer : Go cmd/compile devel gomote.XXXXX <98d81> Unknown AT value: 2905: main </pre>

and the corresponding ranges entry looks like:

<pre> 00000780 00000000000d0c10 00000000000d0cca 00000780 00000000000d1450 00000000000db3da </pre>

The test seems to think that the address of main.main in this case is 0x4d63a0 (that's what is being reported by the internal/objfile package), however looking at the output of "objdump -t" I see a value of 0xd63a0. This is also what's being emitted into the DWARF -- here's the subprogram DIE for main.main:

<pre> <1><9a4cb>: Abbrev Number: 3 (DW_TAG_subprogram) <9a4cc> DW_AT_name : main.main <9a4d6> DW_AT_low_pc : 0xd63a0 <9a4de> DW_AT_high_pc : 0xd659f <9a4e6> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <9a4e8> DW_AT_decl_file : 0x8 <9a4ec> DW_AT_external : 1 </pre>

I think this disagreement is the source of the problem.

Also possibly of interest: had to turn off DWARF compression, since it confused the copy of objdump.exe installed on the gomote (test still fails even with -ldflags=-compressdwarf=0).

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link: TestDWARF failing on windows-amd64-longtest

I took a quick look.

Setting aside the question of whether anyone is using c-archive build mode on windows, I think the problem seems to be the use of the (relatively) new SeekPC method in the test code.

I'll send a CL to disable that part of the test for windows for the time being, and I'll see if I can figure out what the issue is. I do see some tests in debug/pe that do minimal DWARF checkout, but as far as I can tell they don't do any line table testing.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link/internal/ld: TestDynSymShInfo failure on darwin-amd64-10_11 builder

@bcmills agree, it is probably a flake. Let's wait and see if it happens again...

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link/internal/ld: TestDynSymShInfo failure on darwin-amd64-10_11 builder

Something is out of whack here -- when I try to reproduce with a gomote I get:

$ gomote run user-thanm-darwin-amd64-10_11-0 /bin/bash run-on-gomote.sh
=== RUN   TestDynSymShInfo
=== PAUSE TestDynSymShInfo
=== CONT  TestDynSymShInfo
    TestDynSymShInfo: elf_test.go:55: The system may not support ELF, skipped.
--- SKIP: TestDynSymShInfo (0.46s)

This is a little misleading -- it's not skipping the test entirely, in that it does build and link a small test program, but then once it figures out the resulting binary is not an ELF, it then invokes test.Skip.

The failure in https://build.golang.org/log/cc20f26a35ae6a2d9295873b36aa5395cf9dce87 happens before that point, however.

With that said, I ran it a couple of hundred times and didn't see any failures to link or crashes... which makes me think there is some flaky behavior going on.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link/internal/ld: TestDynSymShInfo failure on darwin-amd64-10_11 builder

Interesting; I'll take an initial look.

bcmills

comment created time in 3 months

issue commentgolang/go

plugin: test fails for debug sections on Darwin

I am working on a related bug 21647 and at this point I think I am getting close to getting this fixed. The patch I created to address the problems is: 1829590

If anyone wants to try testing it, that might be helpful. Thanks, Than

YoshikiShibata

comment created time in 3 months

issue commentgolang/go

Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements

@maj-o the intent of my post was just to show that the gccgo backend is using the same sorts of vector instructions that you would expect to see for a comparable C/C++ example compiler with "gcc -O3".

scott-boyce

comment created time in 4 months

issue commentgolang/go

Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements

Does this only apply to the C code developed for go or the go code itself?

The Go code.

https://godbolt.org/z/gRFcMy

Than

On Mon, Nov 4, 2019 at 3:00 PM Scσtt Bσyce notifications@github.com wrote:

We should certainly consider adding vectorization to the gc compiler. Note that you can already get vectorization with Go by using gccgo or GoLLVM.

Adding new types to the language is a much higher bar.

Does this only apply to the C code developed for go or the go code itself? I saw the LLVM, and put on my todo list to figure out their Fortran LLVM (mostly curious if it can complete with then private compilers, like Intel).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35307?email_source=notifications&email_token=AC5WC3AID4FOYE5RUQUC5YTQSB5NNA5CNFSM4JH4VPQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAQRQQ#issuecomment-549521602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5WC3DZOVCF3DAURO54Y5TQSB5NNANCNFSM4JH4VPQQ .

scott-boyce

comment created time in 4 months

issue commentgolang/go

runtime: "signal: segmentation fault (core dumped)" on several builders

I've done a little experimenting with this as well. My suspicion is that the problem is with the runtime's "TestSignalM" test, which is relatively recently added -- when I do repeated runs in parallel of

GOMAXPROCS=2 go test -test.v runtime -cpu=1,2,4 -quick

that's the last testpoint mentioned before the crash. On the other hand, when I run

go test -i -o runtime.test stress ./runtime.test -test.run=TestSignalM -test.cpu=10

I don't see any failures, so it's possible that my theory isn't valid.

eliasnaur

comment created time in 4 months

push eventthanm/devel-scripts

Than McIntosh

commit sha 190f7ddb6a20657836b0c21aca4ece6cb4cd1a3a

Misc.

view details

push time in 4 months

issue closedgolang/go

gccgo: go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:559

1: GCCGO

At command line I typed gccgo -v and it spits out 9.2.0

PACKAGE NAME: gcc-9.2.0-x86_64-1 - date build and installed Aug 18
PACKAGE NAME: gcc-go-9.2.0-x86_64-1 - date build and installed Aug 18
PACKAGE NAME: gcc-g++-9.2.0-x86_64-1
PACKAGE NAME: gcc-gdc-9.2.0-x86_64-1
PACKAGE NAME: gcc-gfortran-9.2.0-x86_64-1
PACKAGE NAME: gcc-gnat-9.2.0-x86_64-1
PACKAGE NAME: gcc-objc-9.2.0-x86_64-1

2: ENV

bash-5.0# go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GOPROXY=""
GORACE=""
GOROOT="/usr"
GOTMPDIR=""
GOTOOLDIR="/usr/libexec/gcc/x86_64-slackware-linux/9.2.0"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build262316847=/tmp/go-build -gno-record-gcc-switches -funwind-tables"
bash-5.0#

3: What did you do?

_/tmp/SBo/thrift-0.12.0/lib/go/thrift
go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:559
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[4]: *** [Makefile:826: all-local] Error 2
make[4]: Leaving directory '/tmp/SBo/thrift-0.12.0/lib/go'
make[3]: *** [Makefile:540: all-recursive] Error 1
make[3]: Leaving directory '/tmp/SBo/thrift-0.12.0/lib/go'
make[2]: *** [Makefile:582: all-recursive] Error 1
make[2]: Leaving directory '/tmp/SBo/thrift-0.12.0/lib'
make[1]: *** [Makefile:664: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/thrift-0.12.0'
make: *** [Makefile:578: all] Error 2
bash-5.0#

4: What did you expect to see?

PACKAGE NAME: thrift-0.12.0-x86_64-1

5: What did you see instead?

go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:559

closed time in 4 months

wmhrae

issue commentgolang/go

gccgo: go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:559

Duplicate of #33871

wmhrae

comment created time in 4 months

issue commentgolang/go

gccgo: go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:559

Thanks for filing this bug. It looks as though it was discovered independently (see issue 33871 and Ian has submitted a fix. With a tip version of gccgo I was able to successfully issue

go get github.com/apache/thrift/lib/go/thrift/...

So I am going to assume that this fixes your issue.

wmhrae

comment created time in 4 months

issue commentgolang/go

cmd/internal/obj: delete Cputime and all its uses

Ok, SGTM. I am in transit at the moment, will take a closer look tomorrow.

josharian

comment created time in 4 months

issue commentgolang/go

cmd/internal/obj: delete Cputime and all its uses

@josharian are you still interested in this CL? I can take a closer look and +2 if so.

josharian

comment created time in 4 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain [1.13 backport]

Apologies, I have been bogged down with other issues. Hope to pick this back up soon.

gopherbot

comment created time in 4 months

push eventthanm/devel-scripts

Than McIntosh

commit sha 1f4688d19d93427de3430acf477dd2c16357a1ca

Misc

view details

push time in 4 months

issue commentgolang/go

gccgo: building non-empty struct with zero-sized trailing fields failed

Thanks for reporting this. I'll take a look.

erifan

comment created time in 4 months

issue openedgolang/go

gccgo: internal error in type_index, export.cc:1265, non-local constant

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

gccgo tip <pre> $ go version go version go1.13 gccgo (GCC) 10.0.0 20191007 (experimental) linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Compile these two packages:

Package "a": <pre> package a

type AI interface { bar() }

type AC int

func (ab AC) bar() { }

const ( ACC = AC(101) ) </pre>

Package "b": <pre> package b

import "a"

func Func() a.AI { return a.ACC }

</pre>

What did you expect to see?

clean build

What did you see instead?

Compile assert of the form

<pre> go1: internal compiler error: in type_index, at go/gofrontend/export.cc:1277 0x852f05 Export::type_index(Type const*) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1277 0x852fdd Export::write_type_to(Type const*, Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1299 0x8641f3 Export_function_body::write_type(Type const*) ../../gcc-trunk/gcc/go/gofrontend/export.h:345 0x8641f3 Integer_expression::do_export(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:2531 0x85f9f1 Expression::export_expression(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.h:1059 0x85f9f1 Type_conversion_expression::do_export(Export_function_body*) const ... </pre>

This is problem very similar to issue 34577, except that in this case the constant is non-local instead of local. I think if I had been a little bit more imaginative in writing my testcase I could have caught it before.

created time in 4 months

issue commentgolang/go

x/build/cmd/gomote: 502 Bad Gateway error

New error just now:

Error running puttar: 502 Bad Gateway; body: (golang.org/issue/28365): gomote proxy error: Put http://10.240.0.16/writetgz?dir=: net/http: request canceled while waiting for connection now run: gomote run user-thanm-android-386-emu-0 /bin/bash build-on-gomote.sh Error running run: Error trying to execute /bin/bash: buildlet: HTTP status 502 Bad Gateway: (golang.org/issue/28365): gomote proxy error: Post http://10.240.0.16/exec?: net/http: request canceled while waiting for connection

hyangah

comment created time in 4 months

issue commentgolang/go

x/build/cmd/gomote: 502 Bad Gateway error

I ran into the same problem this morning. Very mysterious error.

hyangah

comment created time in 4 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain

@gopherbot Please open a backport to 1.13.

mvdan

comment created time in 4 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain

@mvdan the build should succeed.

mvdan

comment created time in 4 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain

OK, I have a tentative fix, which I will send shortly. I am wondering where would be the place to put a test for this... I will consult with the team.

mvdan

comment created time in 4 months

issue commentgolang/go

cmd/link: nil pointer dereference crash when building with an Android NDK toolchain

This appears to be related to the recent changes to the way TLS works on Android (see issue 29674).

As part of Go 1.13 we transitioned to a new TLS access sequence for Android that loads up the newly defined "runtime.tls_g" symbol. If you compile a Go source file with

GOARCH=386 GOOS=android go tool compile x.go

Here is what the prolog looks like (from go tool objdump):

  x.go:5   0x751  8b0d00000000   MOVL 0, CX          [2:6]R_ADDR:runtime.tls_g
  x.go:5   0x757  8b8900000000   MOVL 0(CX), CX      [2:6]R_TLS_LE
  x.go:5   0x75d  3b6108         CMPL 0x8(CX), SP        

Note the R_TLS_LE relocation. Here is the description from cmd/internal/objabi/reloctype.go:

	// R_TLS_LE, used on 386, amd64, and ARM, resolves to the offset of the
	// thread-local symbol from the thread local base and is used to implement the
	// "local exec" model for tls access (r.Sym is not set on intel platforms but is
	// set to a TLS symbol -- runtime.tlsg -- in the linker when externally linking).

At the point of the crash in the linker, we're trying to process an R_TLS_LE relocation on a text symbol (regular Go function), but the relocation's Xsym field is nil, so it tries to execute this line:

Errorf(s, "missing xsym in relocation %#v %#v", r.Sym.Name, s)

which faults because r.Sym is also nil. The code that ordinarily would have filled the r.Sym is here:

cmd/link/internal/ld/data.go:230

	case objabi.R_TLS_LE:
		if ctxt.LinkMode == LinkExternal && ctxt.IsELF {
			r.Done = false
			if r.Sym == nil {
				r.Sym = ctxt.Tlsg
			}
			r.Xsym = r.Sym
			r.Xadd = r.Add

however ctxt.Tlsg is now also nil due to CL 169618.

Not quite sure what the right fix is here-- as I understand it we are no longer using the "local exec" model for TLS (is this right?) in which case we should not have the R_TLS_RE in this case?

mvdan

comment created time in 4 months

issue openedgolang/go

gccgo: oddity with export data and init functions

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

gccgo tip <pre> $ go version go version go1.13 gccgo (GCC) 10.0.0 20190916 (experimental) linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Compile this package with gccgo:

<pre> package c

import "sort"

func init() { sort.Sort(byMaskLength(xpolicyTable)) }

type byMaskLength []policyTableEntry

func (s byMaskLength) Len() int { return len(s) } func (s byMaskLength) Swap(i, j int) { s[i], s[j] = s[j], s[i] } func (s byMaskLength) Less(i, j int) bool { return s[i].Label < s[j].Label }

type policyTableEntry struct { Label int }

type policyTable []policyTableEntry

var xpolicyTable = policyTable{}

//go:noinline func F() int { return xpolicyTable[0].Label } </pre>

What did you expect to see?

Expected a single entry

func F () <type -11>

in the export data for the package, since that is the only exported identifier.

What did you see instead?

Export data includes the 'byMaskLength' type and its associated methods, which was a surprise.

I poked around at this and discovered that the lowering phase is running inlinabliity analysis on init functions, and it decides as part of this that the init() function is inlinable. This means that we include the types reachable from it in the export data (even though the init function itself is not emitted as an inline candidate.

created time in 5 months

issue openedgolang/go

gccgo: internal error in type_index, export.cc:1265

What version of Go are you using (go version)?

gccgo tip <pre> $ go version go version go1.13 gccgo (GCC) 10.0.0 20190916 (experimental) linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Compile these two packages:

Package "a": <pre> package a

type A struct { x int }

//go:noinline func W(a A, k, v interface{}) A { return A{3} } </pre>

Package "b": <pre> package b

import "a"

type B struct { s string }

func (b B) Func(x a.A) a.A { return a.W(x, k, b) }

type ktype int

const k ktype = 0 </pre>

What did you expect to see?

clean compile

What did you see instead?

ICE with this stack trace:

<pre> go1: internal compiler error: in type_index, at go/gofrontend/export.cc:1265 0x8440c5 Export::type_index(Type const*) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1265 0x84419d Export::write_type_to(Type const*, Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1287 0x8553b3 Export_function_body::write_type(Type const*) ../../gcc-trunk/gcc/go/gofrontend/export.h:345 0x8553b3 Integer_expression::do_export(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:2531 0x850bb1 Expression::export_expression(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.h:1054 0x850bb1 Type_conversion_expression::do_export(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:4268 0x85bbe7 Expression::export_expression(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.h:1054 0x85bbe7 Call_expression::export_arguments(Export_function_body*) const ../../gcc-trunk/gcc/go/gofrontend/expressions.cc:12398 0x88e96c Statement::export_statement(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/statements.h:340 0x88e96c Block::export_block(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6932 0x8d8f36 Block_statement::export_block(Export_function_body*, Block*, bool) ../../gcc-trunk/gcc/go/gofrontend/statements.cc:2155 0x88e96c Statement::export_statement(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/statements.h:340 0x88e96c Block::export_block(Export_function_body*) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:6932 0x89a8de Function::export_func_with_type(Export*, Named_object const*, Function_type const*, std::vector<Named_object*, std::allocator<Named_object*> >, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Block, Location) ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5987 0x89aed8 Function::export_func(Export*, Named_object const*) const ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:5841 0x89afa3 Named_object::export_named_object(Export*) const ../../gcc-trunk/gcc/go/gofrontend/gogo.cc:8573 0x8e6efa Named_type::do_export(Export*) const ../../gcc-trunk/gcc/go/gofrontend/types.cc:11132 0x84190a Type::export_type(Export*) const ../../gcc-trunk/gcc/go/gofrontend/types.h:1076 0x84190a Export::write_type_definition(Type const*, int) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1206 0x841b8f Export::write_types(int) ../../gcc-trunk/gcc/go/gofrontend/export.cc:1143 </pre>

It looks as though the issue is with the constant, which is not getting picked up properly by the exporter.

Still working on a fix.

created time in 5 months

issue closedgolang/go

cmd/compile, cmd/link: remove use of Automs

This is a tracking issue/bug for a modest compiler/linker enhancement involving DWARF type generation.

Background / motivation

Consider the following Go program:

<pre> package main

type astruct struct { a, b int } type bstruct struct { c, d byte }

func dead() { var iface = []bstruct{} println(iface)

}

func main() { var iface interface{} = map[string]astruct{} println(iface) } </pre>

We have two functions, "dead" and "main". The main function is obviously useful, but the function 'dead' is uncalled, and will be eliminated by the linker's dead code elimination phase.

When generating DWARF for 'main', we would like to insure that the types used by main are included, that is, that we emit DWARF DIEs for each interesting type. The tricky part here is that there are no variables (autos or parameters) in main that refer to types like astruct or map[string]astruct, which means that these types are also vulnerable to linker deadcode.

The compiler and linker currently handle this via a construct known as an "Autom"; the compiler emits an Autom record for each auto-tmp variable used by the function; these autom's get placed into the object file entry for the function. In the case of 'main' above, the compiler-generated temp var used to construct the value map[string]astruct{} triggers generation of an Autom.

The linker then reads in autom's when it reads the object file, and later on during linker processing it walks the Autom's for each live (non-dead-coded) function and generates a DWARF type DIE for its type if needed.

Note that for the example program above, we'll get type information for astruct (via the autom mechanism) but not for bstruct, since that type is not referenced by any live function.

Proposed change

What the section above leaves out is that the autom mechanism is cumbersome and heavyweight -- Autom's in the object file have a lot more information than strictly needed (this has happened gradually over time due to more DWARF generation moving from the compiler to the linker). This results in object file bloat and extra processing time in the linker.

What would work equally well is to attach dummy relocations to each function symbol that record the Go types used by its associated autotmps, then use these relocations to drive the DWARF type generation. This would speed up the compiler and linker and reduce object file size.

Issues/caveats/problem

There is a small chunk of code in the linker specific to the Plan9 target that does processing of Autom's to create directives or symbols for Autom's in the Plan9 object file. It's hard to tell from the code whether this is at all useful, since we haven't been able to find someone who knows how to run the Plan9 debugger. Given the current usage of autom's (e.g. for non-user-visible variables) it seems unlikely that removing the Plan9 autom handling will cause any debugging issues, so the proposal is to just drop this code.

closed time in 5 months

thanm

issue commentgolang/go

cmd/compile, cmd/link: remove use of Automs

If they are necessary, wouldn't it be better to make the relocations attached to the function DIEs cause the types to be included?

This might be a good idea. The advantage of putting them on the function symbol itself is that there are no changes needed to dead code elimination; if I put them on the subprogram DIE then I'd have to add special processing. With that said, it would be easy to do.

thanm

comment created time in 5 months

issue commentgolang/go

cmd/compile, cmd/link: remove use of Automs

@aclements The example I posted illustrates:

<pre> func main() { var iface interface{} = map[string]astruct{} println(iface) } </pre

There is no place in main's subrogram DIE to hang a type reference, since we never actually declare a named variable (parameter or auto) that has the type of interest (astruct or equivalent). So yes, if we want to preserve the current compiler/linker behavior we need the dummy relocations.

I did also as an experiment try running all.bash after hacking the linker to ignore autom's completely. When I did this I got a failure in the runtime's gdb test (TestGdbAutotmpTypes).

thanm

comment created time in 5 months

issue openedgolang/go

cmd/compile, cmd/link: remove use of Automs

This is a tracking issue/bug for a modest compiler/linker enhancement involving DWARF type generation.

Background / motivation

Consider the following Go program:

<pre> package main

type astruct struct { a, b int } type bstruct struct { c, d byte }

func dead() { var iface = []bstruct{} println(iface)

}

func main() { var iface interface{} = map[string]astruct{} println(iface) } <pre>

We have two functions, "dead" and "main". The main function is obviously useful, but the function 'dead' is uncalled, and will be eliminated by the linker's dead code elimination phase.

When generating DWARF for 'main', we would like to insure that the types used by main are included, that is, that we emit DWARF DIEs for each interesting type. The tricky part here is that there are no variables (autos or parameters) in main that refer to types like astruct or map[string]astruct, which means that these types are also vulnerable to linker deadcode.

The compiler and linker currently handle this via a construct known as an "Autom"; the compiler emits an Autom record for each auto-tmp variable used by the function; these autom's get placed into the object file entry for the function. In the case of 'main' above, the compiler-generated temp var used to construct the value map[string]astruct{} triggers generation of an Autom.

The linker then reads in autom's when it reads the object file, and later on during linker processing it walks the Autom's for each live (non-dead-coded) function and generates a DWARF type DIE for its type if needed.

Note that for the example program above, we'll get type information for astruct (via the autom mechanism) but not for bstruct, since that type is not referenced by any live function.

Proposed change

What the section above leaves out is that the autom mechanism is cumbersome and heavyweight -- Autom's in the object file have a lot more information than strictly needed (this has happened gradually over time due to more DWARF generation moving from the compiler to the linker). This results in object file bloat and extra processing time in the linker.

What would work equally well is to attach dummy relocations to each function symbol that record the Go types used by its associated autotmps, then use these relocations to drive the DWARF type generation. This would speed up the compiler and linker and reduce object file size.

created time in 5 months

issue openedgolang/go

gccgo: incorrectly imported call/deref sequence in inlinable function

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

gccgo tip

<pre> $ go version go version go1.13 gccgo (GCC) 10.0.0 20190916 (experimental) linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Compile these two packages:

Package "b": <pre> package b

import ( "sync/atomic" "unsafe" )

type HookFunc func(x uint64)

var HookV unsafe.Pointer

func Hook(x uint64) { if hkf := atomic.LoadPointer(&HookV); hkf != nil { (*(*HookFunc)(hkf))(x) } } </pre>

Package "c": <pre> package c

import "b"

func Cfunc() { b.Hook(101) } </pre>

Then build first b and then c.

What did you expect to see?

clean compile

What did you see instead?

<pre> $ go build c <GOPATH>/src/b/b.go:18: error: expected function <GOPATH>/src/b/b.go:18: error: expected pointer $ </pre>

I spent a little while poking at this and I believe that the problem is with the exporter/importer for inlinable function bodies. Here's what the inlinable function "Hook" looks like in the export data:

<pre> func Hook (x <type -8>) inl:165 // /ssd2/go1/src/b/b.go:16 { //17 var hkf <type 2> = <p1>LoadPointer(&HookV) //17 if (hkf != $nil) { //17 *$convert(<type 5>, hkf)(x) //18 } //17 } //19 </pre>

For the expression on line 18, when compiling the original code in package "b", the IR looks like

call(fn=deref(convert(var(hkf))), val=var(x))

or from the debugger:

(gdb) p debug_go_statement(this) *((hkf) (x) ) // b.go:18

whereas when trying to lower the inlined copy of the routine while compiling package "c", we get:

deref(call(fn=convert(var(hkf)), val=var(x)))

or from the debugger:

(gdb) p debug_go_statement(this) *((hkf) ) (x) // b.go:18

Off the top of my head I would guess that this is a precedence problem in the importer's parser. I'll look into a fix of some sort.

created time in 5 months

issue commentgolang/go

cmd/link: nil pointer dereference

Many programming tools expose features to make life easier for the developers of those tools. Consider GDB's "maintenance info program-spaces" command, or GCC's "-fdump-tree-all-all" command line options -- yes, they are exposed, but it's not expected that they be used by anyone other than developers of GCC or GDB. The go tool commands fall into the same category.

Regarding the crash on a weird combination of options -- this is surely a bug of some sort... would you like to send a patch?

meme

comment created time in 5 months

push eventthanm/devel-scripts

Than McIntosh

commit sha d56362ba370c924bc1b59ce3de8c67a5ff18bc36

Misc.

view details

push time in 5 months

issue commentgolang/go

x/build/cmd/gopherbot: opt-out from automatically adding reviewers

At the moment with gerrit if you mark a change WIP, you can't kick off the trybots (instead of the usual "reply" button you get a "start review" button). Example:

Screenshot from 2019-09-18 09-26-34

mdempsky

comment created time in 5 months

issue commentgolang/go

cmd/link: TestDWARF failing under all.bash on OSX 10.13.6

@timothyham Is this issue still causing problems for you -- can it be closed out?

timothyham

comment created time in 5 months

issue commentgolang/go

cmd/link: testDWARF in c-archive mode fails on Linux (but not Darwin)

I think the culprit is here?

<pre> if SymType(sym.Info&0xf) != STT_SECTION { // We don't handle non-section relocations for now. continue } </pre>

Here's the compilation unit DIE as reported by objdump:

<pre> <0><97235>: Abbrev Number: 1 (DW_TAG_compile_unit) <97236> DW_AT_name : main <9723b> DW_AT_language : 22 (Go) <9723c> DW_AT_stmt_list : 0x33790 <97240> DW_AT_low_pc : 0xb80c0 <97248> DW_AT_ranges : 0x490 <9724c> DW_AT_comp_dir : . <9724e> DW_AT_producer : Go cmd/compile devel +49e7c7672d Mon Sep 16 11:56:15 2019 +0000; -shared <97297> Unknown AT value: 2905: main </pre>

The relocations for that section of the .debug_info look like:

<pre> 000000097230 00020000000a R_X86_64_32 0000000000000000 .debug_abbrev + 0 00000009723c 00030000000a R_X86_64_32 0000000000000000 .debug_line + 33790 000000097240 0fcf00000001 R_X86_64_64 00000000000b80c0 type..eq.[2]interface + 0 000000097248 00060000000a R_X86_64_32 0000000000000000 .debug_ranges + 490 </pre>

Note the third relocation -- the symbol this relocation targets is not a section, so that would explain how things are going wrong. So the problem is not that there are no relocations being applied, it's that not quite enough of them are being applied. This doesn't really explain why the test works on Darwin, however (maybe MachO relocations work differently?).

eliasnaur

comment created time in 5 months

issue commentgolang/go

cmd/link: testDWARF in c-archive mode fails on Linux (but not Darwin)

Well now, I stand corrected (having talked this over with Austin). Turns out that debug/elf actually does apply relocations when reading section data to feed into the DWARF reader. So it looks as though the problem may be elsewhere. I will take another look...

eliasnaur

comment created time in 5 months

issue commentgolang/go

cmd/link: testDWARF in c-archive mode fails on Linux (but not Darwin)

I spent a little while looking at this problem.

From what I can tell the issue is that our current debug/dwarf reader doesn't support operating on relocatable objects. What this means is that when it goes to read in the contents of things like the .debug_ranges section, it will see a pre-relocation version of the LO/HI PC values, as opposed to the final cooked/relocated value. This is not really so much a bug as it is an implementation shortcoming. The reason that the test works on Darwin is that we are (apparently) emitting fewer relocations.

Some more detail:

I hacked the dwarf.Reader.SeekPC method to print out the contents of the ranges it sees as it tries to locate the compile unit containing the address of interest. When I do this on Linux I see

<pre> examining range [0x0,0xdb9] examining range [0x0,0x5e] examining range [0x0,0x8a7] examining range [0x0,0x5980a] examining range [0x0,0x165] ... </pre>

This makes sense, since the .debug_ranges section is in an unrelocated state:

<pre> /tmp/go-link-TestDWARF501471370$ objdump -r go.o |
fgrep 'RELOCATION RECORDS' | fgrep .debug RELOCATION RECORDS FOR [.debug_line]: RELOCATION RECORDS FOR [.debug_frame]: RELOCATION RECORDS FOR [.debug_pubnames]: RELOCATION RECORDS FOR [.debug_pubtypes]: RELOCATION RECORDS FOR [.debug_info]: RELOCATION RECORDS FOR [.debug_loc]: RELOCATION RECORDS FOR [.debug_ranges]: </pre>

If I do the same thing on Darwin, here's what I see for relocations:

<pre> go-link-TestDWARF386711118 thanm$ gobjdump -r go.o |
fgrep 'RELOCATION RECORDS' | fgrep .debug RELOCATION RECORDS FOR [.debug_line]: RELOCATION RECORDS FOR [.debug_frame]: RELOCATION RECORDS FOR [.debug_info]: </pre>

Note the lack of .debug_ranges relocations. I think the reason for the discrepancy is https://go-review.googlesource.com/c/go/+/171158, also understandable.

As for what to do about this, I'm unsure at this point (need to consult with other folks).

If the goal of the test is just to verify DWARF generation, then I think perhaps the thing to do would be to do an actual link with the result of the -buildmode=c-archive object, so that the relocations are resolved.

eliasnaur

comment created time in 5 months

issue commentgolang/go

cmd/link: nil pointer dereference

I think it is safe to say that that users are expected to build their code "go build" as opposed to raw "go tool compile" and "go tool link" invocations (unlike, say, a C compiler, where you can do just fine with a strategy like "cc -c myfile.c ; cc -o myprog myfile.o").

There may have been a time many releases ago when you could get by on just "go tool compile" and "go tool link", but those days are gone at this point -- the Go command does a lot of careful orchestration of the compiler and linker options depending on what and how you are building. You can see this in action by looking at the output of "go build -x -buildmode=... ...".

meme

comment created time in 5 months

issue commentgolang/go

cmd/link: nil pointer dereference

When I do a build of your code using the "go" command (as opposed to raw 'go tool compile' and 'go tool link' invocations), it seems to work fine:

<pre> $ go build -o tiny -buildmode=plugin tiny.go $ </pre>

When I run the same build using "-x" I can see that the Go command is using a number of other important compiler and linker flags needed for the plugin to work (for example, the '-dynlink' compiler option, which would seem to be mandatory given how plugins are supposed to be used).

Is there a reason why you're not using these options in your 'go tool compile/link' invocations? Thanks.

meme

comment created time in 5 months

issue commentgolang/go

cmd/compile: can't break on inlined function

Duplicate of #26206.

aclements

comment created time in 5 months

issue commentgolang/go

cmd/compile: debug info for inlined funcs are sometimes lost

Moving this issue from 1.14 to unplanned (please move it back if you object).

hyangah

comment created time in 5 months

issue commentgolang/go

cmd/compile: debug info for inlined funcs are sometimes lost

I took another look at this testcase with a recent compiler (Go 1.13 / tip). Problem is still there.

As Keith says, all traces of the function in question are being optimized away -- unless there is some instruction somewhere with a "Pos" that originated in the inlined routine (and in this case we don't, they are all folded away), you don't get a record of the inline in the DWARF.

For grins I rewrote the testcase in C and compiled it with recent versions of clang and gcc. Code:

<pre> #include <stdio.h> #include <string.h>

typedef struct { int Foo; } X;

static inline int InlineThis(X *x, char *s) { int y = strlen(s) + x->Foo; return y; }

int main() { X x; x.Foo = 10; int y = InlineThis(&x, "bar"); printf("%d\n", y); } </pre>

With clang there is also no trace of InlineThis, e.g. it does essentially the same thing as the Go compiler. With gcc there is at least a record of the inline, and it has (heroically) tried to capture the values of the parameters at the callsite:

<pre> <2><342>: Abbrev Number: 22 (DW_TAG_GNU_call_site) <343> DW_AT_low_pc : 0x1a <34b> DW_AT_abstract_origin: <0x399> <3><34f>: Abbrev Number: 23 (DW_TAG_GNU_call_site_parameter) <350> DW_AT_location : 1 byte block: 55 (DW_OP_reg5 (rdi)) <352> DW_AT_GNU_call_site_value: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) <3><35c>: Abbrev Number: 23 (DW_TAG_GNU_call_site_parameter) <35d> DW_AT_location : 1 byte block: 54 (DW_OP_reg4 (rsi)) <35f> DW_AT_GNU_call_site_value: 1 byte block: 3d (DW_OP_lit13) <3><361>: Abbrev Number: 0 </pre>

however according to the DWARF above the callsite is being attributed to an instruction after the call to printf (oops) and the values of the call site parameters look pretty sketchy too (it says that we's passing a zero to InlineThis which doesn't look right).

My own feeling: not sure it is really worth while trying to support this case, or even if it is a good idea at all, given the added complexity that would be needed in the compiler, and given that other comparable compilers (with more resources than Go) aren't handling it.

hyangah

comment created time in 5 months

issue commentgolang/go

cmd/compile: reduce binary bloat for slice literals of interfaces

Drive-by comment: I note that when compiling with tip, the generated code looks better (no longer includes write barriers):

"".makeLiteral STEXT size=304 args=0x18 locals=0x18 0x0000 00000 (issue29573.go:8) TEXT "".MakeLiteral(SB), ABIInternal, $24-24 0x0000 00000 (issue29573.go:8) MOVQ (TLS), CX 0x0009 00009 (issue29573.go:8) CMPQ SP, 16(CX) 0x000d 00013 (issue29573.go:8) JLS 294 0x0013 00019 (issue29573.go:8) SUBQ $24, SP 0x0017 00023 (issue29573.go:8) MOVQ BP, 16(SP) 0x001c 00028 (issue29573.go:8) LEAQ 16(SP), BP 0x0021 00033 (issue29573.go:8) FUNCDATA $0, gclocals·9fb7f0986f647f17cb53dda1484e0f7a(SB) 0x0021 00033 (issue29573.go:8) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x0021 00033 (issue29573.go:8) FUNCDATA $2, gclocals·bfec7e55b3f043d1941c093912808913(SB) 0x0021 00033 (issue29573.go:9) PCDATA $0, $1 0x0021 00033 (issue29573.go:9) PCDATA $1, $0 0x0021 00033 (issue29573.go:9) LEAQ type.[10]interface {}(SB), AX 0x0028 00040 (issue29573.go:9) PCDATA $0, $0 0x0028 00040 (issue29573.go:9) MOVQ AX, (SP) 0x002c 00044 (issue29573.go:9) CALL runtime.newobject(SB) 0x0031 00049 (issue29573.go:9) PCDATA $0, $1 0x0031 00049 (issue29573.go:9) MOVQ 8(SP), AX 0x0036 00054 (issue29573.go:10) PCDATA $0, $2 0x0036 00054 (issue29573.go:10) LEAQ type.uint32(SB), CX 0x003d 00061 (issue29573.go:10) PCDATA $0, $1 0x003d 00061 (issue29573.go:10) MOVQ CX, (AX) 0x0040 00064 (issue29573.go:10) PCDATA $0, $2 0x0040 00064 (issue29573.go:10) LEAQ ""..stmp_0(SB), CX 0x0047 00071 (issue29573.go:10) PCDATA $0, $1 0x0047 00071 (issue29573.go:10) MOVQ CX, 8(AX) 0x004b 00075 (issue29573.go:11) PCDATA $0, $2 0x004b 00075 (issue29573.go:11) LEAQ type.archive/tar.Format(SB), CX 0x0052 00082 (issue29573.go:11) PCDATA $0, $1 0x0052 00082 (issue29573.go:11) MOVQ CX, 16(AX) 0x0056 00086 (issue29573.go:11) PCDATA $0, $2 0x0056 00086 (issue29573.go:11) LEAQ ""..stmp_1(SB), CX 0x005d 00093 (issue29573.go:11) PCDATA $0, $1 0x005d 00093 (issue29573.go:11) MOVQ CX, 24(AX) 0x0061 00097 (issue29573.go:12) PCDATA $0, $2 0x0061 00097 (issue29573.go:12) LEAQ type.*archive/tar.Header(SB), CX 0x0068 00104 (issue29573.go:12) PCDATA $0, $1 0x0068 00104 (issue29573.go:12) MOVQ CX, 32(AX) 0x006c 00108 (issue29573.go:12) MOVQ $0, 40(AX) 0x0074 00116 (issue29573.go:13) PCDATA $0, $2 0x0074 00116 (issue29573.go:13) LEAQ type.*archive/tar.Reader(SB), CX 0x007b 00123 (issue29573.go:13) PCDATA $0, $1 0x007b 00123 (issue29573.go:13) MOVQ CX, 48(AX) 0x007f 00127 (issue29573.go:13) MOVQ $0, 56(AX) 0x0087 00135 (issue29573.go:14) PCDATA $0, $2 0x0087 00135 (issue29573.go:14) LEAQ type.*archive/tar.Writer(SB), CX 0x008e 00142 (issue29573.go:14) PCDATA $0, $1 0x008e 00142 (issue29573.go:14) MOVQ CX, 64(AX) 0x0092 00146 (issue29573.go:14) MOVQ $0, 72(AX) 0x009a 00154 (issue29573.go:15) PCDATA $0, $2 0x009a 00154 (issue29573.go:15) LEAQ type.*archive/zip.File(SB), CX 0x00a1 00161 (issue29573.go:15) PCDATA $0, $1 0x00a1 00161 (issue29573.go:15) MOVQ CX, 80(AX) 0x00a5 00165 (issue29573.go:15) MOVQ $0, 88(AX) 0x00ad 00173 (issue29573.go:16) PCDATA $0, $2 0x00ad 00173 (issue29573.go:16) LEAQ type.*archive/zip.FileHeader(SB), CX 0x00b4 00180 (issue29573.go:16) PCDATA $0, $1 0x00b4 00180 (issue29573.go:16) MOVQ CX, 96(AX) 0x00b8 00184 (issue29573.go:16) MOVQ $0, 104(AX) 0x00c0 00192 (issue29573.go:17) PCDATA $0, $2 0x00c0 00192 (issue29573.go:17) LEAQ type.*archive/zip.ReadCloser(SB), CX 0x00c7 00199 (issue29573.go:17) PCDATA $0, $1 0x00c7 00199 (issue29573.go:17) MOVQ CX, 112(AX) 0x00cb 00203 (issue29573.go:17) MOVQ $0, 120(AX) 0x00d3 00211 (issue29573.go:18) PCDATA $0, $2 0x00d3 00211 (issue29573.go:18) LEAQ type.*archive/zip.Reader(SB), CX 0x00da 00218 (issue29573.go:18) PCDATA $0, $1 0x00da 00218 (issue29573.go:18) MOVQ CX, 128(AX) 0x00e1 00225 (issue29573.go:18) MOVQ $0, 136(AX) 0x00ec 00236 (issue29573.go:19) PCDATA $0, $2 0x00ec 00236 (issue29573.go:19) LEAQ type.*archive/zip.Writer(SB), CX 0x00f3 00243 (issue29573.go:19) PCDATA $0, $1 0x00f3 00243 (issue29573.go:19) MOVQ CX, 144(AX) 0x00fa 00250 (issue29573.go:19) MOVQ $0, 152(AX) 0x0105 00261 (issue29573.go:9) PCDATA $0, $0 0x0105 00261 (issue29573.go:9) PCDATA $1, $1 0x0105 00261 (issue29573.go:9) MOVQ AX, "".~r0+32(SP) 0x010a 00266 (issue29573.go:9) MOVQ $10, "".~r0+40(SP) 0x0113 00275 (issue29573.go:9) MOVQ $10, "".~r0+48(SP) 0x011c 00284 (issue29573.go:9) MOVQ 16(SP), BP 0x0121 00289 (issue29573.go:9) ADDQ $24, SP 0x0125 00293 (issue29573.go:9) RET 0x0126 00294 (issue29573.go:9) NOP 0x0126 00294 (issue29573.go:8) PCDATA $1, $-1 0x0126 00294 (issue29573.go:8) PCDATA $0, $-1 0x0126 00294 (issue29573.go:8) CALL runtime.morestack_noctxt(SB) 0x012b 00299 (issue29573.go:8) JMP 0

Can this bug be closed out as a result?

dsnet

comment created time in 5 months

issue closedgolang/go

debug/elf: decoding dwarf section abbrev at offset 0x13: cannot determine class of unknown attribute form

What version of Go are you using (go version)?

<pre> $ go version go version go1.12.7 windows/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\xxx\AppData\Local\go-build set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=c:\xxx\go set GOPROXY= set GORACE= set GOROOT=C:\Go set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\xxx\AppData\Local\Temp\go-build858273874=/tmp/go-build -gno-record-gcc-switches </pre></details>

What did you do?

I am trying to parse debug info of an embedded binary (ARM / Cortex) generated by Keil uVision.

What did you expect to see?

Be able to call DWARF() on the file without error.

What did you see instead?

Loading the file _elf, err := elf.Open(os.Args[1]) and calling _elf.DWARF() on it results in following error: decoding dwarf section abbrev at offset 0x13: cannot determine class of unknown attribute form

This error seems to originated from debug/dwarf/entry.go with (in my case) form being formIndirect.

At somewhat similar issue and change is described here: https://go-review.googlesource.com/c/go/+/14541/2/src/debug/dwarf/entry.go and I can returning ClassUnknown for formIndirect does help get some of the parsing done, but I missing crucial pieces of the dwarf section (i.e. the members of a struct I care for seem to get skipped altogether).

As I am new to all of this I'd be thankful any comments on whether I have a funamental misunderstanding of purpose of the elf package (i.e. "was never meant to worked with embedded binariers") or whether there's something else I could besides deep diving into the issue and creating a pull request.

closed time in 5 months

g4w

issue commentgolang/go

debug/elf: decoding dwarf section abbrev at offset 0x13: cannot determine class of unknown attribute form

I am going to close this bug, please re-open if you see fit. Thanks.

g4w

comment created time in 5 months

push eventthanm/dwarf-check

Than McIntosh

commit sha 9e153d09095fe480022edc20920db00183e1eb93

dwarf-check: add feature to dump GNU build id New command line option to dump build ID from ELF binaries.

view details

push time in 5 months

more