This is the mail archive of the
sid@sources.redhat.com
mailing list for the SID project.
Re: Segmentation Fault sid&gdb
- To: norbert dot c dot esser at philips dot com
- Subject: Re: Segmentation Fault sid&gdb
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Tue, 16 Jan 2001 12:55:34 -0500
- Cc: sid at sources dot redhat dot com
- References: <0056890019114738000002L982*@MHS>
Hi -
On Tue, Jan 16, 2001 at 03:40:28PM +0100, norbert.c.esser@philips.com wrote:
: [..]
: 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 [..]
Interesting.
: [...]
: (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).
Debugging line numbers sometimes get confused when you put too many
statements on a line. Try addding some whitespace or functional
filler.
: > * 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:
: 0x80e4: MOV_REG_IMM_SHIFT
: 0x80e8: STMDB_WB
: [...]
Right. If you add "--engine=scache", you'll get a more informative trace.
The default for arm, "pbb", provides some optimization but at the cost of
limited tracing. There is the possibility of interference with other
functions such as software breakpoints and exceptions, but that would be
a bug.
"--trace-core" will list simulated memory accesses. It would show the
actual memory address that triggered the simulated SEGV.
: [...]
: 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
Your gcc may be too old, but the others sound fine.
- FChE
PGP signature