Aliasing memory addresses in GDB - gdb

I am looking for a way (directly or best approximation/alternative) to assign aliases to memory addresses in GDB, which would then show up with every function that prints this address (such as x, find, info proc map and so on).
Ideally, I'd also be able to set some sort of a range, which would then be used together with alias, to output offsets rather than direct addresses.
For example, using imaginary commands alias and set-offset-range
(gdb) info proc mem
0x55c10c43e000 0x55c10c44f000 0x11000 0x0 /usr/bin/htop
0x55c10c44f000 0x55c10c47d000 0x2e000 0x11000 /usr/bin/htop
0x55c10c47d000 0x55c10c48c000 0xf000 0x3f000 /usr/bin/htop
0x55c10c48d000 0x55c10c492000 0x5000 0x4e000 /usr/bin/htop
0x55c10c492000 0x55c10c493000 0x1000 0x53000 /usr/bin/htop
0x55c10c493000 0x55c10c495000 0x2000 0x0
0x55c10dee7000 0x55c10e185000 0x29e000 0x0 [heap]
...
(gdb) alias 0x55c10dee7000 'heap' <-------------------
(gdb) set-offset-range $heap 0x29e00 <-------------------
(gdb) info proc map
0x55c10c43e000 0x55c10c44f000 0x11000 0x0 /usr/bin/htop
0x55c10c44f000 0x55c10c47d000 0x2e000 0x11000 /usr/bin/htop
0x55c10c47d000 0x55c10c48c000 0xf000 0x3f000 /usr/bin/htop
0x55c10c48d000 0x55c10c492000 0x5000 0x4e000 /usr/bin/htop
0x55c10c492000 0x55c10c493000 0x1000 0x53000 /usr/bin/htop
0x55c10c493000 0x55c10c495000 0x2000 0x0
$heap ($heap+0x29e000) 0x29e000 0x0 [heap]
(gdb) x/32xb $heap
$heap: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
$heap+8: 0x91 0x02 0x00 0x00 0x00 0x00 0x00 0x00
Bonus question: if I need similar output tweaks in the future - what section of GDB manual should I be looking at to learn more about it?

After some looking around and consulting helpful people on #gdb, turns out this isn't possible - either with gdb or Python extension API.
A workaround is to use ld to generate an artifical object file and fill it with synthetic symbols using --defsym flag, then load that object file into gdb using add-symbol-file.
I won't accept the workaround as solution, so if anyone has a better idea - bring it forth please.

Related

Faster i2ccmd execution

I am facing One problem regarding system command execution ?
Actually there are 2 playback music sources like Bluetooth and other source . For that we used one specific codec (NPCA110B) in our system .
To play music on One source , Let consider BT , I have to run 20 command to play music over BT .
One Important Note is, for performing source switch between Music sources , I have to run the 20 commands in sequentially.
In My code , In one of the API , I am giving 20 system command in following way. This API is responsible for doing source switch.
void func()
{
// here 20 commands are there .
system("i2ccmd w 0x73 0x00 0x02 0xA5 0x00");
system("i2ccmd w 0x73 0x00 0x02 0xC3 0x00");
system("i2ccmd w 0x73 0x00 0x02 0xA4 0x11");
system("i2ccmd w 0x73 0x00 0x02 0x00 0x00");
....
....
....
....
system("i2ccmd w 0x73 0x00 0x02 0xA5 0x00");
}
The problem is , I able to do source switch successfully , but performance is Hampering. because i2ccmd internally perform file operation for each command . And execution time is more to execute above command sequentially.
Is there any way to write all 20 i2ccmd in single file operation ? Or any other way to make faster execution of i2ccmd ?

Default CRC input to reproduce check value

I found a site where a lot of CRC values are listed, with configurations/setup. There is also a "check" value, which I believe is generated with some kind of default input (some dummy string or such).
Does anybody know what this is and/or how I can reproduce it?
Sample config: width=3 poly=0x3 init=0x7 refin=true refout=true xorout=0x0 check=0x6 name="CRC-3/ROHC"
Site: http://reveng.sourceforge.net/crc-catalogue/all.htm#crc.cat.arc
Thanks a lot.
sorry, found the solution.
HEX: 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39
String: 123456789

gdb watch point does not work on gdb load command

I set a watch point on memory location in gdb and load a application through gdb load command. watch point does not hit during load command although memory location is being changed during loading of application.
(gdb) watch *0x1c
Hardware watchpoint 2: *0x1c
(gdb) p/x *0x1c
$2 = 0xffffffff
(gdb) load
Loading section .text, size 0x53b4 lma 0x0
Loading section .eh_frame, size 0x4 lma 0x53b4
Loading section .ARM.exidx, size 0x8 lma 0x53b8
Loading section .rodata, size 0x238 lma 0x53c0
Loading section .data, size 0x520 lma 0x55f8
Start address 0xe4, load size 23320
Transfer rate: 9 KB/sec, 4664 bytes/write.
(gdb) p/x *0x1c
$3 = 0xfdfcdf08
(gdb)
Does watch point work during gdb load command?
I think it would be very unexpected if this triggered. Watchpoints are for changes made by running your program. In this case, your program isn't running, it is being loaded.

ATmega8 doesn't support JMP instruction

Now I'm writing bootloader which starts in the middle of memory, but after it finishes I need to go to the main app, thought to try jmp 0x00, however my chip doesn't support jmp, how should I start main app?
I would use RJMP:
Relative jump to an address within PC - 2K +1 and PC + 2K (words). In
the assembler, labels are used instead of relative operands.
For example:
entry:
rjmp reset
.org 512
reset:
rjmp foo
.org 3072
foo:
rjmp entry
By the way, there are several other jump instructions (RJMP, IJMP, RCALL, ICALL, CALL, RET, RETI etc.) See this relevant discussion.
Well take a look into RET instruction. It returns to previous location, so you can try:
push 0x00
push 0x00
ret
This should work because while entering into any function you push your current location, and RET makes you go back.
As far as I remember ATmege8 has 16-bit address line, but if I'm not right you may need more push 0x00
why not simply use IJMP?
set Z to 0x00 and use IJMP. may be faster than 2xpush and ret
EOR R30, R30 ; clear ZL
EOR R31, R31 ; clear ZH
IJMP ; set PC to Z
should be 4 cycles and 3 instruction words (6 Bytes program memory)

Sending Info Hash to Bittorrent Tracker Over UDP

So I'm writing a Bittorrent client in C++ and I can communicate with the tracker, however when I get the announce response my IP address is the only one I get in return. After looking at my traffic over wireshark and comparing it to the traffic to the same tracker in transmission I've concluded that I must be sending the info-hash of the torrent incorrectly.
So, I'm sending this as my info-hash of my test torrent (TPB AFK (totally legal to torrent!)):
99FEAE0A05C6A5DD9AF939FFCE5CA9B0D16F31B0
From reading a few other posts around the net I got the idea that I have to encode this somehow, and also that it needs to be 20 bytes (which I stupidly didn't realize it wasn't before...didn't count).
So there must be some sort of encoding that I must feed this hash into, but what is it?
Okay, so That string of 40 characters, is just 20 bytes...so the correct way to send the info_hash is:
0x99 0xFE 0xAE 0x0A 0x05 0xC6 0xA5 0xDD 0x9A 0xF9 0x39 0xFF 0xCE 0x5C 0xA9 0xB0 0xD1 0x6F 0x31 0xB0