From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10843 invoked by alias); 3 Sep 2003 15:20:13 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 10794 invoked from network); 3 Sep 2003 15:20:06 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 3 Sep 2003 15:20:06 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id QAA00163; Wed, 3 Sep 2003 16:19:48 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h83FJmX18357; Wed, 3 Sep 2003 16:19:48 +0100 Message-Id: <200309031519.h83FJmX18357@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: mckennad@esatclear.ie cc: Richard Earnshaw , gdb@sources.redhat.com, insight@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: ARM Simulator Bug? In-reply-to: Your message of "Wed, 03 Sep 2003 15:57:00 BST." <3f56013c.3515.0@esatclear.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Sep 2003 15:20:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-q3/txt/msg00143.txt.bz2 > Hi Richard, > > >Does "arm-elf-objdump -xd exe-file" display something sensible? > > When I compared the working to non-working output, the only difference was in > the private flags: > > Working: > private flags = 6: [interworking enabled] [APCS-32] [FPA float format] [has > entry point] > > Broken: > private flags = 4: [interworking enabled] [APCS-32] [FPA float format] > > It seems that it cannot find the entry point. Even though it is defined as always > being 0x00. > By only difference, I assume you mean, "other than that things are moved down by 32Kbytes". Generic ELF says that an image has an entry point if (and only if) e_entry in the ELF header is not zero. That's not particularly helpful on bare-metal ARM systems where we want an entry point at zero; so that would explain the difference here. It's just possible that that is confusing gdb into transferring control to the wrong place, but I suspect not. The sad thing about all this is that all the required tracing ability *is* built into the assembler (rdi_log). But when Cygnus integrated the simulator into GDB they bypassed all the code that manages that (in armrdi.c) and used a custom interface (wrapper.c). So while it's all there, you can't get at it :-( R.