From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 379 invoked by alias); 15 Feb 2012 17:33:41 -0000 Received: (qmail 361 invoked by uid 22791); 15 Feb 2012 17:33:38 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_EV,TW_QE X-Spam-Check-By: sourceware.org Received: from mail-qw0-f48.google.com (HELO mail-qw0-f48.google.com) (209.85.216.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 17:33:22 +0000 Received: by qauh8 with SMTP id h8so1525702qau.0 for ; Wed, 15 Feb 2012 09:33:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.136.79 with SMTP id q15mr15600788qct.149.1329327201540; Wed, 15 Feb 2012 09:33:21 -0800 (PST) Received: by 10.229.35.1 with HTTP; Wed, 15 Feb 2012 09:33:21 -0800 (PST) In-Reply-To: <30DEFAEF-E241-44A7-BB22-5CD1AED61899@elis.ugent.be> References: <047D674A-A77C-4E5A-B207-592A81D857DC@elis.ugent.be> <20120208173258.GA21639@e103070-lin.arm.com> <2370539B-1B7C-4ADB-B44F-0F09553C5D62@elis.ugent.be> <20120209013821.GB7259@e103070-lin.arm.com> <30DEFAEF-E241-44A7-BB22-5CD1AED61899@elis.ugent.be> Date: Wed, 15 Feb 2012 17:33:00 -0000 Message-ID: Subject: Re: Debug ARM semihosting Thumb-2 binary From: Peter Maydell To: Jonas Maebe Cc: Matthew Gretton-Dann , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlIGh+MQiQz/bYVKJCe+47D5rCASa0TQ8nlsfjllSb1c4ad1vtiMMdMYtyVis8LF0rxQVQ3 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00045.txt.bz2 On 9 February 2012 13:08, Jonas Maebe wrote: > On 09 Feb 2012, at 02:38, Matthew Gretton-Dann wrote: >> On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote: >>> The full QEMU command line I use: >>> >>> ~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb -cpu >>> cortex-m3 -kernel qsort_large -append "input_large.dat" -S -s >> >> I think -M realview-eb -cpu cortex-m3 is not the best way of invoking qe= mu >> as it generates a system with a Cortex-M3 but without the appropriate >> interrupt controller. =C2=A0Try one of the Stellaris boards instead (use >> -machine ? to get the actual command line). > > I've now tried both -M lm3s811evb (Stellaris LM3S811EVB) and -M lm3s6965e= vb > (Stellaris LM3S6965EVB) together with -cpu cortex-m3. Neither appears to > work at all: there's no output (not even QEMU complaining that it can't o= pen > any sound devices, which it does instantaneously on startup if I choose t= he > realview-eb platform). You shouldn't expect complaints about sound devices because the stellaris boards don't have any sound devices. The reason this isn't working for you is that QEMU's M3 model doesn't pay any attention to the entry point in an ELF file -- it expects that you feed it an ELF image which starts at address zero and includes the M profile vector table (from which it will pull the starting PC and SP). Not supporting "load ELF file and use its entry point as the starting PC" is arguably a missing feature (although you have to answer the question of 'so what should the starting SP be' if you want to support this). However since QEMU's M profile support is basically in the 'odd fixes' state this isn't likely to be improved in the near future, so the simplest thing is for you to just generate an ELF file of the right shape. Using the 'realview-eb' platform is definitely a bad idea as it only 'works' because we don't really nail down the set of supported CPUs; at some point in the future it may actively tell you this set of command line options are a user error :-) >> We need to diagnose whether this is a QEmu or GDB issue. > Yes, I'm also starting to wonder whether I might be QEMU rather than gdb > that's going wrong... Coincidentally, Meador Inge from CodeSourcery posted a patch to the QEMU list today which fixes the SIGINT issue: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02008.html (not yet code reviewed, but I did a quick test and it does seem to at least avoid the SIGINT problems.) However speed of fread over the gdb syscall interface is absolutely dire, it seems (from 'set debug remote 1') to be doing about one data packet a second... -- PMM