This is the mail archive of the
sid@sources.redhat.com
mailing list for the SID project.
Re: Segmentation Fault sid&gdb
- To: <fche at redhat dot com>
- Subject: Re: Segmentation Fault sid&gdb
- From: norbert dot c dot esser at philips dot com
- Date: Tue, 16 Jan 2001 15:40:28 +0100
- Cc: <sid at sources dot redhat 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.