cmd/pprof: disasm not working on darwin

[rsc]

On my Mac, if I run go test -cpuprofile=x.prof anything, and then go tool pprof x.prof, then the disasm command in pprof does not work, for any function at all:

% go test -cpuprofile=x.prof strings
ok  	strings	1.059s
% go tool pprof x.prof
Type: cpu
Time: Jan 28, 2022 at 2:06pm (EST)
Duration: 805.01ms, Total samples = 540ms (67.08%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 540ms, 100% of 540ms total
Showing top 10 nodes out of 27
      flat  flat%   sum%        cum   cum%
     210ms 38.89% 38.89%      210ms 38.89%  cmpbody
     170ms 31.48% 70.37%      170ms 31.48%  memeqbody
      50ms  9.26% 79.63%       50ms  9.26%  unicode.to
      50ms  9.26% 88.89%       50ms  9.26%  unicode/utf8.EncodeRune
      30ms  5.56% 94.44%      140ms 25.93%  strings.Map
      10ms  1.85% 96.30%       10ms  1.85%  runtime.decoderune
      10ms  1.85% 98.15%       10ms  1.85%  runtime.madvise
      10ms  1.85%   100%      390ms 72.22%  strings_test.TestCompareStrings
         0     0%   100%       10ms  1.85%  runtime.(*mcache).allocLarge
         0     0%   100%       10ms  1.85%  runtime.(*mheap).alloc
(pprof) disasm cmpbody
no matches found for regexp: cmpbody
(pprof) disasm unicode.to
no matches found for regexp: unicode.to
(pprof) disasm .*
no matches found for regexp: .*
(pprof) 

I have not checked whether this is Mac-specific.

[ALTree]

go test -cpuprofile=x.prof strings will leave a strings.test binary in the working directory. If pprof is invoked as go tool pprof x.prof, disasm fails because it's looking for the binary in /tmp/, and it's not there:

(pprof) disasm cmpbody
open /tmp/go-build477592094/b001/strings.test: no such file or directory
no matches found for regexp: cmpbody

but if the binary (which is in wd) is explicitly passed as go tool pprof strings.test x.prof, then disasm works correctly.

FWIW, I see the same behaviour with go1.17.5 (above tests are from tip).

(This is on Linux).

[ianlancetaylor]

Agreed, as far as I can tell this has never worked.

This works (on linux-amd64):

go test -c strings
./strings.test -test.cpuprofile=x.prof
go tool pprof x.prof
disasm cmpbody

Removing the release-blocker label.

[cespare]

I stub my toe on this UX about every other time I use pprof.

[cherrymui]

It seems the go command first runs the binary in the tmp directory, collects the profile, then moves it to the current directory. The file path recorded is the one in the tmp directory.

$WORK/b001/strings.test -test.paniconexit0 -test.timeout=10m0s -test.outputdir=/tmp -test.cpuprofile=x.prof
mkdir -p /tmp/
mv $WORK/b001/strings.test /tmp/strings.test

Perhaps the go command can move the file first then run it?

Another part is that it seems the file names recorded in the profile are from profile.Mapping, which is from reading /proc/self/maps, which probably works only on Linux. So on macOS we may need to always pass the executable file name to pprof, even if the go command does the mv first.

[rsc]

Thanks. Indeed, not a release blocker. It should be easy to run the final executable instead of the one from /tmp to fix Linux. For the Mac we should be able to record os.Executable, which might be sufficient. All good things for a future release.

[fumin]

Getting the same problem on Windows:

PS C:\Users\a3367\work\misc\seg> go run .\cmd\vizccl\main.go
2022/03/29 13:28:17.416938 C:/Users/a3367/work/misc/seg/cmd/vizccl/main.go:45: png write start output\vizqqq.png
2022/03/29 13:28:48.685875 C:/Users/a3367/work/misc/seg/cmd/vizccl/main.go:55: png write end output\vizqqq.png
PS C:\Users\a3367\work\misc\seg>
PS C:\Users\a3367\work\misc\seg\output> go tool pprof .\png_encode.pprof
Type: cpu
Time: Mar 29, 2022 at 1:28pm (CST)
Duration: 31.43s, Total samples = 17.53s (55.77%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 16.92s, 96.52% of 17.53s total
Dropped 91 nodes (cum <= 0.09s)
Showing top 10 nodes out of 29
      flat  flat%   sum%        cum   cum%
     7.96s 45.41% 45.41%     13.07s 74.56%  image/png.filter
        2s 11.41% 56.82%      2.01s 11.47%  image/png.abs
     1.74s  9.93% 66.74%      1.74s  9.93%  runtime.memmove
     1.56s  8.90% 75.64%      1.56s  8.90%  image/png.abs8
     1.44s  8.21% 83.86%      3.46s 19.74%  image/png.paeth
     0.90s  5.13% 88.99%      0.90s  5.13%  hash/adler32.update
     0.80s  4.56% 93.55%      0.81s  4.62%  compress/flate.(*deflateFast).matchLen
     0.29s  1.65% 95.21%      0.31s  1.77%  compress/flate.(*huffmanEncoder).bitCounts
     0.12s  0.68% 95.89%      0.12s  0.68%  runtime.asyncPreempt
     0.11s  0.63% 96.52%      1.04s  5.93%  compress/flate.(*deflateFast).encode
(pprof) disasm png.abs8
Total: 17.53s
(pprof)

$ go version
go version go1.17.6 windows/amd64

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\a3367\AppData\Local\go-build
set GOENV=C:\Users\a3367\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\a3367\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\a3367\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17.6
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
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 -fmessage-length=0 -fdebug-prefix-map=C:\Users\a3367\AppData\Local\Temp\go-build2334633044=/tmp/go-build -gno-record-gcc-switches
gdb --version: GNU gdb (GDB) 8.1

[huoshaochang]

The interesting thing is that if you cross-compile an amd64 version of go on an m1 mac, and then use this go to test and profile, you can successfully execute disasm in pprof.

[erifan]

Any update on this issue ? Given that gdb and perf tool are not available on m1 mac, pprof has become my first choice for debugging on m1 mac, and the ineffectiveness of disasm has caused great inconvenience.

[AlexanderYastrebov]

but if the binary (which is in wd) is explicitly passed as go tool pprof strings.test x.prof, then disasm works correctly.

It also works after second run of go test -cpuprofile=x.prof strings because build uses existing strings.test binary and new x.prof contains path to it.

[cosnicolaou]

I've done a bit of digging into this since I distinctly recall this working circa 2016-17. In short, this did work before a change to pprof that broke things initially for intel (2018 onward) and then for arm when it was introduced in 2020. Fixing pprof is easy and this fixes intel, but not arm macs. For arm, the pc values available within a running process differ from those in the executable's symbol table; this only happens for apple silicon systems and not for other arm (linux/raspberry pi) systems. The symbol table values are "correct" in the sense that objdump displays correct looking assembly code at those locations but are modified, I presume by dyld, when the executable is loaded into memory. In addition, the values change every time the process is run, suggesting that dyld is non-deterministic, which if correct, kinda sucks.

For pprof, google/pprof#313 introduced a check for 'textSegment.Addr > start' which will always fail since the text segments start at 0x100000000. The error occurs when testing for the first argument to pprof being an executable at startup (but the error is ignored there) and when attempting to load the executable when disassembly is requested. Again, no error is displayed. Fixing this fixes the problem for intel based macs, but not for arm based ones and explains why I recall this working correctly before 2018 or so. I am puzzled as to how some of the earlier notes on this thread state that the problem was the executable being in an inaccessible location.

For the eg.go shown below, here's the output on an arm mac and an intel one:

apple silicon - the values change every time it is run.

❯ go build -o eg eg.go
❯ ./eg
[100aa20e0 100aa20c9 100a49030 100a730e4]
100aa20df runtime.Callers
100aa20c8 main.main
100a4902f runtime.main
❯ nm eg | grep main.main
000000010008a090 t _main.main

intel:

❯ go build -o eg eg.go
❯  ~ ./eg
[108ac55 108ac43 10317d2 105a521]
108ac54 runtime.Callers
108ac42 main.main
10317d1 runtime.main
❯  ~ nm eg | grep main.main
000000000108ac00 t _main.main

arm64 on a linux raspberry pi:

 ./eg
[8ea50 8ea39 41bb0 6b474]
8ea4f runtime.Callers
8ea38 main.main
41baf runtime.main
cnicolaou@pa-dnsmasq-2:~$ nm eg | grep main.main
000000000008ea00 T main.main

package main

import (
	"fmt"
	"runtime"
)

func main() {
	pcs := make([]uintptr, 100)
	n := runtime.Callers(0, pcs)
	pcs = pcs[:n]
	fmt.Printf("%x\n", pcs)
	frames := runtime.CallersFrames(pcs[:n])
	for {
		frame, more := frames.Next()
		if !more {
			break
		}
		fmt.Printf("%x %s\n", frame.PC, frame.Function)
	}
}

[cosnicolaou]

oh, it seems that src/runtime/pprof/proto_other.go's implementation of readMapping works only on linux - i.e. it reads /proc/self/maps which doesn't exist on macos. Maybe that should be using vmmap, or the underlying APIs that it uses?

[cosnicolaou]

And sure enough, a quick hack (that runs vmmap) shows that this, at least for one test case, works. Ideally readMappings should use mach_vm_region rather than vmmap. With this in place, another issue with pprof shows up whereby listing source code via the webui (not the cli list command) breaks. This has not worked for so long now that other bugs have crept in.

[cosnicolaou]

See https://go-review.googlesource.com/c/go/+/498375 for a proposed fix.

[cherrymui]

@cosnicolaou thanks for the CL! As you noted, it is better to use the mach_vm_region API if possible. I was actually looking into this a while ago, made some progress but hasn't finished. Would you like to give that a try? Otherwise I can resume and try that. Thanks.

[cosnicolaou]

If you give me some pointers as to how you'd like the new system call added to the runtime I can give it a try. I'm reasonably confident it will work since I already wrote a stand-alone C program to get the appropriate information, assuming you're ok with the assumption that the text section we care about is the first/lowest address? I didn't prototype any means of getting the name of the binary associated with a segment.

[cherrymui]

https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin.go this contains the syscall code. Basically, it needs a Go function like https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin.go;l=123 , an import pragma like https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin.go;l=123 , and an assembly trampoline like https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin_amd64.s;l=415.

These are defined in the runtime package. You'll need to export them to the runtime/pprof package. You could do something similar to what we did for crypto/x509: https://cs.opensource.google/go/go/+/master:src/runtime/sys_darwin.go;l=105 and https://cs.opensource.google/go/go/+/master:src/crypto/x509/internal/macos/corefoundation.go;l=62

Yeah, I tried a C program, too, but didn't get a chance to port it to the Go runtime :)

assuming you're ok with the assumption that the text section we care about is the first/lowest address?

Yes, I think that should be fine. In fact I'm not sure we actually need this assumption. I think you can look for just the executable mappings, matching with the executable segments from the binary. For disassembly we only need executable segments anyway.

[cosnicolaou]

I've spent a little time looking at this, and of course, have some questions!

1. I need access to the various C types required by mach_vm_info. I see defs_darwin.go as being the place to access these, but the comments therein about using cgo -cdefs are out of date since cdefs no longer exists so far as I can tell. Is the current practice to run cgo --godefs and then to manually edit the defs_darwin_.go files? I found https://go-review.googlesource.com/c/go/+/496081 but I can't tell how the edits to the _.go files were achieved - I find it hard to believe they were hand edits, but I don't see how!
2. I need to determine the current processes mach task/port info which is available as an extern variable in the mach_init.h, accessing it via cgo is straightforward, but I assume we do not want to use cgo for this. I haven't been able to figure out how to get go assembly to refer to a variable defined in a library, or rather all my variations of go:cgp_import_dynamic have failed. Do you have any suggestions for this?
   Thanks for the help with this!

[ianlancetaylor]

@cosnicolaou I'm sorry to say that in the runtime package it's pretty much hand-editing these days for new constants and types. Getting back to a sane state is #23341.

[cosnicolaou]

@ianlancetaylor thanks for responding so quickly! I'll just hand edit things which is fine, since it's not a lot of code. Do you have any suggestions for 2? Thanks!

[ianlancetaylor]

You need to access a global variable defined in C code that is always linked in? Is that correct? And there is no C function that returns the value?

I'm not sure that a go:linkname directive will work here. The best bet might be assembler code. But it sounds like you've already tried that. What goes wrong?

[cherrymui]

For 2, I think cgo_import_dynamic is the right answer. Currently I think most use cases are for functions, not variables. So it is possible that the linker just doesn't handle variables well. I can take a look.

[cosnicolaou]

The variable is 'mach_task_self_' declared as an extern in mach/mach_init.h, as 'extern mach_port_t mach_task_self_;' and is initialized by the OS when a process starts. I've tried referencing it from go assembly, as in: TEXT main·mach_task_self(SB),NOSPLIT,$0 //MOVD $100, R0 MOVD mach_task_self_<>+0(SB), R0 MOVD R0, ret+8(SP) RET with various attempts of cgo_import_dynamic, none of which work. I believe the syntax for cgo_import_dynamic is cgo_import_dynamic 'my-name-for-symbol' 'name-of-symbol-in-library'. My C program that accesses it only depends on libSystem, so I assume that this is the correct library to use. It appears undefined in the executable as _mach_task_self_ , hence I believe that its name in the library is also _mach_task_self_. This suggests that the following line, in a go file in the same package as the above assembly file, should work. //go:cgo_import_dynamic mach_task_self_ _mach_task_self_ "/usr/lib/libSystem.B.dylib" I get a linker error of `main.mach_task_self: relocation target mach_task_self_ not defined`. Would you expect this to work? Or am I missing something? I've tried many combinations of names, with/without leading underscores, the Core foundation libraries also. I've never used this part of the system before so it's hard for me to know if I'm messing things up or if it's a bug somewhere. Cheers, Cos.

…

On Wed, Jun 7, 2023 at 12:34 PM cherrymui ***@***.***> wrote: For 2, I think cgo_import_dynamic is the right answer. Currently I think most use cases are for functions, not variables. So it is possible that the linker just doesn't handle variables well. I can take a look. — Reply to this email directly, view it on GitHub <#50891 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCMUYDVJHCMVLNQ6CWVASTXKDJUZANCNFSM5NBQ3LLQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ianlancetaylor]

I don't know if this is the problem, but in this line:

MOVD mach_task_self_<>+0(SB), R0

you don't want the <> there. I would write this more like

MOVD $mach_task_self_(SB), R0 # puts address of variable into R0
MOVD 0(R0), R0 #load value of variable into R0

[cherrymui]

I took a look at the linker code and I think we just don't handle cgo_import_dynamic for variables well (because we never needed it before). I'll see if I can make the linker handle this. Thanks.

[cosnicolaou]

Ah yes, Ian's suggestion that definitely helps - I forgot to remove the <> when trying out different data approaches. Now I get the error below:
main.mach_task_self: program too large, address relocation distance = -4295532544

Which digging into the linker shows that a value is never set for the external symbol which could be because either it doesn't exist or the linker doesn't handle variables as well as functions for the cgo pragmas. Sounds like the latter. I extracted the libraries from the shared cache and found that this symbol is defined in the lowest level dyld library rather than libSystem (see below), but making that change to the cgo_import doesn't help, so I think it is the linker.

$nm ./libraries/usr/lib/dyld | grep mach_task_self
00000001db3ff6f0 s mach_task_self

[cherrymui]

Yeah, it misses some case in the linker. The patch below seems to make it work:

diff --git a/src/cmd/link/internal/amd64/asm.go b/src/cmd/link/internal/amd64/asm.go
index c91e37584c..0a76c71dc5 100644
--- a/src/cmd/link/internal/amd64/asm.go
+++ b/src/cmd/link/internal/amd64/asm.go
@@ -38,6 +38,7 @@ import (
        "cmd/link/internal/sym"
        "debug/elf"
        "log"
+       "fmt"
 )
 
 func PADDR(x uint32) uint32 {
@@ -251,6 +252,20 @@ func adddynrel(target *ld.Target, ldr *loader.Loader, syms *ld.ArchSyms, s loade
                        // nothing to do, the relocation will be laid out in reloc
                        return true
                }
+               if r.Type() == objabi.R_PCREL && ldr.SymType(s) == sym.STEXT && target.IsDarwin() {
+                       fmt.Println("XXX adddynrel", ldr.SymName(s), ldr.SymName(targ))
+                       ld.AddGotSym(target, ldr, syms, targ, 0)
+                       // turn LEAQ symbol address to MOVQ of GOT entry
+                       su := ldr.MakeSymbolUpdater(s)
+                       if r.Off() >= 2 && su.Data()[r.Off()-2] == 0x8d {
+                               su.MakeWritable()
+                               su.Data()[r.Off()-2] = 0x8b
+                               su.SetRelocSym(rIdx, syms.GOT)
+                               su.SetRelocAdd(rIdx, int64(ldr.SymGot(targ)))
+                               return true
+                       }
+                       log.Fatal("R_PCREL reloc to SDYNIMPORT symbol not preceded by LEAQ instruction")
+               }
                if target.IsExternal() {
                        // External linker will do this relocation.
                        return true

(Currently AMD64 internal linking mode only. I still need to do external linking mode (i.e. linking with cgo) and ARM64.)

With this patch, this seems to work: in Go, add

//go:cgo_import_dynamic libc_mach_task_self_ mach_task_self_ "/usr/lib/libSystem.B.dylib"

and in assembly,

	MOVQ	$libc_mach_task_self_(SB), AX
	MOVQ	(AX), AX
	MOVQ	AX, ret+0(FP)

Thanks.

[cherrymui]

diff --git a/src/cmd/link/internal/amd64/asm.go b/src/cmd/link/internal/amd64/asm.go
index c91e37584c..b6aae0039a 100644
--- a/src/cmd/link/internal/amd64/asm.go
+++ b/src/cmd/link/internal/amd64/asm.go
@@ -38,6 +38,7 @@ import (
        "cmd/link/internal/sym"
        "debug/elf"
        "log"
+       "fmt"
 )
 
 func PADDR(x uint32) uint32 {
@@ -251,6 +252,24 @@ func adddynrel(target *ld.Target, ldr *loader.Loader, syms *ld.ArchSyms, s loade
                        // nothing to do, the relocation will be laid out in reloc
                        return true
                }
+               if r.Type() == objabi.R_PCREL && ldr.SymType(s) == sym.STEXT && target.IsDarwin() {
+                       fmt.Println("XXX adddynrel", ldr.SymName(s), ldr.SymName(targ))
+                       // turn LEAQ symbol address to MOVQ of GOT entry
+                       su := ldr.MakeSymbolUpdater(s)
+                       if r.Off() >= 2 && su.Data()[r.Off()-2] == 0x8d {
+                               su.MakeWritable()
+                               su.Data()[r.Off()-2] = 0x8b
+                               if target.IsInternal() {
+                                       ld.AddGotSym(target, ldr, syms, targ, 0)
+                                       su.SetRelocSym(rIdx, syms.GOT)
+                                       su.SetRelocAdd(rIdx, int64(ldr.SymGot(targ)))
+                               } else {
+                                       su.SetRelocType(rIdx, objabi.R_GOTPCREL)
+                               }
+                               return true
+                       }
+                       log.Fatal("R_PCREL reloc to SDYNIMPORT symbol not preceded by LEAQ instruction")
+               }
                if target.IsExternal() {
                        // External linker will do this relocation.
                        return true

This should handle external linking. Still need to do ARM64. Thanks.

[cosnicolaou]

ok, I don't have access to an intel mac right now so I tried the above in the arm64/asm.go. Unfortunately, I think a larger change is required. adddynrel is called for the symbol main.get_mach_task_self and a targ of libc_mach_task_self, but the type of the relocation is R_ADDRARM64 which is not caught by any of the switch arms in adddynrel. Note that main.get_mach_task_self is the function that references the variable. Hope this helps!

[cherrymui]

@cosnicolaou this is the ARM64 version. It has different relocation types and instructions. Hopefully this will work. Thanks!

diff --git a/src/cmd/link/internal/arm64/asm.go b/src/cmd/link/internal/arm64/asm.go
index 312ee27aa6..88ead8d897 100644
--- a/src/cmd/link/internal/arm64/asm.go
+++ b/src/cmd/link/internal/arm64/asm.go
@@ -306,6 +306,36 @@ func adddynrel(target *ld.Target, ldr *loader.Loader, syms *ld.ArchSyms, s loade
                su.SetRelocAdd(rIdx, int64(ldr.SymPlt(targ)))
                return true
 
+       case objabi.R_ADDRARM64:
+               if targType == sym.SDYNIMPORT && ldr.SymType(s) == sym.STEXT && target.IsDarwin() {
+                       fmt.Println("XXX adddynrel", ldr.SymName(s), ldr.SymName(targ))
+                       // turn MOVD $sym (adrp+add) into MOVD sym@GOT (adrp+ldr)
+                       su := ldr.MakeSymbolUpdater(s)
+                       data := ldr.Data(s)
+                       off := r.Off()
+                       if int(off+8) > len(data) {
+                               ldr.Errorf(s, "unexpected R_ADDRARM64 reloc for dynamic symbol %s", ldr.SymName(targ))
+                               return false
+                       }
+                       o := target.Arch.ByteOrder.Uint32(data[off+4:])
+                       if o>>24 == 0x91 { // add
+                               // rewrite to ldr
+                               o = (0xf9 << 24) | 1<<22 | (o & (1<<22 - 1))
+                               su.MakeWritable()
+                               su.SetUint32(target.Arch, int64(off+4), o)
+                               if target.IsInternal() {
+                                       ld.AddGotSym(target, ldr, syms, targ, 0)
+                                       su.SetRelocSym(rIdx, syms.GOT)
+                                       su.SetRelocAdd(rIdx, int64(ldr.SymGot(targ)))
+                                       su.SetRelocType(rIdx, objabi.R_ARM64_PCREL_LDST64)
+                               } else {
+                                       su.SetRelocType(rIdx, objabi.R_ARM64_GOTPCREL)
+                               }
+                               return true
+                       }
+                       ldr.Errorf(s, "unexpected R_ADDRARM64 reloc for dynamic symbol %s", ldr.SymName(targ))
+               }
+
        case objabi.R_ADDR:
                if ldr.SymType(s) == sym.STEXT && target.IsElf() {
                        // The code is asking for the address of an external

I'll clean it up and turn it into a CL. Thanks.

[cosnicolaou]

Yep - it does indeed work for arm64! Thanks! I'll try the intel version when I get back home in a week or so and have access to an intel mbp.

[gopherbot]

Change https://go.dev/cl/501855 mentions this issue: cmd/link: handle dynamic import variables on Darwin

[cosnicolaou]

FYI, I have the arm version of vm_region_info working. What are your plans for merging the linker changes and how should I construct the PRs for my changes - i.e. would you like to see one PR with the mach_vm_region assembly code and a second one with the pprof mapping changes, or would you prefer one? I would assume one, but lmk.

[cherrymui]

This is great! Thanks.

We are currently in the freeze for Go 1.21 release, so I have to wait for the tree opens (probably late July) then I can submit the linker CL. (In the meantime, feel free to copy that code into your CL, if that's easier for you.)

For your change, yeah, a single CL is fine. Thanks.

[cosnicolaou]

Take a look at https://go-review.googlesource.com/c/go/+/503919 when you have a moment, it includes your changes too.

[gopherbot]

Change https://go.dev/cl/503919 mentions this issue: runtime,runtime/pprof: fixes support for assembler output

[gopherbot]

Change https://go.dev/cl/516156 mentions this issue: runtime/pprof: correct field alignment in machVMRegionBasicInfoData

[gopherbot]

Change https://go.dev/cl/518315 mentions this issue: runtime/pprof: don't run TestVMInfo on ios