I read the LLDB troubleshooting page [1] and found interesting quotes: > When setting breakpoints in implementation source files (.c, cpp, cxx, .m, .mm, etc), LLDB by > default will only search for compile units whose filename matches. > [...] > % echo "settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit > This tells LLDB to always look in all compile units and search for breakpoint locations > by file and line even if the implementation file doesn’t match. Setting breakpoints in header > files always searches all compile units because inline functions are commonly defined in > header files and often cause multiple breakpoints to have source line information that matches > many header file paths.
In my email before I did this $ lldb -x -b -o "breakpoint set --file foo.h --name foo" ./a.out I now added the breakpoint strategy and ran the above command without the -x in order to pick up the LLDB init code. Still no luck. [1]: https://lldb.llvm.org/use/troubleshooting.html#troubleshooting Am Mo., 4. Nov. 2019 um 13:56 Uhr schrieb Konrad Kleine <kkle...@redhat.com >: > Hello, > > I noticed this behavior for LLDB under Linux when setting a breakpoint on > a file and a function name: > > When doing "breakpoint set --file <filename> --name <function-name>", the > <filename> is that of the compile unit (CU) and not necessarily where the > function is defined. This is not what an end-user expects. > > Take this simple example program: > > $ cat foo.h > int foo(){ return 42; } > > $ cat main.c > #include "foo.h" > int main(){return foo();} > > $ clang -g main.c > > As you can see, the function foo is defined in foo.h so it seems natural > to set a breakpoint on foo.h, doesn't it? > > $ lldb -x -b -o "breakpoint set --file foo.h --name foo" ./a.out > (lldb) target create "./a.out" > Current executable set to './a.out' (x86_64). > (lldb) breakpoint set --file foo.h --name foo > Breakpoint 1: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > > Apparently, LLDB cannot find the symbol like this. Let's try the only > other file that we have in the project: > > $ lldb -x -b -o "breakpoint set --file main.c --name foo" ./a.out > (lldb) target create "./a.out" > Current executable set to './a.out' (x86_64). > (lldb) breakpoint set --file main.c --name foo > Breakpoint 1: where = a.out`foo + 4 at foo.h:1:12, address = > 0x0000000000401114 > > Isn't that remarkable? LLDB uses main.c as the file to search in but then > finds it in foo.h. > > Let's recall what the parameters --file and --name mean: > > -n <function-name> ( --name <function-name> ) > Set the breakpoint by function name. Can be repeated multiple > times to make one breakpoint for multiple names > > -f <filename> ( --file <filename> ) > Specifies the source file in which to set this breakpoint. > Note, by default lldb only looks for files that are #included if they use > the standard include file extensions. To > set breakpoints on .c/.cpp/.m/.mm files that are #included, > set target.inline-breakpoint-strategy to "always". > > Let's check if setting the target.inline-breakpoint strategy to "always" > changes something: > > $ lldb -x -b -o "settings set target.inline-breakpoint-strategy always" > -o "breakpoint set --file foo.h --name foo" ./a.out > (lldb) target create "./a.out" > Current executable set to './a.out' (x86_64). > (lldb) settings set target.inline-breakpoint-strategy always > (lldb) breakpoint set --file foo.h --name foo > Breakpoint 1: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > > No, it didn't change anything. > > The only evidence for my assumption that LLDB uses the CU's name for > --file is the DWARF dump: > > $ llvm-dwarfdump a.out > a.out: file format ELF64-x86-64 > > .debug_info contents: > 0x00000000: Compile Unit: length = 0x00000060 version = 0x0004 abbr_offset > = 0x0000 addr_size = 0x08 (next unit at 0x00000064) > > 0x0000000b: DW_TAG_compile_unit > DW_AT_producer ("clang version 8.0.0 (Fedora 8.0.0-3.fc30)") > DW_AT_language (DW_LANG_C99) > DW_AT_name ("main.c") > DW_AT_stmt_list (0x00000000) > DW_AT_comp_dir ("/home/kkleine") > DW_AT_low_pc (0x0000000000401110) > DW_AT_high_pc (0x000000000040113a) > > 0x0000002a: DW_TAG_subprogram > DW_AT_low_pc (0x0000000000401110) > DW_AT_high_pc (0x000000000040111b) > DW_AT_frame_base (DW_OP_reg6 RBP) > DW_AT_name ("foo") > DW_AT_decl_file ("/home/kkleine/./foo.h") > DW_AT_decl_line (1) > DW_AT_type (0x0000005c "int") > DW_AT_external (true) > > 0x00000043: DW_TAG_subprogram > DW_AT_low_pc (0x0000000000401120) > DW_AT_high_pc (0x000000000040113a) > DW_AT_frame_base (DW_OP_reg6 RBP) > DW_AT_name ("main") > DW_AT_decl_file ("/home/kkleine/main.c") > DW_AT_decl_line (2) > DW_AT_type (0x0000005c "int") > DW_AT_external (true) > > 0x0000005c: DW_TAG_base_type > DW_AT_name ("int") > DW_AT_encoding (DW_ATE_signed) > DW_AT_byte_size (0x04) > > As you can see, the DWARF is very small and simply. The function foo has a > DW_AT_decl_file which is probably used to report the breakpoint location > but for the actual filtering, it seems as if the CU is crucial for the > --file argument. > > The only reasonable implementation for --file to me seems to be when > combined with the line number: > > $ lldb -x -b -o "breakpoint set --file foo.h --line 1" ./a.out > (lldb) target create "./a.out" > Current executable set to './a.out' (x86_64). > (lldb) breakpoint set --file foo.h --line 1 > Breakpoint 1: where = a.out`foo + 4 at foo.h:1:12, address = > 0x0000000000401114 > > This works as expected. > > For myself I think that the --file --name combination works not like an > end-user expects because in bigger projects you typically look at the > definition of foo and want to pause, when execution reaches this. You don't > care if a function is inlined or in which CU the function is located. > Moreover I think the DWARF actually supports more than enough information > with the DW_TAG_subprogram DIE's attributes for the file and line number. > Enough to filter by file and line number. > > IMHO we should come up with a very strong argument to justify that --file > limits by a CU's DW_AT_name. To me the only reasonable argument is speed. > But speed doesn't justify such a drastic limitation. Shouldn't we rather > change what --file currently does and keep the old behavior when using --cu > instead of --file? > > - Konrad > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
