Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gollvm: error in names.cc [const: assertion 'c < '0' || c > '9'' failed] when building mjl-/vmgo package #41862

Closed
advancedwebdeveloper opened this issue Oct 8, 2020 · 11 comments
Milestone

Comments

@advancedwebdeveloper
Copy link

@advancedwebdeveloper advancedwebdeveloper commented Oct 8, 2020

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

$ go version

go version go1.15.2 gollvm LLVM 12.0.0git linux/amd64
My "release" build is available [here](go version go1.15.2 gollvm LLVM 12.0.0git linux/amd64
)

Does this issue reproduce with the latest release?

Yes, for sure.

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

Ubuntu 20.04 x86_64

go env $ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/oceanfish81/.cache/go-build"
GOENV="/home/oceanfish81/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/oceanfish81/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/oceanfish81/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/oceanfish81/gollvm_dist"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/oceanfish81/gollvm_dist/tools"
GCCGO="/home/oceanfish81/gollvm_dist/bin/llvm-goc"
AR="ar"
CC="/usr/bin/clang"
CXX="/usr/bin/clang++"
CGO_ENABLED="1"
GOMOD="/home/oceanfish81/golang_projects/duit/go.mod"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build577579041=/tmp/go-build -gno-record-gcc-switches -funwind-tables"


$ go env

What did you do?

Cloned duit and entered the directory.
Then I tried to build

$ go build -i -v -x

What did you expect to see?

Normal build process, without any errors.

What did you see instead?

WORK=/tmp/go-build288395935

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info

get https://proxy.golang.org/github.com/mjl-/go/@v/v0.0.0-20180429123528-fafada5f286e.info: 200 OK (0.832s)

9fans.net/go/draw/drawfcall
mkdir -p $WORK/b003/
cd $WORK
/home/oceanfish81/gollvm_dist/bin/llvm-goc -fgo-importcfg=/dev/null -c -x c - -o /dev/null || true
cd /home/oceanfish81/go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall
/home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ./bit.go ./msg.go ./mux.go

9fans.net/go/draw/drawfcall

llvm-goc: /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go/names.cc:595: std::string Type::mangled_name(Gogo ) const: assertion 'c < '0' || c > '9'' failed.
#0 0x0000000000d765f3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd765f3)
#1 0x0000000000d7468c llvm::sys::RunSignalHandlers() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd7468c)
#2 0x0000000000d76a85 SignalHandler(int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd76a85)
#3 0x00007f73143713c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x00007f7313ea218b raise /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x00007f7313e81859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#6 0x000000000051b662 (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x51b662)
#7 0x00000000004b1397 Type::mangled_name(Gogo
) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b1397)
#8 0x00000000004b3ec8 Gogo::type_descriptor_name(Type const*, Named_type*) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b3ec8)
#9 0x0000000000548101 Sort_types::operator()(Type const*, Type const*) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x548101)
#10 0x0000000000547fa9 void std::__1::__sort<Sort_types&, Type const**>(Type const**, Type const**, Sort_types&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x547fa9)
#11 0x0000000000542a1a Export::assign_type_indices(std::__1::vector<Named_object*, std::__1::allocator<Named_object*> > const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542a1a)
#12 0x0000000000542261 Export::export_globals(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, Import_init_set const&, Bindings const*, std::__1::unordered_set<Named_object*, std::__1::hash<Named_object*>, std::__1::equal_to<Named_object*>, std::__1::allocator<Named_object*> >) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542261)
#13 0x000000000049253d Gogo::do_exports() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x49253d)
#14 0x0000000000479b28 go_parse_input_files(char const**, unsigned int, bool, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x479b28)
#15 0x000000000046e933 gollvm::driver::CompileGoImpl::invokeFrontEnd() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x46e933)
#16 0x000000000047118b gollvm::driver::CompileGo::performAction(gollvm::driver::Compilation&, gollvm::driver::Action const&, llvm::SmallVector<gollvm::driver::Artifact
, 3u> const&, gollvm::driver::Artifact const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x47118b)
#17 0x0000000000467b12 gollvm::driver::Driver::processAction(gollvm::driver::Action*, gollvm::driver::Compilation&, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467b12)
#18 0x0000000000467c22 gollvm::driver::Driver::processActions(gollvm::driver::Compilation&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467c22)
#19 0x0000000000460f07 main (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x460f07)
#20 0x00007f7313e830b3 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:342:3
#21 0x000000000045fb2e _start (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x45fb2e)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=/tmp/go-build288395935=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/bit.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/msg.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/mux.go

