LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

Subprojects LLDB
1

Has LLDB considered adding per-binary support for LLDB python scripts,
eg. for adding custom type summaries?

This is the equivalent GDB feature

GDB can load a custom python script from either a side-installed file
or an ELF section. This allows debugging of multiple binaries with
different implementations of the pretty-printer.

Any suggestions for LLDB workarounds would be welcome.

2

We currently have the ability to support this for ELf. It is only currently hooked up for Mach-O binaries when you have a dSYM (stand alone debug info bundle). You will want to implement this for your platform:

FileSpecList
Platform::LocateExecutableScriptingResources(Target *target, Module &module,
                                             Stream *feedback_stream) {
  return FileSpecList();
}

So given an LLDB Module (executable/shared library), find any python files that should be imported. You can take a look at what we do in PlatformDarwin:

PlatformDarwin::LocateExecutableScriptingResources()

Basically it sees if the module has a stand alone debug file, and if it does, it looks for scripting resource files that will be imported. In our case we might have and module whose path is "/tmp/a.out", we ask the symbol vendor to get the symbol file ("/tmp/a.out.dSYM"), and if it has one, this file is a bundle. Inside of this bundle we look for a "a_out.py" that is relative to the file. If that file exists, it will be pulled in automatically.

So this is possible to implement for other platforms. Seems like you can have ".debug_lldb_python_scripts" section that could specify a relative (relative to the ELF file itself) or absolute path to scripting files that should be loaded when this binary gets loaded. So that shouldn't be too hard to implement.

Let me know if you have any questions.

Greg

3

LLDB has a similar feature, except:

a) it tries to load python scripts from dSYM bundles. If you have debug info stored in foo.dSYM, it will look for foo.dSYM/Contents/Resources/Python/foo.py
As far as I know, dSYMs only exist on Apple systems, so clearly you would need to design something else to load from places other than such debug info bundles

b) the feature is off by default, but there’s a setting you can tweak to enable it. That is due to security concerns
I have given some thought to ideas in that space (e.g. code-signatures for the script files) but no code exists to back those thoughts