The 8f33ec4 made `pwndbg.symbol.address` to discard addresses
of symbols not mapped.
Unfortunately this broke pwndbg's `start`.
GDB's `start` puts a temporal break in `main` and pwndbg's `start` does
the same but when GDB returns the address of `main`, it returns an
offset the first time because the symbol was not mapped yet.
The offset is then discarded and pwndbg doesn't put the breakpoint when
it should.
This PR fixes pwndbg's `start` allowing `pwndbg.symbol.address` to
return offsets instead of addresses: GDB will resolve the correct
address when it builds the breakpoint and pwndbg's `start` will behave
like GDB's `start`.
* Added option to compact the register list when displayed in context view.
* Disabled compact register list as default setting.
* Moved calculate_padding method outside the compact_regs function and renamed it to calculate_padding_to_align
* Replaced custom get_text_length function with existing pwndb.color.strip function
* Moved width calculation in context_regs to top so that other function calls can reuse the calculated width value
* Clarified show-compact-regs-space configuration option description
This commit fixes the issue described in https://github.com/pwndbg/pwndbg/issues/772#issuecomment-652260420
tl;dr: when we displayed a known constant call instruction like
`call qword ptr [rip + 0x1c7d2]` when it called a known symbol we only
displayed the target address instead of the symbol.
Now, we will display only the target address.
Note that there are still cases when we can display both. This can
happen for example for a `ret` instruction (even without emulation).
This commit extends a comment around that code to give such example.
* vmmap command: show offset for single addresses
Changes vmmap display so when it is invoked with a single address, it
will also display its offset.
Before this commit:
```
pwndbg> vmmap $rsp
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
0x7ffffffde000 0x7ffffffff000 rw-p 21000 0 [stack]
```
After this commit:
```
pwndbg> vmmap $rsp
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
0x7ffffffde000 0x7ffffffff000 rw-p 21000 0 [stack] +0x1fb60
```
* Remove ugly hack :)
I believe the `arch_to_regs[pwndbg.arch.current][item]` is a dead code.
I stumbled upon this during debugging one of other issues and:
* The `arch_to_regs` is a dict mapping str -> RegisterSet objects
* So `arch_to_regs[pwndbg.arch.current]` gets a `RegisterSet`
* Now, the `RegisterSet` doesn't have a subscription (the `__getitem__` magic method)
This can also be seen below:
```
>>> pwndbg.regs.arch_to_regs
{'i386': <pwndbg.regs.RegisterSet object at 0x7f931020b048>, 'x86-64': <pwndbg.regs.RegisterSet object at 0x7f931020b080>, 'mips': <pwndbg.regs.RegisterSet object at 0x7f9310212f98>, 'sparc': <pwndbg.regs.RegisterSet object at 0x7f9310212b38>, 'arm': <pwndbg.regs.RegisterSet object at 0x7f930ee7a6a0>, 'armcm': <pwndbg.regs.RegisterSet object at 0x7f930ee7aba8>, 'aarch64': <pwndbg.regs.RegisterSet object at 0x7f931020b0b8>, 'powerpc': <pwndbg.regs.RegisterSet object at 0x7f9310212518>}
>>> pwndbg.arch.current
'x86-64'
>>> pwndbg.regs.arch_to_regs[pwndbg.arch.current]
<pwndbg.regs.RegisterSet object at 0x7f931020b080>
>>> pwndbg.regs.arch_to_regs[pwndbg.arch.current]['$rax']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'RegisterSet' object is not subscriptable
>>> pwndbg.regs.arch_to_regs[pwndbg.arch.current][0]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'RegisterSet' object does not support indexing
>>>
```
When pyelftools missed a PT_* name, invoking a `xinfo` command on a library with the missing program header crashed the `xinfo` command due to us assuming the ptype will be a string.
Instead, since pyelftoools didn't have the name, this ph is then an int.
So this commit takes this into acccount and omits those program headers that we weren't able to name due to lack of info in pyelftools.
This solution is not ideal as we might miss something, but given that we care about given program header name, I don't think it will be a big deal for us.
* Added install to apt line: fixed bug mentioned by @martinclauss in #748 that might be needed for Ubuntu <20.04.
* Added git to apt-get, which is needed for a docker run -it ubuntu
This commit fixes the issue described in #749.
During disasm output, we enhance the display to show additional information of the instructions.
When a future instruction executes a branch instruction (jmp/call), we fetch the next instruction based on the jmp/call target, as long as we can calculate it statically.
If we can calculate it statically, we will then display the target of the jmp/call as the next instruction, as e.g. in here:
```
> 0x5555555545fe <main+4> jmp main+4 <0x5555555545fe>
v
> 0x5555555545fe <main+4> jmp main+4 <0x5555555545fe>
```
The issue is, that we mark both instructions as "current", highlighting both of them, making it a bit unambigous "where we are".
While this view is _kinda valid_ as the PC is really the same, we want to mark/hightlight only the first instruction we are on, as it is the one that is being executed right now and the program might go some other path in the future.
This commit fixes this display by simply making it so that the `nearpc` function/command used to display disasm shows the marker only once, for the first time it shows the current PC instruction.
This should fix#726. I am not 100% sure if this is a complete fix, but lets see if it breaks for a few days and if not, we can make a last release with py2 support.
Israel Alberto RV
GGyul-E
eldipa
roptimizer
German Vechtomov
fishykz
Disconnect3d
Konstantin Bücheler
xmcp
takimata
Lonny Wong
Tobias Faller
RGDZ-GZU
Lonny Wong
Keun Tae (Kevin) Park
Arusekk
Les De Ridder
Paweł Płatek
WeSeekAfterKnowledge
Bet4
layderv
Weston
tabell
Jan Mazur