Compiling the package crypto/secp256k1 from the go-ethereum package yields the error message "malformed DWARF TagVariable entry" from cgo. Maybe it does not yet know about the latest changes to debug information in Gcc? I know this report is very terse; if a code example is necessary to debug or fix this issue, just give me a shout and I'll see what I can do next week. (Gcc sources checked out at 25th of Septermber, 2015.)
It seems that the DWARF library is unable to handle DW_AT_specification: -- snip -- <1><7b4>: Abbrev Number: 27 (DW_TAG_variable) <7b5> DW_AT_specification: <0x8b> <7b9> DW_AT_decl_file : 13 <7ba> DW_AT_decl_line : 77 <7bb> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 4 80 (DW_OP_addr: 480) <1><8b>: Abbrev Number: 10 (DW_TAG_variable) <8c> DW_AT_name : (indirect string, offset: 0x3c4): secp256k1_nonce_function_rfc6979 <90> DW_AT_decl_file : 14 <91> DW_AT_decl_line : 104 <92> DW_AT_type : <0x98> <96> DW_AT_external : 1 <97> DW_AT_declaration : 1 -- snip -- DW_AT_name and DW_AT_type are provided by the DW_TAG_variable that the DW_AT_specification attribute is pointing to. Is that a known problem; ist there already a fix? Otherwise I can try to make a patch.
This is not a known bug. I wonder what is special about this package that it causes it to happen? I don't see anything new in GCC related to DW_AT_specification. I think the place to fix in the Go sources would be cmd/cgo/gcc.go.
Created attachment 36588 [details] Experimental fix The attached patch fixes the problem for us by skipping DW_TAG_variable DWARF info that only contains a DW_AT_specification (no DW_AT_type and DW_AT_name), assuming that they are just duplicate declarations/definitions.
@comment 2 I can't see anything special that the file does: -- secp256.go -- package secp256k1 /* #cgo CFLAGS: -I./secp256k1 ... #include "./secp256k1/src/secp256k1.c" */ import "C" -- END -- Then in -- secp256k1.c -- const secp256k1_nonce_function_t secp256k1_nonce_function_rfc6979 = nonce_function_rfc6979; -- END -- Just this one occurence of the symbol "secp256k1_nonce_function_rfc6979".
Any opinions on the patch in comment 3?
The patch seems plausible but we'll need a test case, even if that test case only fails with current GCC. It looks like the GCC change might be due to the early-debug work. It looks like it should be pretty easy to boil down the test case into a small piece of code that fails.
All right, I'll try to extract a minimal test case.
Created attachment 36750 [details] Test case This is the requested minimal test program.
Thanks very much for taking the time to narrow down the test case. That is nice and simple.
FYI, refiled as https://golang.org/issue/13344 and sent out https://golang.org/cl/17151 , a variant of the patch you suggested.
Author: ian Date: Fri Nov 20 22:48:47 2015 New Revision: 230685 URL: https://gcc.gnu.org/viewcvs?rev=230685&root=gcc&view=rev Log: PR go/68072 cmd/cgo: ignore vars with no name or type if they have a AttrSpecification Backport of master CL https://golang.org/cl/17151. Fixes https://gcc.gnu.org/PR/68072. Reviewed-on: https://go-review.googlesource.com/17152 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/cmd/cgo/gcc.go
Author: ian Date: Fri Nov 20 22:49:06 2015 New Revision: 230686 URL: https://gcc.gnu.org/viewcvs?rev=230686&root=gcc&view=rev Log: PR go/68072 cmd/cgo: ignore vars with no name or type if they have a AttrSpecification Backport of master CL https://golang.org/cl/17151. Fixes https://gcc.gnu.org/PR/68072. Reviewed-on: https://go-review.googlesource.com/17152 Modified: branches/gcc-5-branch/libgo/go/cmd/cgo/gcc.go
Should be fixed on mainline and GCc 5 branch.