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 47C7B385DC00 for ; Fri, 8 May 2020 17:17:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 47C7B385DC00 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 948E51E5F9; Fri, 8 May 2020 13:17:16 -0400 (EDT) Subject: Re: Running programs on aarch64 simulator To: joel@rtems.org Cc: gdb@sourceware.org, Nick Clifton References: <05b1ac83-4c46-45b5-d6ce-aba700b9c933@simark.ca> From: Simon Marchi Message-ID: <802bfcc2-2a74-ef30-eca0-b247a6d5b8f1@simark.ca> Date: Fri, 8 May 2020 13:17:16 -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: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.7 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: Fri, 08 May 2020 17:17:18 -0000 On 2020-05-08 12:57 p.m., Joel Sherrill wrote: > On all the elf/eabi targets I have tried over the years, CPU-elf-gcc produced an a.out that was linked with the installed libgloss. I randomly had an sh-elf toolchain laying around and it worked like "sh-elf-gcc m.c" and then both sh-elf-gdb and sh-elf-run could run it on the gdb simulator. > > The aarch64-elf toolchain installs 4 .specs files from libgloss but adding -specs XXX and trying each with the gdb simulator (via aarch64-elf-run) all fail. > > home/joel/test-gcc/install-master/aarch64-elf/lib/aem-validation.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/aem-ve.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/nosys.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/rdimon.specs Ok, I am not familiar with that. Well, it did work for me to build with: $ aarch64-none-elf-gcc test.c -g3 -O0 -o test -specs=nosys.specs I didn't have to provide my own _exit. According to the DWARF info, the _exit now included in my program comes from: /tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/src/newlib-cygwin/libgloss/libnosys/_exit.c > > This seems to be an odd case where there is a simulator in the source tree and there is no clear way to use it. Assuming it works. 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 did not push the investigation further. > > > I think Nick may be the key to getting an answer here.  Added him in CC, we'll see :). Simon