From: norbert.c.esser@philips.com
To: <fche@redhat.com>
Cc: <sid@sources.redhat.com>
Subject: Re: Segmentation Fault sid&gdb
Date: Tue, 16 Jan 2001 06:38:00 -0000 [thread overview]
Message-ID: <0056890019114738000002L982*@MHS> (raw)
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.
next reply other threads:[~2001-01-16 6:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-16 6:38 norbert.c.esser [this message]
2001-01-16 9:55 ` Frank Ch. Eigler
2001-01-16 14:26 ` matthew green
-- strict thread matches above, loose matches on Subject: below --
2001-01-17 0:37 Bernard Dautrevaux
2001-01-16 11:04 Bernard Dautrevaux
2001-01-16 13:09 ` Frank Ch. Eigler
2001-01-16 14:46 ` Ben Elliston
2001-01-16 1:23 norbert.c.esser
2001-01-16 4:39 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='0056890019114738000002L982*@MHS' \
--to=norbert.c.esser@philips.com \
--cc=fche@redhat.com \
--cc=sid@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).