Open kepkin opened 4 months ago
I actually debugged our plugin with Krakend in VS Code. But I haven't tried listing library.
It won't load any OSX specific library, but go modules work. Maybe I should filter OSX .dylib?
I've dug a little bit. So those libraries won't load, cause they are universal binaries.
% lipo -archs /usr/lib/dyld
i386 x86_64 arm64e
However GO builds only one architecture (here are my minimal cmd and plugin files)
% lipo -archs cli-plugin
arm64
% lipo -archs plug.so
arm64
In this PR I would like to give opportunity to debug GO plugin on OSX (I suppose the most common case). And then fix issue with loading libraries which are compiled as universal binaries.
Here is a recording how it works https://asciinema.org/a/ePsIt72qx5C9aLsNe57dKdDEg
Regarding universal binaries. I can either skip them loading or leave as it is now.
In general this is good, however there is a problem. We have a bunch of tests for plugin debugging, these are currently disabled by a runtime.GOOS
check in WithPlugins
(which is in pkg/proc/test/support.go).
That check should be changed, however when you change it you will see that a bunch of tests in CI will start to fail. The reason is that the vast majority of macOS versions ship with a broken build of dsymutil, specifically the bug fixed by https://github.com/llvm/llvm-project/commit/10539ec2cf69fa8433840c9ddd6a56b8e2735e7a.
So I think we (@derekparker and I) need to decide what the behavior of delve is going to be in those cases:
In general this is good, however there is a problem. We have a bunch of tests for plugin debugging, these are currently disabled by a
runtime.GOOS
check inWithPlugins
(which is in pkg/proc/test/support.go). That check should be changed, however when you change it you will see that a bunch of tests in CI will start to fail. The reason is that the vast majority of macOS versions ship with a broken build of dsymutil, specifically the bug fixed by llvm/llvm-project@10539ec.So I think we (@derekparker and I) need to decide what the behavior of delve is going to be in those cases:
- we just let it be silently broken and skip those tests in CI
- we only merge this PR after we have code to detect plugins with broken debug_frame sections
- ???
Apologies on the late response here.
I think we go with option 2, and we use that to selectively skip tests in CI.
Hi.
I'm pretty busy on my main job. However if you give me a hint on how to to detect broken debug_frame sections, I might be able to do this on weekends.
I think it would be acceptable to do this by checking what macOSDebugFrameBugWorkaround
does (in pkg/proc/bininfo.go). If the workaround is applied then dynamic libraries shouldn't be loaded.
I just get a bunch of errors like this: