Re: Segmentation Fault sid&gdb

[norbert dot c dot esser at philips dot com]

Thanks for the quick response.

>>: But I now give the follwing command:
>>:
>>:       (gdb) cont
>>:
>>: Then I get the following message:
>>:       Program received signal SIGSEGV, Segmentation fault
>>: [...]

> This message indicates that the arm-elf program running
> on the simulator has encountered a SEGV.  hello-world of
> course shouldn't, but there are a few ways to find out
> what's happening:

To be a little more precise, the SEGV thing only happens to me
when I create breakpoints. Without any breakpoints the program
seems to runn correctly (i.e. it prints Hello world!) and gdb 
indicates that the program terminated normally.

>
> * when the first fault message comes from gdb, run
>   the gdb `backtrace' command to find out where the
>   crash occurred

Ok. compiled the program
#include <stdio.h>

int main() 
{ printf("Hello world!\n");
  return 0;
}

with: arm-elf-gcc -mlittle-endian -g hello.c -o hello.x

started sid with: arm-elf-sid --gdb:2000 -EL &

and then ran gdb as follows:

arm-elf-gdb -nw hello.x                    (Note I'm using Insight5.0 gdb)
GNU gdb 20010115
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
0x00000000 in ?? ()
(gdb) load
Loading section .text, size 0x87d0 lma 0x8000
Loading section .rodata, size 0x22c lma 0x107d0
Loading section .data, size 0x854 lma 0x10afc
Loading section .ctors, size 0x8 lma 0x11350
Loading section .dtors, size 0x8 lma 0x11358
Start address 0x8000, load size 37472
Transfer rate: 149888 bits/sec, 302 bytes/write.
(gdb) break 4
Breakpoint 1 at 0x80e4: file hello.c, line 4. 

Note: that now break main for some reason sets the breakpoint at line 5 (after the return 0).
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000080e8 in main () at hello.c:4
4	{ printf("Hello world!\n"); 
(gdb) backtrace
#0  0x000080e8 in main () at hello.c:4

> * enable more simulator tracing options, for example by
>   adding "--trace-sem" and "--trace-core" and perhaps "--verbose"
>   to the arm-elf-sid command line; possibly, compare the
>   trace-sem disassembly to "arm-elf-objdump -d <your-hello-world.x>".
Ok. I added --trace-sem option. And this what I got:


Running without breakpoint (program runs and terminates normally):
0x80e4: MOV_REG_IMM_SHIFT
0x80e8: STMDB_WB	
0x80ec: SUB_IMM	
0x80f0: BL
....snip
0x80f4: LDR_PRE_INC_IMM_OFFSET
0x80f8: BL
....snip
0x80fc: MOV_IMM
0x8100: B
0x8108: LDMDB	

Running with breakpoint (program terminates with SEGV):
0x80e4: LDRB_PRE_INC_WB_REG_OFFSET	
0x80e8: STMDB_WB

arm-elf-objdump -d -S gives:
000080e4 <main>:
#include <stdio.h>

int main() 
{ printf("Hello world!\n");
    80e4:	e1a0c00d 	mov	r12, sp    
    80e8:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
    80ec:	e24cb004 	sub	r11, r12, #4	; 0x4
    80f0:	eb000038 	bl	81d8 <__gccmain>
    80f4:	e59f0008 	ldr	r0, [pc, #8]	; 8104 <main+0x20>
    80f8:	eb000275 	bl	8ad4 <printf>
  return 0;
    80fc:	e3a00000 	mov	r0, #0	; 0x0
    8100:	ea000000 	b	8108 <main+0x24>
    8104:	000107d0 	streqsb	r0, [r1], -r0
}
    8108:	e91ba800 	ldmdb	r11, {r11, sp, pc}

It seems that the breakpoint causes the problems, but I have no idea
what is exactly going on. 

> * identify which arm-elf cross-compiler toolchain you are using
I'm using the following:

binutils-2.10.1
gcc-2.95.2
insight-5.0    (also tried gdb-5.0 with same results)
newlib-1.9.0

All configured with --target=arm-elf

> : [...]
> : I would for example like to be able to set multiple breakpoints and
> : if the program stops on a breakpoint continue the program until it
> : stops on another breakpoint.  Is this possible?   [...]

> Certainly.  This is a routine usage scenario, and should in general
> work.

Thats what I thought :-)

Hope this clears things up a bit and that you can help me further.

Greetings.