delve
delve copied to clipboard
Load dynamic libraries on darwin
I just get a bunch of errors like this:
(dlv) libraries
0. 0x0 /usr/lib/dyld
Load error: invalid magic number in record at byte 0x0
1. 0x0 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Load error: open /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation: no such file or directory
2. 0x0 /usr/lib/libobjc.A.dylib
Load error: open /usr/lib/libobjc.A.dylib: no such file or directory
3. 0x0 /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
Load error: open /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal: no such file or directory
4. 0x0 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
Load error: open /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: no such file or directory
5. 0x0 /usr/lib/liboah.dylib
Load error: open /usr/lib/liboah.dylib: no such file or directory
6. 0x0 /usr/lib/libfakelink.dylib
Load error: open /usr/lib/libfakelink.dylib: no such file or directory
7. 0x0 /usr/lib/libicucore.A.dylib
Load error: open /usr/lib/libicucore.A.dylib: no such file or directory
8. 0x0 /usr/lib/libSystem.B.dylib
Load error: open /usr/lib/libSystem.B.dylib: no such file or directory
9. 0x0 /System/Library/PrivateFrameworks/SoftLinking.framework/Versions/A/SoftLinking
Load error: open /System/Library/PrivateFrameworks/SoftLinking.framework/Versions/A/SoftLinking: no such file or directory
...
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:
- 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
- ???
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.GOOScheck 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.
Hello, do you have capacity to work on this issue? Otherwise I may close it and you can submit a new PR when you have cycles.
I actually looked into this last month and, even after they were updated our builders still had the buggy version of dsymutil. Maybe the recently released version of macOS doesn't.
Going to go ahead and close this PR since there hasn't been any activity in some time. Feel free to resubmit when you have capacity to work on this.