3

I'm trying to step through a big project >100k loc but only care about interactions with lib. Is there a way to get lldb to break on all functions declarations in once source file?

So far I've tried doing

br s -f <file> --func-regex .*

with info from gdb to lldb and gdb solution but that appears to be breaking on all function calls in the file which causes 5129 matches for a 4911 line source file.

A possible solution could be to do source regex matching to find function calls via

br s -f --source-pattern-regexp

but given C++'s ridiculous parsing rules, a regex that matches all cases is impossible.

James Deng
  • 173
  • 10
  • You could put the list of functions to break in a file as break commands. Should be easy to create from your header file. The run gdb with the -x flag: `gdb -x command_file_name` – bruceg Oct 07 '16 at 02:14
  • The problem is that I want a more generic solution and breaking on functions in headers doesn't adequately cover cases where the function isn't declared in the header such as when it's declared in the source file and passed around as a function pointer. – James Deng Oct 07 '16 at 02:35
  • Good luck. Let us know what you figure out. – bruceg Oct 07 '16 at 17:18

1 Answers1

3

The -f specification really limits the breakpoint search to the Compilation Unit defined by <file> and so it ends up including all the template instantiations that that Compilation Unit contains, which if you use any std:: stuff is generally a lot, as you have discovered.

The debugger generally does know where a function was declared (it is part of the debug info) so we could add an option to treat -f as "file of declaration" not "comp unit name". Then you could say something like:

(lldb) break set -f foo.h -f foo.cpp --match-declaration-file --func-regex .*

That would be pretty straight forward to add. If you're so inclined, please file an enhancement request to this effect to http://bugreporter.apple.com.

If you follow the convention of writing your functions like:

void A::foo()
{
  ...
}

Then you can do a source regex on "^{". That was the primary reason for this coding convention, it made the beginnings of functions really easy to pick out.

If the template instantiations are mostly coming from std, you could find the .o file and do something like (this is on OS X):

$ nm <file-basename>.o -s __TEXT __text -j | c++filt | grep -v std

That will produce a list of the non-std functions in this .o file, and then you could add break set -n to the beginning of each line and source that in.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • The `nm`-trick is amazing. If you don't know the libraries your binary is using, you can also run `ldd` on the binary and find out. Sometimes it is also helpful to run a --func-regex search narrowing down the functions by namespaces, like this: `breakpoint set --func-regex clang::format::*` – Artyom Gevorgyan Oct 11 '20 at 14:11
  • Pardon me, I meant `breakpoint set --func-regex ^clang::format::*`, otherwise functions that do not belong to the `clang::format` namespace but take parameters of type from this namespace will be selected. – Artyom Gevorgyan Oct 11 '20 at 14:31
  • Have to accept that namespace-based approach won't work either. Return types can also come from the namespace, but I am only interested in the functions from it. The described approach with `nm` is the best workaround. – Artyom Gevorgyan Oct 11 '20 at 15:25
  • Another way to do this is to write a custom breakpoint resolver. Set it at Module depth (that's the default). Your resolver will get passed a SBSymbolContext containing the module you are supposed to set the breakpoint in, and you can call SBModule.FindFunctions to get all the functions. You can get the function names from the SBFunction, and since you are in Python, you have more flexibility to filter the names as you wish. – Jim Ingham Oct 15 '20 at 00:23