On 23.08.2019 23:07, Alexander Tormasov via users wrote:
Thank you for information!
Dump of my file show Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000200040 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000150 memsz 0x0000000000000150 flags r-- INTERP off 0x000000000012bee2 vaddr 0x000000000112aee2 paddr 0x000000000112aee2 align 2**0 filesz 0x000000000000000a memsz 0x000000000000000a flags r-- LOAD off 0x0000000000001000 vaddr 0x0000000001000000 paddr 0x0000000001000000 align 2**12 filesz 0x000000000015c9fc memsz 0x000000000015c9fc flags r-x LOAD off 0x000000000015e000 vaddr 0x000000000115d000 paddr 0x000000000115d000 align 2**12 filesz 0x0000000000081e9c memsz 0x00000000001112f4 flags rw- DYNAMIC off 0x00000000001c0c18 vaddr 0x00000000011bfc18 paddr 0x00000000011bfc18 align 2**5 filesz 0x000000000001f284 memsz 0x000000000001f26c flags rw- EH_FRAME off 0x0000000000156030 vaddr 0x0000000001155030 paddr 0x0000000001155030 align 2**2 filesz 0x00000000000079cc memsz 0x00000000000079cc flags r-- Does it mean that real offset in code is
ip=0xa95b1- 0x1000
like 0xa85b1 Disassembly shows the following: 10a85b1: 8b 15 69 85 11 00 mov 0x118569(%rip),%edx # 11c0b20 <genode_argv+0x260>
Seems that argv is damaged… While I still try to find exactly which function fail here
You also can try "objdump -S" on your binary, and search for the trap address in the output. This
command should show a disassembly, intermixed with a source code (if it's C/C++, not sure
about Golang). So, you can determine, which function exactly is trapped. And yes, you need to
compile with full debug symbols.