Re: Running programs on aarch64 simulator
Simon Marchi <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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