This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: ARM Simulator Bug?
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: mckennad at esatclear dot ie
- Cc: Richard Earnshaw <rearnsha at arm dot com>, gdb at sources dot redhat dot com, insight at sources dot redhat dot com
- Date: Wed, 03 Sep 2003 16:19:48 +0100
- Subject: Re: ARM Simulator Bug?
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> 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.