Re: ARM Simulator Bug?

Re: ARM Simulator Bug?

[David Mc Kenna]

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

Re: ARM Simulator Bug?

[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.

Re: ARM Simulator Bug?

[David Mc Kenna]

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

Re: ARM Simulator Bug?

[Richard Earnshaw]

> 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.

Re: ARM Simulator Bug?

[Richard Earnshaw]

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.

Re: ARM Simulator Bug?

[David Mc Kenna]

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

Re: ARM Simulator Bug?

[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.

Re: ARM Simulator Bug?

[David Mc Kenna]

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

Re: ARM Simulator Bug?

[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.

ARM Simulator Bug?

[David Mc Kenna]

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

Re: ARM Simulator Bug?

[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.