public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: joel@rtems.org
Cc: gdb@sourceware.org
Subject: Re: Running programs on aarch64 simulator
Date: Sun, 10 May 2020 22:35:28 -0400	[thread overview]
Message-ID: <e7af71ca-b81f-3a6f-d965-ccc38cf59aa2@simark.ca> (raw)
In-Reply-To: <802bfcc2-2a74-ef30-eca0-b247a6d5b8f1@simark.ca>

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

  reply	other threads:[~2020-05-11  2:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 13:44 Joel Sherrill
2020-05-08 16:09 ` Simon Marchi
2020-05-08 16:57   ` Joel Sherrill
2020-05-08 17:17     ` Simon Marchi
2020-05-11  2:35       ` Simon Marchi [this message]
2020-05-11 14:26       ` Nick Clifton
2020-05-11 14:40         ` Joel Sherrill
2020-05-11 17:58           ` Jim Wilson
2020-05-11 18:30             ` Joel Sherrill
2020-05-11 22:13               ` Jim Wilson
2020-05-08 16:16 ` Luis Machado
2020-05-08 16:44   ` Joel Sherrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7af71ca-b81f-3a6f-d965-ccc38cf59aa2@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb@sourceware.org \
    --cc=joel@rtems.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).