* feature(radare2): add alias radare2 to r2 command
* feature(radare2): add argument to set base when loading for PIE
Depending on the use case, one may want to have either the same
addresses for PIE as in gdb or just use the non rebased plain addresses
without taking the current memory mapping into account.
* fix(radare2): fix relocations in disassembly warning by enabling io.cache
There was a quoting bug as `INSTALLFLAGS` contains both the option key and value.
This causes the subsequent commands to look something like `python ... '--target foo'...`, causing
the command to treat the entire string `--target foo` as an option key rather than a key-value pair.
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.
Levente Polyak
WeSeekAfterKnowledge
Bintang Fikriguska
Tobias Faller
Israel Alberto RV
Disconnect3d
Victor Chan
Bet4
Tim Gates
GGyul-E
eldipa
roptimizer
German Vechtomov
fishykz
Konstantin Bücheler
xmcp
takimata
Lonny Wong
Tobias Faller
RGDZ-GZU
Lonny Wong
Keun Tae (Kevin) Park
Arusekk
Les De Ridder
Paweł Płatek