From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id F36ED3887013 for ; Mon, 11 May 2020 02:35:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F36ED3887013 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1D3211E5F9; Sun, 10 May 2020 22:35:29 -0400 (EDT) Subject: Re: Running programs on aarch64 simulator From: Simon Marchi To: joel@rtems.org Cc: gdb@sourceware.org References: <05b1ac83-4c46-45b5-d6ce-aba700b9c933@simark.ca> <802bfcc2-2a74-ef30-eca0-b247a6d5b8f1@simark.ca> Message-ID: Date: Sun, 10 May 2020 22:35:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <802bfcc2-2a74-ef30-eca0-b247a6d5b8f1@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 02:35:35 -0000 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