Segmentation Fault sid&gdb

[Frank Ch. Eigler]

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
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6ZIsWVZbdDOm/ZT0RArGnAJ9goGNaoVgL+DD7QjOku40XXQ2+HQCeO9eW
6Cc6rWZ6G3Gey+6Q0iO4h6I=
=YRnX
-----END PGP SIGNATURE-----