[all-commits] [llvm/llvm-project] 397696: [lldb][Mach-O] Don't read symbol table of speciall...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 397696bb3d26c1298bf265e4907b0b6416ad59c9
      https://github.com/llvm/llvm-project/commit/397696bb3d26c1298bf265e4907b0b6416ad59c9
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2025-03-06 (Thu, 06 Mar 2025)

  Changed paths:
    M lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
    M lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
    A lldb/test/API/macosx/no-nlist-memory-module/Makefile
    A lldb/test/API/macosx/no-nlist-memory-module/TestNoNlistsDylib.py
    A lldb/test/API/macosx/no-nlist-memory-module/has-nlists.c
    A lldb/test/API/macosx/no-nlist-memory-module/main.c
    A lldb/test/API/macosx/no-nlist-memory-module/no-nlist-sect.s
    A lldb/test/API/macosx/no-nlist-memory-module/no-nlists.c

  Log Message:
  -----------
  [lldb][Mach-O] Don't read symbol table of specially marked binary (#129967)

We have a binary image on Darwin that has no code, only metadata. It has
a large symbol table with many external symbol names that will not be
needed in the debugger. And it is possible to not have this binary on
the debugger system - so lldb must read all of the symbol names out of
memory, one at a time, which can be quite slow.

We're adding a section __TEXT,__lldb_no_nlist, to this binary to
indicate that lldb should not read the nlist symbols for it when we are
reading out of memory. If lldb is run with an on-disk version of the
binary, we will load the symbol table as we normally would, there's no
benefit to handling this binary differently.

I added a test where I create a dylib with this specially named section,
launch the process. The main binary deletes the dylib from the disk so
lldb is forced to read it out of memory. lldb attaches to the binary,
confirms that the dylib is present in the process and is a memory
Module. If the binary is not present, or lldb found the on-disk copy
because it hasn't been deleted yet, we delete the target, flush the
Debugger's module cache, sleep and retry, up to ten times. I create the
specially named section by compiling an assembly file that puts a byte
in the section which makes for a bit of a messy Makefile (the pre-canned
actions to build a dylib don't quite handle this case) but I don't think
it's much of a problem. This is a purely skipUnlessDarwin test case.

rdar://146167816



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications