delve icon indicating copy to clipboard operation
delve copied to clipboard

Load dynamic libraries on darwin

Open kepkin opened this issue 1 year ago • 9 comments
trafficstars

kepkin avatar Feb 20 '24 06:02 kepkin

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

derekparker avatar Feb 22 '24 19:02 derekparker

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 avatar Feb 26 '24 16:02 kepkin

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.

kepkin avatar Feb 27 '24 16:02 kepkin

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

aarzilli avatar Feb 28 '24 14:02 aarzilli

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.

derekparker avatar Apr 11 '24 16:04 derekparker

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.

kepkin avatar Apr 23 '24 08:04 kepkin

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.

aarzilli avatar Apr 24 '24 09:04 aarzilli

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.

derekparker avatar Oct 03 '24 21:10 derekparker

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.

aarzilli avatar Oct 04 '24 08:10 aarzilli

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.

derekparker avatar Feb 03 '25 16:02 derekparker