go-delve / delve

Delve is a debugger for the Go programming language.
MIT License
22.38k stars 2.13k forks source link

Load dynamic libraries on darwin #3669

Open kepkin opened 4 months ago

derekparker commented 4 months ago

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
...
kepkin commented 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?

kepkin commented 4 months ago

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.

aarzilli commented 4 months ago

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:

  1. we just let it be silently broken and skip those tests in CI
  2. we only merge this PR after we have code to detect plugins with broken debug_frame sections
  3. ???
derekparker commented 2 months ago

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 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:

  1. we just let it be silently broken and skip those tests in CI
  2. we only merge this PR after we have code to detect plugins with broken debug_frame sections
  3. ???

Apologies on the late response here.

I think we go with option 2, and we use that to selectively skip tests in CI.

kepkin commented 2 months ago

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.

aarzilli commented 2 months ago

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.