oceanfish81@oceanfish81-VirtualBox:~/golang_projects/duit$ go test ./...

9fans.net/go/draw/drawfcall

llvm-goc: /home/oceanfish81/workarea/llvm-project/llvm/tools/gollvm/gofrontend/go/names.cc:595: std::string Type::mangled_name(Gogo ) const: assertion 'c < '0' || c > '9'' failed.
#0 0x0000000000d765f3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd765f3)
#1 0x0000000000d7468c llvm::sys::RunSignalHandlers() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd7468c)
#2 0x0000000000d76a85 SignalHandler(int) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0xd76a85)
#3 0x00007f27a70ee3c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x00007f27a6c1f18b raise /build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x00007f27a6bfe859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#6 0x000000000051b662 (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x51b662)
#7 0x00000000004b1397 Type::mangled_name(Gogo
) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b1397)
#8 0x00000000004b3ec8 Gogo::type_descriptor_name(Type const*, Named_type*) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x4b3ec8)
#9 0x0000000000548101 Sort_types::operator()(Type const*, Type const*) const (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x548101)
#10 0x0000000000547fa9 void std::__1::__sort<Sort_types&, Type const**>(Type const**, Type const**, Sort_types&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x547fa9)
#11 0x0000000000542a1a Export::assign_type_indices(std::__1::vector<Named_object*, std::__1::allocator<Named_object*> > const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542a1a)
#12 0x0000000000542261 Export::export_globals(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::map<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, Package*, std::__1::less<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const, Package*> > > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, Import_init_set const&, Bindings const*, std::__1::unordered_set<Named_object*, std::__1::hash<Named_object*>, std::__1::equal_to<Named_object*>, std::__1::allocator<Named_object*> >) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x542261)
#13 0x000000000049253d Gogo::do_exports() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x49253d)
#14 0x0000000000479b28 go_parse_input_files(char const**, unsigned int, bool, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x479b28)
#15 0x000000000046e933 gollvm::driver::CompileGoImpl::invokeFrontEnd() (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x46e933)
#16 0x000000000047118b gollvm::driver::CompileGo::performAction(gollvm::driver::Compilation&, gollvm::driver::Action const&, llvm::SmallVector<gollvm::driver::Artifact
, 3u> const&, gollvm::driver::Artifact const&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x47118b)
#17 0x0000000000467b12 gollvm::driver::Driver::processAction(gollvm::driver::Action*, gollvm::driver::Compilation&, bool) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467b12)
#18 0x0000000000467c22 gollvm::driver::Driver::processActions(gollvm::driver::Compilation&) (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x467c22)
#19 0x0000000000460f07 main (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x460f07)
#20 0x00007f27a6c000b3 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:342:3
#21 0x000000000045fb2e _start (/home/oceanfish81/gollvm_dist/bin/llvm-goc+0x45fb2e)
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/oceanfish81/gollvm_dist/bin/llvm-goc -c -O2 -g -m64 -fdebug-prefix-map=/tmp/go-build443995143=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=9fans.net/go/draw/drawfcall -o $WORK/b003/go.o -I $WORK/b003/importcfgroot ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/bit.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/msg.go ../../go/pkg/mod/github.com/mjl-/go@v0.0.0-20180429123528-fafada5f286e/draw/drawfcall/mux.go

It looks like this assertion fails.

@ianlancetaylor , please what is it implemented for.

@thanm , @cherrymui : my compressed build folder, for gollvm, could be retrieved here

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 8, 2020

The problem arises when building in the directory vendor/9fans.net/go/draw/drawfcall. The gofrontend code doesn't correctly handle package paths starting with digits. I'll take a look.

