From mboxrd@z Thu Jan 1 00:00:00 1970 From: norbert.c.esser@philips.com To: Cc: Subject: Re: Segmentation Fault sid&gdb Date: Tue, 16 Jan 2001 06:38:00 -0000 Message-id: <0056890019114738000002L982*@MHS> X-SW-Source: 2001-q1/msg00048.html 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 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 ". 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
: #include 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 80f8: eb000275 bl 8ad4 return 0; 80fc: e3a00000 mov r0, #0 ; 0x0 8100: ea000000 b 8108 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.