lldb cannot resolve breakpoints freashly written to a file

[samolisov]

I load a simple dictionary application described in this tutorial in an LLDB session and set up a breakpoint to the find_word function:

(lldb) br s -n find_word

The breakpoint is set and resolved:

(lldb) br list


8: name = 'find_word', locations = 1, resolved = 1, hit count = 0
  8.1: where = dictionary`find_word + 16 at dictionary.c:109:8, address = 0x0000555555555580, resolved, hit count = 0

Everything works as it is expected:

(lldb) c
Process 2148463 stopped
* thread #1, name = 'dictionary', stop reason = breakpoint 8.1
    frame #0: 0x0000555555555580 dictionary`find_word(dictionary=0x00005555555596b0, word="romeo") at dictionary.c:109:8
   106  /* Given a binary search tree and a word, search for the word
   107     in the binary search tree. */
   108  int find_word(tree_node *dictionary, char *word) {
-> 109    if (!word || !dictionary)
   110      return 0;

Then I write the breakpoint 8 into a file:

(lldb) br write -f debug 8

The breakpoint has been written to the file debug, I see this in the file:

"BKPTResolver":{"Options":{"NameMask":[56],"Offset":0,"SkipPrologue":true,"SymbolNames":["find_word"]},"Type":"SymbolName"},"

Then I stop my lldb session, reload the debugger and restart the application

$  lldb dictionary -- romeo.txt

read the breakpoints from the debug file:

(lldb) br read -f debug

and get the pending breakpoint:

New breakpoints:
Breakpoint 1: no locations (pending).

(lldb) br list
Current breakpoints:
1: name = 'find_word', locations = 0 (pending)

I can get the idea when address-based breakpoints with fixed address may be resolved after restart due to address changes, but here I have a symbol-related breakpoint, I didn't recompile and build the binary and I believe the breakpoints should be resolved. Currently, as a workaround, a command-script or python script must be used to set breakpoints and the corresponding commands must be issued every time when the debug session starts.

Even though I attach the debugger to a running process, write breakpoints to a file, delete them and then read the breakpoints from the file, they are reloaded as pending. I didn't touched the application process and therefore no addresses in the executable should be changed.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Pavel Samolysov (samolisov)

I load a simple dictionary application described in [this tutorial](https://lldb.llvm.org/use/tutorials/script-driven-debugging.html) in an LLDB session and set up a breakpoint to the `find_word` function:

(lldb) br s -n find_word
```

The breakpoint is set and resolved:

```
(lldb) br list


8: name = 'find_word', locations = 1, resolved = 1, hit count = 0
  8.1: where = dictionary`find_word + 16 at dictionary.c:109:8, address = 0x0000555555555580, resolved, hit count = 0
```

Everything works as it is expected:

```
(lldb) c
Process 2148463 stopped
* thread #<!-- -->1, name = 'dictionary', stop reason = breakpoint 8.1
    frame #<!-- -->0: 0x0000555555555580 dictionary`find_word(dictionary=0x00005555555596b0, word="romeo") at dictionary.c:109:8
   106  /* Given a binary search tree and a word, search for the word
   107     in the binary search tree. */
   108  int find_word(tree_node *dictionary, char *word) {
-&gt; 109    if (!word || !dictionary)
   110      return 0;
```

Then I write the breakpoint 8 into a file:

```
(lldb) br write -f debug 8
```

The breakpoint has been written to the file `debug`, I see this in the file:

```
"BKPTResolver":{"Options":{"NameMask":[56],"Offset":0,"SkipPrologue":true,"SymbolNames":["find_word"]},"Type":"SymbolName"},"
```

Then I stop my lldb session, reload the debugger and restart the application
```
$  lldb dictionary -- romeo.txt
```

read the breakpoints from the `debug` file:

```
(lldb) br read -f debug
```
and get the pending breakpoint:

```
New breakpoints:
Breakpoint 1: no locations (pending).

(lldb) br list
Current breakpoints:
1: name = 'find_word', locations = 0 (pending)
```

I can get the idea when address-based breakpoints with fixed address may be resolved after restart due to address changes, but here I have a symbol-related breakpoint, I didn't recompile and build the binary and I believe the breakpoints should be resolved. Currently, as a workaround, a command-script or python script must be used to set breakpoints and the corresponding commands must be issued every time when the debug session starts.

Even though I attach the debugger to a running process, write breakpoints to a file, delete them and then read the breakpoints from the file, they are reloaded as pending. I didn't touched the application process and therefore no addresses in the executable should be changed.

</details>

[jimingham]

This seems to have broken fairly recently.

[samolisov]

It is reproduced with LLDB 21.1.5, lvm revision 8e2cd28cd4ba46613a46467b0c91b1cabead26cd and lldb version 22.0.0git (https://github.com/llvm/llvm-project.git revision a751ed97acf1ea760d6724bc6ea72b1b9b59a448).

[jimingham]

The bug was introduced in:

#135033

The logic in Module::LookupInfo::LookupInfo when the function name type is not eFunctionNameTypeAuto seems wrong. It lets the first language that recognizes the name as a possible name type get to reset the breakpoint name type to whatever it supports. If you are on a system with ObjC support and that happens to be the first language, it will say find_word looks like a selector to me... and that converts the breakpoint to a "selector only" breakpoint, which then isn't found.

[jimingham]

Still working on how to make it do the right thing.