* Re: ARM Simulator Bug?
@ 2003-09-03 14:57 David Mc Kenna
2003-09-03 15:20 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: David Mc Kenna @ 2003-09-03 14:57 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: gdb, insight
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.
Any ideas?
Thanks,
Dave
--
http://www.iol.ie
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-03 14:57 ARM Simulator Bug? David Mc Kenna
@ 2003-09-03 15:20 ` Richard Earnshaw
2003-09-04 11:45 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-03 15:20 UTC (permalink / raw)
To: mckennad; +Cc: Richard Earnshaw, gdb, insight
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-03 15:20 ` Richard Earnshaw
@ 2003-09-04 11:45 ` Richard Earnshaw
0 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-04 11:45 UTC (permalink / raw)
To: mckennad; +Cc: Richard Earnshaw, gdb, insight, nickc
Ok, the executive summary on this is that gdb seems to have done the right
thing (inserted a Thumb breakpoint at the appropriate point), but the
simulator is ignoring this by treating it as a nop. That's not very
helpful, especially since it's then "nop"ped out a real instruction.
The reason that the behaviour changes when you drop in your link script is
that it causes a SWI vector to be installed (at least, it does according
to the primitive logic in the simulator), and hence SWI_vector_installed
becomes true.
What happens is that the Thumb decoder translates the instruction into an
ARM BKPT instruction, and it then runs the following ARM code to handle
that:
if (state->is_v5)
{
if (BITS (4, 7) == 0x7)
{
ARMword value;
extern int SWI_vector_installed;
/* Hardware is allowed to optionally override this
instruction and treat it as a breakpoint. Since
this is a simulator not hardware, we take the position
that if a SWI vector was not installed, then an Abort
vector was probably not installed either, and so
normally this instruction would be ignored, even if an
Abort is generated. This is a bad thing, since GDB
uses this instruction for its breakpoints (at least in
Thumb mode it does). So intercept the instruction here
and generate a breakpoint SWI instead. */
if (! SWI_vector_installed)
ARMul_OSHandleSWI (state, SWI_Breakpoint);
else
{
/* BKPT - normally this will cause an abort, but on the
XScale we must check the DCSR. */
XScale_set_fsr_far (state, ARMul_CP15_R5_MMU_EXCPT, pc);
if (!XScale_debug_moe (state, ARMul_CP14_R10_MOE_BT))
break;
}
/* Force the next instruction to be refetched. */
state->NextInstr = RESUME;
break;
Now, since SWI_vector_installed is true, we don't call ARMul_OSHandleSWI
for this case, so the debugger never gets re-entered (normally done
through SWI_Breakpoint).
I think the code should call ARMul_UndefInstr() if there isn't a specific
handler for it. The argument that if there isn't a SWI handler then there
won't be an abort handler seems specious -- it's not an abort anyway.
This is all a mess. But I'm not sure right now how best to start
untangling it.
R.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-03 10:36 David Mc Kenna
@ 2003-09-03 13:53 ` Richard Earnshaw
0 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-03 13:53 UTC (permalink / raw)
To: mckennad; +Cc: Richard Earnshaw, gdb, insight, Richard.Earnshaw
> Hi Richard,
>
> I think I have gotten closer to solving my problem. It relates to the linker
> script I use with compilation of gcc.
>
> If I take the standard armelf.x from the ldscripts directory and link against
> it my problem disappears. My problem is that I wish to place my reset vectors
> at 0x00 not the standard 0x8000. So I change the line:
>
> /* Read-only sections, merged into text segment: */
> . = 0x8000;
>
> to
>
> /* Read-only sections, merged into text segment: */
> . = 0x00;
>
> and my problem resurfaces. At a quick check of my memory contents from gdb at
> 0x00 I get 0x01 as opposed to what I get when I "download" the program using
> Run->Download of 0xEA000015.
>
> Any ideas?
Not really. Does "arm-elf-objdump -xd exe-file" display something
sensible?
R.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
@ 2003-09-03 10:36 David Mc Kenna
2003-09-03 13:53 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: David Mc Kenna @ 2003-09-03 10:36 UTC (permalink / raw)
To: Richard Earnshaw, mckennad, Richard Earnshaw, gdb, insight,
Richard.Earnshaw
Cc: gdb, insight, Richard.Earnshaw
Hi Richard,
I think I have gotten closer to solving my problem. It relates to the linker
script I use with compilation of gcc.
If I take the standard armelf.x from the ldscripts directory and link against
it my problem disappears. My problem is that I wish to place my reset vectors
at 0x00 not the standard 0x8000. So I change the line:
/* Read-only sections, merged into text segment: */
. = 0x8000;
to
/* Read-only sections, merged into text segment: */
. = 0x00;
and my problem resurfaces. At a quick check of my memory contents from gdb at
0x00 I get 0x01 as opposed to what I get when I "download" the program using
Run->Download of 0xEA000015.
Any ideas?
Thanks,
Dave
--
http://www.iol.ie
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-03 9:13 David Mc Kenna
@ 2003-09-03 9:51 ` Richard Earnshaw
0 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-03 9:51 UTC (permalink / raw)
To: mckennad; +Cc: Richard Earnshaw, gdb, insight, Richard.Earnshaw
> Hi Richard,
>
> >Try using an
> >
> > LDR r0, =__thumb
> >
>
> This command places the correct value into R0 for the BX command, but the bug
> within the simulator is still present.
>
> Take the following code as an example.
>
> 0000005c <TST_start>:
> 5c: e3a0da12 mov sp, #73728 ; 0x12000
> 60: e59f00a4 ldr r0, [pc, #164] ; 10c <IRQ_Interrupt+0x50>
> 64: e12fff10 bx r0
>
> 00000068 <__start_of_thumb>:
>
> void IRQ_Interrupt(void);
>
> int main()
> {
> 68: b580 push {r7, lr}
> 6a: 466f mov r7, sp
> 6c: b082 sub sp, #8
>
> If I place a breakpoint at 0x6c and run the code gdb loses itself, i.e. if I
> interrupt it with ctrl-c it says the PC is 0x0580fa70 or some thing similar.
> Again, if I place a breakpoint at 0x5c, I can single step successfully. If I
> single step to 0x68 and place a breakpoint at 0x6c and continue, gdb loses itself
> again.
>
> This problem only occurs when I attempt to use thumb. If I remove the bx command
> and compile my C file in ARM mode the simulator works perfectly.
Hmm, you are building *all* of your source with -g aren't you? gdb can
get very confused if it doesn't know whether it's debugging ARM or Thumb
code and it defaults to ARM when it doesn't know (another side-effect of
no mapping symbols).
Another thing to consider:
Is the processor taking an abort on the push instruction and jumping into
the abort handler? Try putting an a breakpoint at address 0x00000010.
Alternatively, check the value of SP before stepping the instruction.
>
> Is it possible to see which commands the simulator is executing?
>
I'm not aware of any simple way to do that. I agree that there are times
when it would be useful.
R.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
@ 2003-09-03 9:13 David Mc Kenna
2003-09-03 9:51 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: David Mc Kenna @ 2003-09-03 9:13 UTC (permalink / raw)
To: Richard Earnshaw, mckennad, gdb, insight, Richard.Earnshaw; +Cc: gdb, insight
Hi Richard,
>Try using an
>
> LDR r0, =__thumb
>
This command places the correct value into R0 for the BX command, but the bug
within the simulator is still present.
Take the following code as an example.
0000005c <TST_start>:
5c: e3a0da12 mov sp, #73728 ; 0x12000
60: e59f00a4 ldr r0, [pc, #164] ; 10c <IRQ_Interrupt+0x50>
64: e12fff10 bx r0
00000068 <__start_of_thumb>:
void IRQ_Interrupt(void);
int main()
{
68: b580 push {r7, lr}
6a: 466f mov r7, sp
6c: b082 sub sp, #8
If I place a breakpoint at 0x6c and run the code gdb loses itself, i.e. if I
interrupt it with ctrl-c it says the PC is 0x0580fa70 or some thing similar.
Again, if I place a breakpoint at 0x5c, I can single step successfully. If I
single step to 0x68 and place a breakpoint at 0x6c and continue, gdb loses itself
again.
This problem only occurs when I attempt to use thumb. If I remove the bx command
and compile my C file in ARM mode the simulator works perfectly.
Is it possible to see which commands the simulator is executing?
Thanks,
Dave
--
http://www.iol.ie
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-02 14:31 David Mc Kenna
@ 2003-09-02 18:17 ` Richard Earnshaw
0 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-02 18:17 UTC (permalink / raw)
To: mckennad; +Cc: Richard Earnshaw, gdb, insight, Richard.Earnshaw
> Hi Richard,
>
> Thanks for the reply.
>
> >It's more likely to be the way you are trying to get into Thumb state. Try
>
> >
> > adr r0, __start_of_thumb
>
> Should this line not be
>
> adr r0, __start_of_thumb+1
>
> To set the LSB to tell the core we want to enter Thumb mode
>
Well, no. If the bottom bit isn't being set automatically when the target
is a thumb symbol then that's really a bug in the tools.
> > bx r0
> > .code 16
> > .global __start_of_thumb
> > .thumb_func
> >__start_of_thumb:
> >
> >
> >This is really brokenness in the way gas implements ARM and Thumb code
> >areas, but it's hard to fix properly until GAS starts using mapping
> >symbols.
>
> If I use the +1 code above, and set a breakpoint at the adr command, I can single
> step successfully past the BX command and into my main.
It appears that GAS is broken:
$ cat test.s
.arm
adr r0, __thumb
bx r0
.thumb
.globl __thumb
.thumb_func
__thumb:
nop
$ arm-elf-as test.s -o test.o
$ arm-elf-objdump -dr test.o
test.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <__thumb-0x8>:
0: e28f0000 add r0, pc, #0 ; 0x0 ####### Bzzt no!
4: e12fff10 bx r0
00000008 <__thumb>:
8: 46c0 nop (mov r8, r8)
Try using an
LDR r0, =__thumb
expression. You'll need to squeeze the constant pool in somewhere.
R.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
@ 2003-09-02 14:31 David Mc Kenna
2003-09-02 18:17 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: David Mc Kenna @ 2003-09-02 14:31 UTC (permalink / raw)
To: Richard Earnshaw, mckennad, gdb, insight, Richard.Earnshaw
Hi Richard,
Thanks for the reply.
>It's more likely to be the way you are trying to get into Thumb state. Try
>
> adr r0, __start_of_thumb
Should this line not be
adr r0, __start_of_thumb+1
To set the LSB to tell the core we want to enter Thumb mode
> bx r0
> .code 16
> .global __start_of_thumb
> .thumb_func
>__start_of_thumb:
>
>
>This is really brokenness in the way gas implements ARM and Thumb code
>areas, but it's hard to fix properly until GAS starts using mapping
>symbols.
If I use the +1 code above, and set a breakpoint at the adr command, I can single
step successfully past the BX command and into my main.
But if I set a breakpoint further down, e.g. after two NOPS, and hit continue,
things go astray again. It seems that gdb does not know that when it does a
continue that it is in thumb mode and that it is executing 32bit arm commands
( e.g. 2*16bit Thumb Commands).
Is it possible to see the commands the simulator recieves as you can with the
remote serial commands , i.e. set debug remote 1?
Thanks,
Dave
--
http://www.iol.ie
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ARM Simulator Bug?
2003-09-02 11:27 David Mc Kenna
@ 2003-09-02 12:43 ` Richard Earnshaw
0 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2003-09-02 12:43 UTC (permalink / raw)
To: mckennad; +Cc: gdb, insight, Richard.Earnshaw
> Hi all,
>
> Has anyone else come across something similar to the below??
>
> I have a startup file embedded in a header file using inline assembly. This
> file contains the Interrupt vectors for an ARM7TDMi. The main file is compiled
> as ARM and I can simulate this perfectly.
> When I insert a BX command at the end of the inline assembly and add the
> -mthumb CL option to instruct gcc to compile the main as thumb it generates
> the elf. Then when I go to the simulator things go weird. If I place a "b ."
> command at the end of the inline assembly, I can stop gdb at this point and
> it stays at the correct point, i.e. at the b .. But if I remove the "b ." command
> the simulator goes hay-wire, i.e. Does not know where it is
>
>
> The embedded file:
>
> asm(".org 0x00\n"
> "\n"
> " b tst_start @ SVC 0x00\n"
> " b tst_start @ Undfd InstrUND 0x04\n"
> " b tst_start @ SWI _StartupSVC 0x08\n"
> " b tst_start @ Pre Abort ABORT 0x0C\n"
> " b tst_start @ Data AbortABORT 0x10\n"
> " b tst_start\n"
> " b tst_start @ IRQ _StartupIRQ 0x18\n"
> " b tst_start @ FIQ _Startup FIQ 0x1C\n"
> ".global tst_start\n"
> "tst_start: \n"
> " mov sp,#0x12000\n"
> " adr R0,tmp+1\n"
> " bx R0\n" !!!!!!!!! Problem Line
> ".code 16\n"
> "tmp:\n"
> "\n");
>
>
> My main file:
>
>
> #include "tester.h"
>
> int main()
> {
> unsigned int b=0x01;
> unsigned int count = 0x00;
>
> while ( b != 0x00)
> {
> count++;
> }
> return 0;
>
> }
>
> My compile script:
>
> arm-elf-gcc.exe -mthumb \
> $1.c -mthumb-interwork -mcpu=arm7tdmi\
> -g -Wall -nostartfiles -mlittle-endian -save-temps -O$2 \
> -Wl,-T /c/tst/scripts/clink.x -o $1.elf
>
> I have tried this with the same result with gcc3.2.3, gcc version 3.3.2 20030825
> and gdb snapshots from 10-6-2003 and 01-09-2003
>
> Any ideas?
It's more likely to be the way you are trying to get into Thumb state. Try
adr r0, __start_of_thumb
bx r0
.code 16
.global __start_of_thumb
.thumb_func
__start_of_thumb:
This is really brokenness in the way gas implements ARM and Thumb code
areas, but it's hard to fix properly until GAS starts using mapping
symbols.
R.
^ permalink raw reply [flat|nested] 11+ messages in thread
* ARM Simulator Bug?
@ 2003-09-02 11:27 David Mc Kenna
2003-09-02 12:43 ` Richard Earnshaw
0 siblings, 1 reply; 11+ messages in thread
From: David Mc Kenna @ 2003-09-02 11:27 UTC (permalink / raw)
To: gdb, insight
Hi all,
Has anyone else come across something similar to the below??
I have a startup file embedded in a header file using inline assembly. This
file contains the Interrupt vectors for an ARM7TDMi. The main file is compiled
as ARM and I can simulate this perfectly.
When I insert a BX command at the end of the inline assembly and add the
-mthumb CL option to instruct gcc to compile the main as thumb it generates
the elf. Then when I go to the simulator things go weird. If I place a "b ."
command at the end of the inline assembly, I can stop gdb at this point and
it stays at the correct point, i.e. at the b .. But if I remove the "b ." command
the simulator goes hay-wire, i.e. Does not know where it is
The embedded file:
asm(".org 0x00\n"
"\n"
" b tst_start @ SVC 0x00\n"
" b tst_start @ Undfd InstrUND 0x04\n"
" b tst_start @ SWI _StartupSVC 0x08\n"
" b tst_start @ Pre Abort ABORT 0x0C\n"
" b tst_start @ Data AbortABORT 0x10\n"
" b tst_start\n"
" b tst_start @ IRQ _StartupIRQ 0x18\n"
" b tst_start @ FIQ _Startup FIQ 0x1C\n"
".global tst_start\n"
"tst_start: \n"
" mov sp,#0x12000\n"
" adr R0,tmp+1\n"
" bx R0\n" !!!!!!!!! Problem Line
".code 16\n"
"tmp:\n"
"\n");
My main file:
#include "tester.h"
int main()
{
unsigned int b=0x01;
unsigned int count = 0x00;
while ( b != 0x00)
{
count++;
}
return 0;
}
My compile script:
arm-elf-gcc.exe -mthumb \
$1.c -mthumb-interwork -mcpu=arm7tdmi\
-g -Wall -nostartfiles -mlittle-endian -save-temps -O$2 \
-Wl,-T /c/tst/scripts/clink.x -o $1.elf
I have tried this with the same result with gcc3.2.3, gcc version 3.3.2 20030825
and gdb snapshots from 10-6-2003 and 01-09-2003
Any ideas?
Thanks,
Dave Mc Kenna
--
http://www.iol.ie
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-09-04 11:45 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-03 14:57 ARM Simulator Bug? David Mc Kenna
2003-09-03 15:20 ` Richard Earnshaw
2003-09-04 11:45 ` Richard Earnshaw
-- strict thread matches above, loose matches on Subject: below --
2003-09-03 10:36 David Mc Kenna
2003-09-03 13:53 ` Richard Earnshaw
2003-09-03 9:13 David Mc Kenna
2003-09-03 9:51 ` Richard Earnshaw
2003-09-02 14:31 David Mc Kenna
2003-09-02 18:17 ` Richard Earnshaw
2003-09-02 11:27 David Mc Kenna
2003-09-02 12:43 ` Richard Earnshaw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).