To set a breakpoint on a function called YOURFUNCTION you do this:
(lldb) breakpoint set -n YOURFUNCTION
The output then could look like this:
Breakpoint 1: where = YOURTARGET`YOURFUNCTION() + 4 at YOURFILE:1:20, address = 0x01234
LLDB does a good job in finding YOURFUNCTION because, indeed,
YOURFILE contains the definition of YOURFUNCTION.
Let's say, you not only want to find YOURFUNCTION anywhere in
YOURTARGET. Say, you want to find YOURFUNCTION in the file that LLDB
found it in.
This is how you'd do that:
(lldb) breakpoint set -n YOURFUNCTION -f YOURFILE
This is where things get a bit tricky.
LLDB uses only the DW_TAG_compile_unit's name that it finds under the
Suppose this is a snippet of llvm-darfdump YOURTARGET
0x0000000b: DW_TAG_compile_unit DW_AT_name ("main.c") 0x0000002a: DW_TAG_subprogram DW_AT_name ("YOURFUNCTION") DW_AT_decl_file ("YOURFILE")
Then LLDB only looks at the file called main.c and ignores the
With this change LLDB respects the DW_AT_decl_file.
This change is aware of the target.inline-breakpoint-strategy setting and
respects it when filtering for breakpoints.
Reference for DW_AT_decl_file
For reference, here's the definition for DW_AT_decl_file from the DWARF
spec in chapter 2.14:
It is sometimes useful in a debugger to be able to associate a
declaration with its occurrence in the program source.
The value of the DW_AT_decl_file attribute corresponds to a file
number from the line number information table for the compilation unit
containing the debugging information entry and represents the source
file in which the declaration appeared (see Section 6.2 on page 148).
The value 0 indicates that no source file has been specified.
Reference to lldb-dev mailing list
I once brought this topic up on the lldb-dev mailing list
since then worked on it.