Projects needing CGO_ENABLED=1 cause "could not find rodata struct member" on M1 MacOS

[Rocco-Gossmann]

Please answer the following before submitting your issue:

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.22.1
Build: $Id: 0c3470054da6feac5f6dcf3e3e5144a64f7a9a48 $

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

go version go1.22.1 darwin/arm64

3. What operating system and processor architecture are you using?
   MacOS 13.6 M1 MacBook Air (2020)

uname -a 

Darwin ... 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:30 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_ARM64_T8103 arm64

4. What did you do?
   Setup a Project, that uses Raylib-Go and needs CGO_ENABLED=1 to be set.
   As soon as any code using the raylib-go/raylib package is added Delve crashed.

5. What did you expect to see?
   The Debugger working as it did before I added the raylib-go/raylib code.

6. What did you see instead?
   It crashed with the message

could not find rodata struct member

The same happens on other projects too. So it is not related to Raylib-Go alone.
One of my projects (https://github.com/rocco-gossmann/tnt) requires CGO_ENABLED=1 to use the SQLite Database. It has the same issues.

See Video for a Demonstration.

2024-04-14_14-58-10.mov

[aarzilli]

Are you using Xcode 15?

[aarzilli]

cc @cherrymui are there already known situations where debug info are not produced using cgo on macos?

[Rocco-Gossmann]

Are you using Xcode 15?

It should be XCode Commandline Tools version 15.

I recently removed the XCode App itself (it took to much space). But the CLI tools are still there.
Maybe the AppCleaner I used removed to much of the App? No idea, I got a used MacBook and have only used MacOS for a couple of month now.

Edit:
I reinstalled XCode 15.2 now. Nothing changed.

[cherrymui]

cc @cherrymui are there already known situations where debug info are not produced using cgo on macos?

I'm not aware of issues like this. I just tried building a cgo program on Mac and it comes with debug info as expected.

Could you share the command that the program is built with?

[Rocco-Gossmann]

Could you share the command that the program is built with?

For the demonstration video I've used what ever VSCode (VSCodium) has by default (I don'
t know sorry). You can see the config at the beginning of the Video.

As for my own project, I build it with:

CGO_ENABLED=1 go build -ldflags="-X main.Version=$(DEVVERSION)" -o ./tnt

You can check the command in the Projects Makefile.
https://github.com/Rocco-Gossmann/tnt/blob/332a1a6638ac63bf911df76a4767fd02345edeeb/Makefile#L19

The Project can compile without CGO_ENABLED (but the cross-builds won't run anywhere else without) .

I then started to debug it with dlv exec ./tnt.
When compiled without CGO_ENABLED, the debugger starts fine.
When compiled with, I get the same error.

[ltagliamonte-dd]

Hi there!
i'm having the exact same problem, i'm running the same delve and golang version.
I'm a newer Mac:

uname -a
Darwin K36MD3JV22 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:37 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6031 arm64

i'm running VsCode:

Version: 1.88.1 (Universal)
Commit: e170252f762678dec6ca2cc69aba1570769a5d39
Date: 2024-04-10T17:42:52.765Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.4.0

[jason-lynch]

I'm also experiencing this issue, but I was able to work around it by using the -ldflags=-linkmode=internal build flag. I suspect that it's related to golang/go#61229.

[Rocco-Gossmann]

I'm also experiencing this issue, but I was able to work around it by using the -ldflags=-linkmode=internal build flag. I suspect that it's related to golang/go#61229.

Can confirm, that this made https://github.com/rocco-gossmann/tnt debuggable via delve.

Unfortunately, now my raylib-go project does not seem to like that flag and doesn't build at all. 😢

However, that doesn't have anything to do with Delve.
So, since the initial issue seems to be solved, this can be closed. Does anyone else want to add anything?

[aarzilli]

Issue golang/go#61229 is closed. Maybe a new one should be opened on golang/go for this, it will probably be easier to track for the compiler team if it's there.

[cherrymui]

Could you share the source code and a command (ideally without makefile) that I can reproduce? I'll try to reproduce and look into it. Thanks.

[jason-lynch]

In my case, this debug issue is happening for every Go program. The easiest repro that I've encountered is if I do this without setting that ldflag:

go install github.com/deepmap/oapi-codegen/cmd/oapi-codegen@v1.12.4

Then the resulting binary is unusable:

oapi-codegen --help
[1]    6393 killed     oapi-codegen --help

I'm not sure which system specs will be most helpful, but I'm on a MacBook Pro with an Apple M3 Max chip, running Sonoma 14.4.1:

uname -a
Darwin ... 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:37 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6031 arm64

xcode-select --version
xcode-select version 2406.

go version
go version go1.22.2 darwin/arm64

dlv version
Delve Debugger
Version: 1.22.1
Build: $Id: 0c3470054da6feac5f6dcf3e3e5144a64f7a9a48 $

[Rocco-Gossmann]

Could you share the source code and a command (ideally without makefile) that I can reproduce? I'll try to reproduce and look into it. Thanks.

I had not planned on making it public, but if it helps.
There you go:
https://github.com/Rocco-Gossmann/RayTheater---Go

just clone that:

git clone https://github.com/Rocco-Gossmann/RayTheater---Go RayTheater

cd RayTheater

go mod tidy

I tried various commands, none of which worked:

• dlv debug .
• go build -o debug.run && dlv exec debug.run
• CGO_ENABLED=1 go build -ldflags="-g" -o debug.run
• CGO_ENABLED=1 CGO_CXXFLAGS=-g CGO_CFLAGS=-g go build -o debug.run && dlv exec debug.run
• CGO_ENABLED=1 CGO_CXXFLAGS=-g CGO_CFLAGS=-g go build -ldflags=-linkmode=internal -o debug.run && dlv exec debug.run

(Interestingly enough, it seems to work fine on Asahi Linux on an M1 Mac, so the issue must be specifically MacOS related). I've heard, that Apple uses their own fork of clang, maybe that could also be a factor.

[cherrymui]

Thanks for the information. I'll try to reproduce next week.

What C compiler do you use? Do you use the one from Xcode, or a custom installation of clang (built from upstream LLVM, or not) or some other C toolchain? From what I've heard a non-Xcode C toolchain sometimes may not work very well. Thanks.

[Rocco-Gossmann]

Thanks for the information. I'll try to reproduce next week.

What C compiler do you use? Do you use the one from Xcode, or a custom installation of clang (built from upstream LLVM, or not) or some other C toolchain? From what I've heard a non-Xcode C toolchain sometimes may not work very well. Thanks.

Thank YOU for trying to help. 🤗

I'm using the clang, that came with LLVM
That is the one that makes problems.

clang --version 

Homebrew clang version 18.1.5
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin

I just figured out, that Delve works with the CC and CXX EnvVars.
So if I set them back to /usr/bin/cc and /usr/bin/c++ respectively, I can at least debug again.

CC=/usr/bin/cc CXX=/usr/bin/c++ dlv debug . 

works. 🎉

For the others, if you use VSCode.
Try this launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "env": {
                "CC": "/usr/bin/cc",
                "CXX": "/usr/bin/c++",
            }
        }
    ]
}