Debugging without GDB - stack print?

[Alexander Tormasov]

Significant problem here is that you need to know where it will be loaded in memory
Disasm start at 100000 while probably basic load address is 1000 as mentioned below
But I still not sure that this 1000 is for my code test-go, may be it is for noux?
Or to something else?
Where to find a detailed map of memory load? Log from VM seems to be not enough...

Отправлено с iPhone

> 24 авг. 2019 г., в 11:01, Valery V. Sedletski via users <users at lists.genode.org> написал(а):
> 
>> 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.
> 
> 
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users