Debugging without GDB - stack print?

[Valery V. Sedletski]

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.