CC @thanm @cherrymui

@ianlancetaylor ianlancetaylor added this to the Gccgo milestone Oct 8, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 9, 2020

@thanm This turns out to be more complicated than I thought. As I reread the long comment at the top of names.cc, I see that it explicitly assumes that a pkgpath can't contain a dot. But the current pkgpath encoding can contain a dot. That means that we can have name conflicts.

Consider x/a.go:

package p

type x2e int

func (x2e) M() {}

x./a.go (note: the name of the directory is x., with a trailing dot):

package p

import _ "x"

func M() {}

main/main.go:

package main

import _ "x."

func main() {}

Building main gives this error:

# main
/home/iant/binutils/gold-dir/ld: error: /home/iant/.cache/go-build/7b/7baa8f3e3feb77e7d804488cc23f3709086aea92a5afc313dbec7febc4fb5b61-d(_go_.o): multiple definition of 'x.x2e.M'
/home/iant/binutils/gold-dir/ld: /home/iant/.cache/go-build/f7/f7f6d53f176b77f8bc226aa6215f9ff5f7b6affda1f6f804d3ea05b679463344-d(_go_.o): previous definition here
collect2: error: ld returned 1 exit status

The problem is that in the package x (no dot) the name of the method is x.x2e.M. In the package x. (with dot), the package path is encoded as x.x2e and the name of the function is x.x2e.M. So the method and the function wind up with the same name.

Unfortunately I think we need to introduce yet another package path mangling scheme, one that doesn't use a dot in the package path. Unless anyone can think of a better idea.

@thanm
Copy link
Member

@thanm thanm commented Oct 9, 2020

Ouch. I don't see an easy way to resolve that clash. BTW, this seems orthogonal to original submitted problem, which is a compiler crash?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 9, 2020

It's different but related. The compiler crash is because the mangled package path has a leading digit, which triggers an assertion failure when it is combined with a leading dot. That is, the problem in both cases is package path mangling.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 12, 2020

@thanm @cherrymui Here are my thoughts. Interested to hear yours.

Premises:

  1. The names of symbols in generated assembly code and object files must contain only ASCII letters, ASCII digits, underscore, and dot. They must start with an ASCII letter or underscore.
  2. A Go symbol may contain any Unicode letter or digit or underscore but may not contain dot.
  3. A package path may contain any character at all, except perhaps a 0 byte.
  4. To avoid symbol name conflicts, we need some way to separate symbol names into components, such as some way to separate the package path from the actual symbol, and a number of similar separations. Currently we use dot for that, as outlined in the long comment at the top of names.cc. To maintain sanity that separation symbol must not appear in the components that we are separating.
  5. We clearly must have some encoding scheme for characters that can't appear in symbol names. For simplicity and convenience for users it should be straightforward to decode that scheme without having to understand the different components of a symbol name. That is, decoding should not need to figure out whether it is looking at a package path or a Go identifier name.

The problem we have today is that we accidentally broke premise 4: a dot can appear in a package path. This leads to ambiguity.

I see two paths forward.

First path.

We continue using dot as the separator character and we keep the current identifier encoding. Therefore, we need an encoding scheme for package paths that converts any string to ASCII letters, digits, and underscores, with no dots. The obvious choice is to use underscore. We encode bytes < 0x80 as _xbb (or _zbb) and we encode Unicode characters as either _udddd or _Udddddddd. We encode underscore itself as either _x5f or as simply __. Note that we also have to encode a leading digit in a package path, presumably using the _xbb notation.

To satisfy premise 5, we have to further encode underscores in Go identifier names. We can encode them as ..z5f (using the current encoding) or _x5f or __ (using the new encoding).

This means that the decoding scheme will have to support both underscore mangling and dot mangling.

Second path.

We continue using dot as a separator character. However, we stop using dot as a mangling character. Instead, we use underscore. Instead of .xbb in a struct tag, we use _xbb. Instead of ..zbb, ..udddd or ..Udddddddd, we use _xbb, _udddd, or _Udddddddd. We encode underscore itself as either _x5f or __. We apply this mangling to both package paths and Go identifiers.

