Pwndbg: Cannot break on a symbol from a shared library

[stnevans]

Description

Pwndbg makes it impossible to set breakpoints on symbols from shared libraries that haven't yet loaded. This is because we run set confirm off in __init__.py

Steps to reproduce

$gdb binary
pwndbg: loaded 178 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./binary...(no debugging symbols found)...done.
pwndbg> b read
Function "read" not defined.

Expected behaviour:

$gdb binary
pwndbg: loaded 178 commands. Type pwndbg [filter] for a list.
pwndbg: created $rebase, $ida gdb functions (can be used with print/break)
Reading symbols from ./binary...(no debugging symbols found)...done.
pwndbg> b read
Function "read" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (read) pending.

My setup

Gdb: 7.11.1
Pwndbg: 1.1.0 build: 93aabaa

How to manually fix:

set confirm on allows you to set breakpoints on currently nonexistent symbols.

[stnevans]

I was looking for a way to get around not running set confirm off in the init as it's very nice, but I can't see anything that wouldn't require a large amount of work.
The initial thing that came to mind was making commands called "b","br","bre","brea", and "break" which just call gdb.Breakpoint() on their argument.
The issue with doing this is that it appears that the command parsing itself actually tries to resolve symbols.

I personally would be fine with leaving pwndbg in the current configuration with the knowledge that users who want to set breakpoints on symbols from shared libraries would just have to run set confirm on, but I thought it would be worth seeing if anyone had other thoughts.

EDIT:
On further reading, it looks like we might just be able to run set breakpoint pending on. That seems like a better solution.

[disconnect3d]

Hmm, that's an interesting point. I think I used to see that Make breakpoint pending on future shared library load? (y or [n]) question asked by gdb with pwndbg many times, but I can't reproduce it huh.

The potential problem with set breakpoint pending on is that if users mistype a function name they will not end up in it... It might be annoying.

Since you checked it, why can't we sett set confirm yes during init?

[stnevans]

The potential problem with set breakpoint pending on is that if users mistype a function name they will not end up in it... It might be annoying.

That's true.

Since you checked it, why can't we sett set confirm yes during init?

I actually think we could do set confirm on. I assumed there was some reason that pwndbg turned confirm off in the first place though, and presumably doing this would negate that. I'm not really sure of this though. I'm also not sure exactly what the value of confirm changes.

[disconnect3d]

@zachriggle @anthraxx @gsingh93 do you possibly know why do we do set confirm off? :D

[disconnect3d]

@stnevans Let's just throw set confirm on (or remove setting it off it if it's default or sth).

If it breaks something we can always revert it.

[disconnect3d]

@stnevans bump, can you send a PR with that? :)

[stnevans]

@disconnect3d I'm honestly not sure if it's worth doing this. I played around a little bit, and the following message is annoying.
```A debugging session is active.

Inferior 1 [process 10998] will be killed.

Quit anyway? (y or n) y
```
Given that no one had ever complained about it before this, it also doesn't seem like a major issue. It might be worth just closing the issue and leaving it so that anyone who wants to send breakpoints on unloaded shared library functions can see how to do so.