Disconnect3d

@syheliel I think it is not a GDB bug. There are some valid reasons like "no stack available" and there may be others for GDB to not be able to...

Added some comments. Btw there are some things that bothers me with all the refactoring we are doing: * long namespaces, aka: `pwndbg.gdblib.config.syntax_highlight` is long to read/write ;p * duplicated...

> Can you elaborate on this one? Are you saying we normally do import pwndb.gdblib.config instead of from pwndbg.gdblib import config. I think it may be possible to switch to...

(btw conflicts :F)

> If you want to give this a shot, I'm supportive of it. But there were so many import issues last time that I don't think I'll attempt it again...

GEF also has sth around that. iirc they have some custom bp related commands for that. Pls look at it as well and document it here.

FWIW: function vs variable - I sometimes would be happy to be able to do sth like `break * ($vmmap("libchicken.so")+0x1234)` aka: set a bp in runtime determining the first vmmap...

So maybe let's go with variables for known mappings and use short names for them?: ``` $base $heap $libc $ldso ``` Any other useful ones? Also not sure if `$ldso`...

@lebr0nli what's the state of this after #1075?

@lebr0nli The weird '.' display in vmmap was caused by us fetching vmmap info the same way as we do for coredump files. This should be fixed in https://github.com/pwndbg/pwndbg/pull/1149 Regarding...