llef: init at unstable-2023-10-18

[nrabulinski]

Description of changes

LLEF is an LLDB plugin to make it more usable for low-level RE and VR. Similar to GEF, but for LLDB.
I packaged it the same way we currently package similar GDB plugins, such as the aforementioned GEF or pwndbg. I did not need to add any Python dependencies as (at least as of now) LLEF doesn't need any.

I also added meta.mainProgram to lldb as I used lib.getExe as an argument to makeWrapper.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/2839

[RaitoBezarius]

Shouldn't this package ends up in the llvmPackages hierarchy rather?
This way, you can do llvmPackages_15.lldbPlugins.llef for example.

Or I would rewire a lldbPlugins attrset inside of llvmPackages and reinject lldb from there. Otherwise, it's hard to have coherent package sets.

[nrabulinski]

I did as you requested @RaitoBezarius, but now there's another problem - LLDB 15 and 16 (LLEF specifically says they're targetting 15+) with LLEF are failing to launch because python cannot find the lldb package, even though when I try to inject lldb from llvmPackages_14 everything works. This is on macOS Sonoma 14.0, MacBook with an M1 processor

[nrabulinski]

I'm so sorry if my previous rebase pinged anybody I really hope it didn't 😅

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/3145

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/3191

[RaitoBezarius]

I did as you requested @RaitoBezarius, but now there's another problem - LLDB 15 and 16 (LLEF specifically says they're targetting 15+) with LLEF are failing to launch because python cannot find the lldb package, even though when I try to inject lldb from llvmPackages_14 everything works. This is on macOS Sonoma 14.0, MacBook with an M1 processor

Can you rebase and look if this is still the case? Apologies for getting back to you, it fell too far in my shortlist. We fixed some LLDB stuff recently.

stale

[nrabulinski]

@RaitoBezarius it does indeed work! I still need to set LLDB_DEBUGSERVER_PATH manually, but that's to be expected with lldb from nixpkgs on MacOS

[RaitoBezarius]

@RaitoBezarius it does indeed work! I still need to set LLDB_DEBUGSERVER_PATH manually, but that's to be expected with lldb from nixpkgs on MacOS

Awesome news! Could this LLDB_DEBUGSERVER_PATH be wired somehow in a wrapper or does it not make sense? Once we are good, please give me the ping for the final merge. I really apologize for making you wait for so long.

[nrabulinski]

@RaitoBezarius no, that's fine. I mentioned the debugserver path in #277958 (comment). Not sure if it makes sense for a nixpkgs wrapper since it's a MacOS impurity and requires Xcode to be installed globally. I don't know enough about lldb to say whether we can manage it in some other way

[nrabulinski]

Apparently the debugserver is inside LLVM's repository, not sure why we're not building it. Or maybe we are and simply aren't signing the lldb binary properly. https://lldb.llvm.org/resources/build.html has more info on that

[RaitoBezarius]

cc @reckenrode for the macOS bits

[nrabulinski]

Another option would be to set LLDB_USE_SYSTEM_DEBUGSERVER or whatever that flag is called and just require people to have Xcode installed as we already do for some of the stuff 😅

[reckenrode]

debugserver presumably isn’t built because it requires code-signing. See #18420.

lldb in nixpkgs due to #252838, though I don’t know if it’s related to debugserver issue.

[nrabulinski]

Aha, we already do exactly that - set the system debugserver flag, it's simply that lldb can't find it because it's not in path nor can it find the support directory since it's not located along with Xcode (logs from lldb when I try to launch a process without explicitly specifying the debugserver path):

 HostInfoMacOSX::ComputeSupportExeDirectory(): failed to find support directory
 support exe dir -> `(empty)`
 Process::SetExitStatus (status=-1 (0xffffffff), description="unable to locate debugserver")

[nrabulinski]

Oh, you already linked a related issue, yeah I believe it's related @reckenrode

[nrabulinski]

Here's the code responsible for finding debugserver, if it's not explicitly set with LLDB_DEBUGSERVER_PATH https://github.com/llvm/llvm-project/blob/882b4fccd26264be15aed5ec531ab6c879d8cc2a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp#L914-L944

[RaitoBezarius]

Merging so that we can move the needle on the debugserver stuff. :)