Projects needing CGO_ENABLED=1 cause "could not find rodata struct member" on M1 MacOS about delve HOT 15 OPEN

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

from delve.

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.

from delve.

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++",
            }
        }
    ]
}

from delve.

Are you using Xcode 15?

from delve.

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

from delve.

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.

from delve.

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?

from delve.

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.

from delve.

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?

from delve.

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.

from delve.

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.

from delve.

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/[email protected]

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 $

from delve.

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.

from delve.

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.

from delve.