Running programs on aarch64 simulator

Simon Marchi simark@simark.ca
Mon May 11 02:35:28 GMT 2020


On 2020-05-08 1:17 p.m., Simon Marchi wrote:
> It's also possible to run it directly like this:
> 
> $ ./sim/aarch64/run gdb/test
> core: 8 byte write to unmapped address 0xfffffff0 at 0x0
> program stopped with signal 11 (Segmentation fault).
> 
> The result is the same as when I ran it through GDB.  I have no idea if it's the sim that
> is faulty, or the binary needs to be compiled differently.
> 
>>
>>     Program received signal SIGSEGV, Segmentation fault.
>>     0x0000000000000000 in ?? ()
>>
>>
>> That matches what luck I had on master. I suspect that is a mismatch between
>> the address map of the simulator and whatever the default linker script does.
> 
> Perhaps.  With the ARM simulator, when I do "starti" in GDB, I see that it starts
> executing at the ELF file's entry point.  With the AArch64 simulator, it starts
> at 0 (the entry point of the ELF is not 0).  So I also suspect that the initial
> PC is not right.

I was wrong here, the PC is fine.  I found how to enable traces when running the simulator
(not that it's complicated).  It crashes after a few instructions:

$ ./sim/aarch64/run --trace=on --trace-disasm=on ./sim/aarch64/a.out
memory:   ERROR: executable is too big: ffffffffffffffff
insn:      pc = 400168 instr = 58000281
disasm:   ldr   x1, 0x00000000004001b8
memory:   read of 0 (8 bytes) from 4001b8
insn:      pc = 40016c instr = 927cec20
disasm:   and   x0, x1, #0xfffffffffffffff0
insn:      pc = 400170 instr = 9100001f
disasm:   mov   sp, x0
insn:      pc = 400174 instr = d280001d
disasm:   mov   x29, #0x0                       // #0
insn:      pc = 400178 instr = a9bf77fd
disasm:   stp   x29, x29, [sp, #-16]!
memory:   write of 0 (8 bytes) to fffffffffffffff0
core: 8 byte write to unmapped address 0xfffffff0 at 0x0
program stopped with signal 11 (Segmentation fault).

What seems to happen is that the code tries to set up the stack pointer, but its initial value
read from 0x4001b8 is 0.  So it crashes when we try to write to the stack.

I have no idea why, I posted this question here:

  https://sourceware.org/pipermail/newlib/2020/017635.html

Simon


More information about the Gdb mailing list