This makes the decoding scheme simpler. It's a little easier to reason about as we no longer have to ensure that there is no overlap between the separator character dot and the mangling character dot (this is why the mangling scheme needs two dots but only one underscore).

@thanm
Copy link
Member

@thanm thanm commented Oct 12, 2020

Thanks the the analysis. I think you've broken it down well.

The one thing that makes me nervous about making more use of "_" (as opposed to ".") in the mangling process is that it increases the risk that users might not "notice" that a given symbol is encoded vs original. With the "." encoding, most Go users are aware that Go symbols can't contain a dot, so when seeing a mangled named one immediately catches on. When looking at a name like "x_x5f_x5fQ" in the debugger, it's possible that a user might not catch on right away that this is a mangled symbol name.

With that said, we have to do something, so in fact either of the schemes you describe seem ok to me. Getting a complete/functional mangling scheme is the important thing, even if it risks user debugger confusion in rare cases.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Oct 12, 2020

@brendandburns , could you express your vision/opinion?

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 17, 2020

Change https://golang.org/cl/270637 mentions this issue: cmd/go, cmd/cgo: update gofrontend mangling checks

gopherbot pushed a commit to golang/gofrontend that referenced this issue Nov 18, 2020
This is a port of two patches in the master repository.

https://golang.org/cl/259298

    cmd/cgo: split gofrontend mangling checks into cmd/internal/pkgpath

    This is a step toward porting https://golang.org/cl/219817 from the
    gofrontend repo to the main repo.

    Note that this also corrects the implementation of the v2 mangling
    scheme to use ..u and ..U where appropriate.

https://golang.org/cl/259299

    cmd/go: use cmd/internal/pkgpath for gccgo pkgpath symbol

For golang/go#37272
For golang/go#41862

Change-Id: Id276ca1bac7e1d850408a9d222c19e57b26ba001
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/270637
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
pull bot pushed a commit to Qwerty0x64/gcc that referenced this issue Nov 18, 2020
This is a port of two patches in the master repository.

https://golang.org/cl/259298

    cmd/cgo: split gofrontend mangling checks into cmd/internal/pkgpath

    This is a step toward porting https://golang.org/cl/219817 from the
    gofrontend repo to the main repo.

    Note that this also corrects the implementation of the v2 mangling
    scheme to use ..u and ..U where appropriate.

https://golang.org/cl/259299

    cmd/go: use cmd/internal/pkgpath for gccgo pkgpath symbol

For golang/go#37272
For golang/go#41862

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/270637
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 19, 2020

Change https://golang.org/cl/271726 mentions this issue: compiler, libgo: change mangling scheme

gopherbot pushed a commit to golang/gofrontend that referenced this issue Nov 20, 2020
Overhaul the mangling scheme to avoid ambiguities if the package path
contains a dot. Instead of using dot both to separate components and
to mangle characters, use dot only to separate components and use
underscore to mangle characters.

For golang/go#41862

Change-Id: Iddc04422673a4cdc6773d24d3d75fc8945266773
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 20, 2020

Change https://golang.org/cl/272127 mentions this issue: cmd/cgo, cmd/internal/pkgpath: support gofrontend mangler v3

gopherbot pushed a commit that referenced this issue Nov 20, 2020
The gofrontend mangling scheme used by gccgo and GoLLVM has changed again.
Support the new version. This is a port of the relevant parts of
https://golang.org/cl/271726.

For #41862

Change-Id: I9c961c8e17ec960a83a23e1d49ea900962b63393
Reviewed-on: https://go-review.googlesource.com/c/go/+/272127
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
kraj pushed a commit to kraj/gcc that referenced this issue Nov 20, 2020
Overhaul the mangling scheme to avoid ambiguities if the package path
contains a dot. Instead of using dot both to separate components and
to mangle characters, use dot only to separate components and use
underscore to mangle characters.

For golang/go#41862

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Dec 8, 2020

This is now fixed on tip.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants