cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 #62465

zhsj · 2023-09-05T20:41:29Z

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

$ go version
go version go1.21.0 linux/riscv64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GO111MODULE=''
GOARCH='riscv64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='riscv64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn'
GOROOT='/usr/lib/go-1.21'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go-1.21/pkg/tool/linux_riscv64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/work/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2926220559=/tmp/go-build -gno-record-gcc-switches'

What did you do?

root@bfe27bbaba29:/# git clone https://github.com/prometheus/alertmanager /work
root@bfe27bbaba29:/# cd /work
root@bfe27bbaba29:/work# go build ./cmd/amtool/

What did you expect to see?

Build successfully.

What did you see instead?

# github.com/prometheus/alertmanager/cmd/amtool
github.com/aws/aws-sdk-go/aws/endpoints.init: missing section for github.com/aws/aws-sdk-go/aws/endpoints.map.init.0
github.com/aws/aws-sdk-go/aws/endpoints.init: reloc 62 (R_RISCV_PCREL_ITYPE) to non-elf symbol github.com/aws/aws-sdk-go/aws/endpoints.map.init.0 (outer=github.com/aws/aws-sdk-go/aws/endpoints.map.init.0) 1 (STEXT)
github.com/aws/aws-sdk-go/aws/endpoints.init: unreachable reloc 62 (R_RISCV_PCREL_ITYPE) target github.com/aws/aws-sdk-go/aws/endpoints.map.init.0

The text was updated successfully, but these errors were encountered:

cherrymui · 2023-09-05T20:44:45Z

cc @golang/riscv64 @golang/compiler

cherrymui · 2023-09-05T20:45:27Z

Is this a regression in Go 1.21? Does it build with Go 1.20? Thanks.

zhsj · 2023-09-06T02:15:42Z

Is this a regression in Go 1.21? Does it build with Go 1.20? Thanks.

Yes. Go1.20 can build.

mengzhuo · 2023-09-06T06:47:44Z

I can confirm this issue, bisect shows d49719b is the first bad commit.

cc @randall77

mknyszek · 2023-09-06T19:19:33Z

In triage, we think the linker failure is a red herring and that it's actually an issue with the write barrier on RISC-V. The problem is we can't really make progress without a RISC-V machine to access (we have a builder, but we don't have SSH privileges). @randall77 briefly looked into this, but got stuck there.

While we look for a way to access a machine in the background, it would be really helpful if someone from @golang/riscv64 could continue investigation here with these breadcrumbs. Thanks.

mengzhuo · 2023-09-07T01:38:15Z

Feel free send me mzh <at> golangcn.org the ssh public key if you want to login builder unmatched025.farm.rvlab.org.

mengzhuo · 2023-09-08T12:44:51Z

Some updates, I can build this amtool now but can't start it

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

goroutine 1 [running]:
github.com/aws/aws-sdk-go/aws/endpoints.init()
        /root/go/pkg/mod/github.com/aws/aws-sdk-go@v1.44.317/aws/endpoints/defaults.go:41015 +0x90

I found that defautls.go has an abnormal big initial function (952KB), both PC and link failure might related to big init function.

randall77 · 2023-09-11T05:36:41Z

I can reproduce the original error with 1.21.1.
I can reproduce Meng's error (builds, but crashes when run) with tip.

4a6f656c · 2023-09-11T10:57:06Z

I suspect this is likely to be a riscv64 assembler or linker issue - some quick data points (on openbsd/riscv64):

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000670128 in github.com/aws/aws-sdk-go/aws/endpoints.init () at /home/joel/go/pkg/mod/github.com/aws/aws-sdk-go@v1.44.317/aws/endpoints/legacy_regions.go:3
#2  0x000000000005c1b8 in runtime.doInit1 (t=0x54122dc0) at /usr/local/go/src/runtime/proc.go:6733
#3  0x000000000004e548 in runtime.doInit (ts=...) at /usr/local/go/src/runtime/proc.go:6700
#4  runtime.main () at /usr/local/go/src/runtime/proc.go:249
#5  0x000000000007cb24 in runtime.goexit () at /usr/local/go/src/runtime/asm_riscv64.s:521

(gdb) disass 0x0000000000670128
   ...
   0x00000000006700b8 <+1027544>:       ld      t1,-1196(t1) # 0x141ec08 <github.com/aws/aws-sdk-go/aws/endpoints.awsisofPartition+72>
   0x00000000006700bc <+1027548>:       beqz    t0,0x6700d8 <github.com/aws/aws-sdk-go/aws/endpoints.init+1027576>
   0x00000000006700c0 <+1027552>:       auipc   t6,0xffa0d
   0x00000000006700c4 <+1027556>:       jalr    -792(t6) # 0x7cda8 <runtime.gcWriteBarrier2>
   0x00000000006700c8 <+1027560>:       sd      t1,0(s8)
   0x00000000006700cc <+1027564>:       auipc   t0,0xdb4
   0x00000000006700d0 <+1027568>:       ld      t0,-356(t0) # 0x1423f68
   0x00000000006700d4 <+1027572>:       sd      t0,8(s8)
   0x00000000006700d8 <+1027576>:       auipc   t6,0xdb4
   0x00000000006700dc <+1027580>:       sd      t1,-368(t6) # 0x1423f68
   0x00000000006700e0 <+1027584>:       auipc   a0,0x300
   0x00000000006700e4 <+1027588>:       addi    a0,a0,382 # 0x97025e
   0x00000000006700e8 <+1027592>:       li      a1,11
   0x00000000006700ec <+1027596>:       auipc   t6,0xffab1
   0x00000000006700f0 <+1027600>:       jalr    -1124(t6) # 0x120c88 <regexp.MustCompile>
   0x00000000006700f4 <+1027604>:       auipc   t0,0xdf2
   0x00000000006700f8 <+1027608>:       lwu     t0,-1620(t0) # 0x1461aa0 <runtime.writeBarrier>
   0x00000000006700fc <+1027612>:       beqz    t0,0x670118 <github.com/aws/aws-sdk-go/aws/endpoints.init+1027640>
   0x0000000000670100 <+1027616>:       auipc   t6,0xffa0d
   0x0000000000670104 <+1027620>:       jalr    -856(t6) # 0x7cda8 <runtime.gcWriteBarrier2>
   0x0000000000670108 <+1027624>:       sd      a0,0(s8)
   0x000000000067010c <+1027628>:       auipc   t0,0xdc0
   0x0000000000670110 <+1027632>:       ld      t0,-1252(t0) # 0x142fc28 <github.com/aws/aws-sdk-go/aws/endpoints.schemeRE>
   0x0000000000670114 <+1027636>:       sd      t0,8(s8)
   0x0000000000670118 <+1027640>:       auipc   t6,0xdc0
   0x000000000067011c <+1027644>:       sd      a0,-1264(t6) # 0x142fc28 <github.com/aws/aws-sdk-go/aws/endpoints.schemeRE>
   0x0000000000670120 <+1027648>:       auipc   t6,0xff990
   0x0000000000670124 <+1027652>:       jalr    -288(t6) # 0x0
   0x0000000000670128 <+1027656>:       auipc   a0,0x329
   0x000000000067012c <+1027660>:       addi    a0,a0,1296 # 0x999638
   0x0000000000670130 <+1027664>:       li      a1,41
   0x0000000000670134 <+1027668>:       auipc   t6,0xffab1
   0x0000000000670138 <+1027672>:       jalr    -1196(t6) # 0x120c88 <regexp.MustCompile>
   0x000000000067013c <+1027676>:       auipc   t0,0xdf2
   0x0000000000670140 <+1027680>:       lwu     t0,-1692(t0) # 0x1461aa0 <runtime.writeBarrier>
   0x0000000000670144 <+1027684>:       beqz    t0,0x670160 <github.com/aws/aws-sdk-go/aws/endpoints.init+1027712>
   0x0000000000670148 <+1027688>:       auipc   t6,0xffa0d
   0x000000000067014c <+1027692>:       jalr    -928(t6) # 0x7cda8 <runtime.gcWriteBarrier2>
   0x0000000000670150 <+1027696>:       sd      a0,0(s8)
   0x0000000000670154 <+1027700>:       auipc   t0,0xdc0
   0x0000000000670158 <+1027704>:       ld      t0,-1316(t0) # 0x142fc30 <github.com/aws/aws-sdk-go/aws/endpoints.regionValidationRegex>
   0x000000000067015c <+1027708>:       sd      t0,8(s8)
   0x0000000000670160 <+1027712>:       auipc   t6,0xdc0
   0x0000000000670164 <+1027716>:       sd      a0,-1328(t6) # 0x142fc30 <github.com/aws/aws-sdk-go/aws/endpoints.regionValidationRegex>
   0x0000000000670168 <+1027720>:       ld      ra,0(sp)
   0x000000000067016c <+1027724>:       lui     t6,0x28
   0x0000000000670170 <+1027728>:       addiw   t6,t6,224
   0x0000000000670174 <+1027732>:       add     sp,sp,t6
   0x0000000000670178 <+1027736>:       ret

The jalr at 0x670124 is literally to 0x0, which smells like a missing or incorrectly handled relocation. As Meng noted, this is a huge function (I've not yet looked at the write barrier change, but it presumably results in the init function growing). On riscv64 the JAL instruction can only reach +/-1MiB, however there is code that should handle this and switch to AUIPC+JALR if the function exceeds that size (the big case in cmd/internal/obj/riscv/obj.go:preprocess) - at first glance this looks to be correct.

The next step is to figure out what that call is supposed to be targeting...

4a6f656c · 2023-09-11T12:43:19Z

Two more data points... the reported error message can be reproduced by forcing external linking:

$ go build -o amtool -ldflags=-linkmode=external ./cmd/amtool                  
# github.com/prometheus/alertmanager/cmd/amtool
github.com/aws/aws-sdk-go/aws/endpoints.init: missing section for github.com/aws/aws-sdk-go/aws/endpoints.map.init.0
github.com/aws/aws-sdk-go/aws/endpoints.init: reloc 62 (R_RISCV_PCREL_ITYPE) to non-elf symbol github.com/aws/aws-sdk-go/aws/endpoints.map.init.0 (outer=github.com/aws/aws-sdk-go/aws/endpoints.map.init.0) 1 (STEXT)
github.com/aws/aws-sdk-go/aws/endpoints.init: unreachable reloc 62 (R_RISCV_PCREL_ITYPE) target github.com/aws/aws-sdk-go/aws/endpoints.map.init.0

The github.com/aws/aws-sdk-go/aws/endpoints.map.init.0 symbol does not exist in the internally linked version (so I suspect this is what the call is supposed to be to):

$ llvm-objdump -x ./amtool | fgrep -c aws/endpoints.init   
1
$ llvm-objdump -x ./amtool | fgrep -c aws/endpoints.map    
0

randall77 · 2023-09-11T15:57:57Z

@thanm This looks like maybe the lazy map stuff? That's the symbol that isn't reached.
Adding -gcflags=all=-d=wrapglobalmapctl=1 fixed it.

thanm · 2023-09-11T16:11:25Z

Thanks, yes, it does look related. I think the problem might be this code here:

https://go.googlesource.com/go/+/fbcf43c60ba5170309a238b0e42fd5879d419776/src/cmd/internal/objabi/reloctype.go#369

which doesn't include R_RISCV_PCREL_ITYPE. Linker deadcode is calling IsDirectCall here:

https://go.googlesource.com/go/+/fbcf43c60ba5170309a238b0e42fd5879d419776/src/cmd/link/internal/ld/deadcode.go#305

and if that's not returning TRUE for the call from init func to outline map init fragment, that will be a problem.

4a6f656c · 2023-09-11T16:25:29Z

I arrived at the same conclusion - what I believe is happening is that the assembler switches the JAL (with R_RISCV_CALL or R_RISCV_CALL_TRAMP) to an AUIPC+JALR with R_RISCV_PCREL_ITYPE, which means it is no longer considered a direct call. That results in a dangling call to map.init that has been removed as dead code. Unfortunately, R_RISCV_PCREL_ITYPE is currently overloaded - this would be addressed with:

https://go-review.googlesource.com/c/go/+/520095

That said, based on the comment above IsDirectCall it is not immediately clear that AUIPC+JALR should be treated as a direct call, since the call is made via a register (however we're loading the value into that register, so it is effectively the same as a two instruction version of the immediate and not an arbitrary call to a function pointer).

FWIW, commenting out the IsDirectCall check in cmd/link/internal/ld/deadcode.go:mapinitcleanup avoids the issue.

cherrymui · 2023-09-11T16:35:17Z

I thought the JAL to AUIPC+JALR rewrite still keeps an R_RISCV_CALL relocation around? So the linker can find the direct call target in a few places. Does it not?

4a6f656c · 2023-09-11T18:28:40Z

I thought the JAL to AUIPC+JALR rewrite still keeps an R_RISCV_CALL relocation around? So the linker can find the direct call target in a few places. Does it not?

No, the R_RISCV_CALL is switched to R_RISCV_PCREL_ITYPE in the process:

https://go.googlesource.com/go/+/fbcf43c60ba5170309a238b0e42fd5879d419776/src/cmd/internal/obj/riscv/obj.go#667

This is needed so that we can distinguish between the single instruction JAL calls and the two instruction AUIPC+JALR calls, largely for trampoline handling. This was one of the reasons for suggesting CL#520095 - another option would be to keep them as R_RISCV_CALL and use the size of the relocation to distinguish between them, but that feels like a nasty hack...

thanm · 2023-09-11T18:37:36Z

There are a number of places in the linker where the code needs to detect whether a relocation is a direct call, e.g.

$ git grep IsDirectCall
ld/data.go:             if r.Type().IsDirectCallOrJump() {
ld/data.go:             if !rt.IsDirectCallOrJump() && !isPLTCall(rt) {
ld/deadcode.go:                         if d.ctxt.canUsePlugins && r.Type().IsDirectCall() {
ld/deadcode.go:                 if r.Weak() && r.Type().IsDirectCall() && !d.ldr.AttrReachable(rs) {
ld/lib.go:                      if r.Type().IsDirectCall() && ldr.SymType(rs) == sym.STEXT {
ld/pcln.go:             if r.Type().IsDirectCall() && (r.Sym() == deferReturnSym || ldr.IsDeferReturnTramp(r.Sym())) {
ld/stackcheck.go:                       if t.IsDirectCall() || t == objabi.R_CALLIND {

For RISCV calls are converted to R_RISCV_PCREL_ITYPE and then IsDirectCall no longer recognizes them, what should our plan be for making sure that deadcode, stackcheck, etc still work properly?

cherrymui · 2023-09-11T19:12:19Z

@4a6f656c I suggest that when rewriting JAL to AUIPC+JALR, we emit an R_RISCV_PCREL_ITYPE relocation but also keep the R_RISCV_CALL marker relocation. R_RISCV_CALL doesn't need to imply any code change, just tells the linker what the direct call target is. I thought it worked that way, but apparently it does not... I wonder if (and how) the current stack bounds check in the linker works for RISCV64...

Maybe CL 520095 does so. I haven't looked at the CL.

another option would be to keep them as R_RISCV_CALL and use the size of the relocation to distinguish between them

I'm not sure why we need to distinguish between them. I was thinking R_RISCV_PCREL_ITYPE applies to actual code generation and R_RISCV_CALL is just a marker.

4a6f656c · 2023-09-12T06:08:58Z

For RISCV calls are converted to R_RISCV_PCREL_ITYPE and then IsDirectCall no longer recognizes them, what should our plan be for making sure that deadcode, stackcheck, etc still work properly?

I think we're all agreeing that this is a long standing bug that needs to be fixed - IsDirectCall should be returning true in this case (and it is not currently). To date it has not caused any known issues since the precondition is a single function that has a text size that exceeds 1MiB.

4a6f656c · 2023-09-12T12:51:18Z

@4a6f656c I suggest that when rewriting JAL to AUIPC+JALR, we emit an R_RISCV_PCREL_ITYPE relocation but also keep the R_RISCV_CALL marker relocation. R_RISCV_CALL doesn't need to imply any code change, just tells the linker what the direct call target is. I thought it worked that way, but apparently it does not... I wonder if (and how) the current stack bounds check in the linker works for RISCV64...

Maybe CL 520095 does so. I haven't looked at the CL.

another option would be to keep them as R_RISCV_CALL and use the size of the relocation to distinguish between them

I'm not sure why we need to distinguish between them. I was thinking R_RISCV_PCREL_ITYPE applies to actual code generation and R_RISCV_CALL is just a marker.

Currently, R_RISCV_CALL is used to identify relocations that may need trampolines - if they overlap we would be mishandling AUIPC+JALR with trampolines:

https://go.googlesource.com/go/+/fbcf43c60ba5170309a238b0e42fd5879d419776/src/cmd/link/internal/riscv64/asm.go#171

I see a number of ways to fix this:

Add R_RISCV_JAL and use that to mark sites that may need trampolines - R_RISCV_CALL is then used to mark the AUIPC+JALR variant (which is what CL 520095 does). In order to fix this issue, we then simply add R_RISCV_CALL to the IsDirectCase.
Use R_RISCV_CALL as a direct call marker in all cases and use R_RISCV_JAL and R_RISCV_PCREL_ITYPE to mark the individual cases (i.e. a relocation has both a R_RISCV_CALL and a R_RISCV_JAL or R_RISCV_PCREL_ITYPE).
Use R_RISCV_CALL as a direct call marker in all cases and use the relocation size to determine if it is a JAL or AUIPC+JALR. This would work, but seems potentially fragile.

I'll try to send a fix out today or tomorrow.

gopherbot · 2023-09-17T16:01:46Z

Change https://go.dev/cl/520095 mentions this issue: cmd/internal/obj/riscv,cmd/link: rework riscv64 call relocations

zhsj · 2023-09-22T05:06:18Z

Hi, could this be backported to 1.21 as it's a regression and I'm not sure how to workaround it.

ianlancetaylor · 2023-09-22T20:07:06Z

@gopherbot Please open backport to 1.21.

This is a build failure with no straightforward workaround. It is a regression from 1.20.

gopherbot · 2023-09-22T20:07:48Z

Backport issue(s) opened: #63166 (for 1.20), #63167 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

4a6f656c · 2023-09-23T15:33:44Z

@ianlancetaylor Could we please retitle this issue and the backport issue - it is really "cmd/internal/objabi,cmd/link: direct calls not correctly identified on riscv64" (it does not actually have anything to do with write barriers). Also, just to clarify, this issue exists in 1.20 - however the code that makes it a noticeable issue does not.

@zhsj One workaround for the issue is to compile with -gcflags=all=-d=wrapglobalmapctl=1 (per #62465 (comment)):

$ go build ./cmd/amtool/           
$ ./amtool                                                                                                                                                                                
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
                                                                                                                  
goroutine 1 [running]:                         
github.com/aws/aws-sdk-go/aws/endpoints.init()   
        /home/joel/go/pkg/mod/github.com/aws/aws-sdk-go@v1.44.317/aws/endpoints/v3model.go:44 +0xfae48
$ go build -gcflags=all=-d=wrapglobalmapctl=1 ./cmd/amtool/
$ ./amtool                                                   
usage: amtool [<flags>] <command> [<args> ...]                                                                    
                                                                                                                  
View and modify the current Alertmanager state.
...

cherrymui · 2023-09-25T14:16:47Z

I feel CL 520095 is a bit invasive for backporting. Could we use some simpler workaround, like adding some relocation type to IsDirectCall? Will it cause any problem? Thanks.

hack3ric · 2024-02-09T17:47:33Z

This issue seems not fixed completely. When building Go packages containing aws-sdk-go using Go 1.22.0 and Arch Linux RISC-V, similar errors appear, though output differs.

Build log taken from https://archriscv.felixc.at/.status/log.htm?url=logs/rekor/rekor-1.3.5-1.log:

# command-line-arguments
failed to find text symbol for HI20 relocation at 16198024 (f72988)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.morestack_noctxt
failed to find text symbol for HI20 relocation at 16198076 (f729bc)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to regexp.MustCompile
failed to find text symbol for HI20 relocation at 16198096 (f729d0)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.gcWriteBarrier2
failed to find text symbol for HI20 relocation at 16198128 (f729f0)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to github.com/aws/aws-sdk-go/aws/endpoints.map.init.0
failed to find text symbol for HI20 relocation at 16198136 (f729f8)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to github.com/aws/aws-sdk-go/aws/endpoints.init.func1
failed to find text symbol for HI20 relocation at 16198156 (f72a0c)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.gcWriteBarrier2
failed to find text symbol for HI20 relocation at 16198188 (f72a2c)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.makemap_small
failed to find text symbol for HI20 relocation at 16198228 (f72a54)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.duffzero
failed to find text symbol for HI20 relocation at 16198280 (f72a88)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.newobject
failed to find text symbol for HI20 relocation at 16198356 (f72ad4)
github.com/aws/aws-sdk-go/aws/endpoints.init: unsupported obj reloc 62 (R_RISCV_CALL)/8 to runtime.newobject
failed to find text symbol for HI20 relocation at 16198448 (f72b30)
/usr/lib/go/pkg/tool/linux_riscv64/link: too many errors

This failed to build on riscv64 due to a bug in the Go compiler. With the upgrade to Go 1.22 this bug has been fixed. Hence, we can enable mimir on riscv64 again. See: * https://gitlab.alpinelinux.org/alpine/aports/-/commit/44b844d6da762606eba8912f97877c565b70ef4f#note_363441 * golang/go#62465 Co-authored-by: raspbeguy <guy.godfroy@gugod.fr>

cherrymui added the arch-riscv Issues solely affecting the riscv64 architecture. label Sep 5, 2023

cherrymui changed the title ~~cmd/go: build fails with unreachable reloc 62 (R_RISCV_PCREL_ITYPE) target~~ cmd/link: build fails with unreachable reloc 62 (R_RISCV_PCREL_ITYPE) target Sep 5, 2023

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Sep 5, 2023

cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 5, 2023

mknyszek added this to the Backlog milestone Sep 6, 2023

mknyszek changed the title ~~cmd/link: build fails with unreachable reloc 62 (R_RISCV_PCREL_ITYPE) target~~ cmd/compile,runtime: write barrier issue on riscv64 Sep 6, 2023

Xeonacid mentioned this issue Sep 12, 2023

upgpatch: go 2:1.21.1-1 felixonmars/archriscv-packages#2957

Merged

gopherbot closed this as completed in bda5e6c Sep 19, 2023

gopherbot mentioned this issue Sep 22, 2023

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 [1.20 backport] #63166

Closed

gopherbot mentioned this issue Sep 22, 2023

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 [1.21 backport] #63167

Open

ianlancetaylor changed the title ~~cmd/compile,runtime: write barrier issue on riscv64~~ cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 Sep 26, 2023

dmitshur modified the milestones: Backlog, Go1.22 Oct 4, 2023

dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 4, 2023

Xeonacid mentioned this issue Feb 10, 2024

cmd/link: RISC-V external link, failed to find text symbol for HI20 relocation #65646

Closed

iGxnon mentioned this issue Mar 22, 2024

修复 alertmanager openEuler-RISCV/oerv-team#278

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 #62465

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 #62465

zhsj commented Sep 5, 2023

cherrymui commented Sep 5, 2023

cherrymui commented Sep 5, 2023

zhsj commented Sep 6, 2023

mengzhuo commented Sep 6, 2023 •

edited

mknyszek commented Sep 6, 2023

mengzhuo commented Sep 7, 2023

mengzhuo commented Sep 8, 2023

randall77 commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

randall77 commented Sep 11, 2023

thanm commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

cherrymui commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

thanm commented Sep 11, 2023 •

edited

cherrymui commented Sep 11, 2023

4a6f656c commented Sep 12, 2023

4a6f656c commented Sep 12, 2023

gopherbot commented Sep 17, 2023

zhsj commented Sep 22, 2023 •

edited

ianlancetaylor commented Sep 22, 2023

gopherbot commented Sep 22, 2023

4a6f656c commented Sep 23, 2023

cherrymui commented Sep 25, 2023

hack3ric commented Feb 9, 2024

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 #62465

cmd/internal/objabi, cmd/link: direct calls not correctly identified on riscv64 #62465

Comments

zhsj commented Sep 5, 2023

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

cherrymui commented Sep 5, 2023

cherrymui commented Sep 5, 2023

zhsj commented Sep 6, 2023

mengzhuo commented Sep 6, 2023 • edited

mknyszek commented Sep 6, 2023

mengzhuo commented Sep 7, 2023

mengzhuo commented Sep 8, 2023

randall77 commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

randall77 commented Sep 11, 2023

thanm commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

cherrymui commented Sep 11, 2023

4a6f656c commented Sep 11, 2023

thanm commented Sep 11, 2023 • edited

cherrymui commented Sep 11, 2023

4a6f656c commented Sep 12, 2023

4a6f656c commented Sep 12, 2023

gopherbot commented Sep 17, 2023

zhsj commented Sep 22, 2023 • edited

ianlancetaylor commented Sep 22, 2023

gopherbot commented Sep 22, 2023

4a6f656c commented Sep 23, 2023

cherrymui commented Sep 25, 2023

hack3ric commented Feb 9, 2024

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

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

mengzhuo commented Sep 6, 2023 •

edited

thanm commented Sep 11, 2023 •

edited

zhsj commented Sep 22, 2023 •

edited