This is the mail archive of the sid@sources.redhat.com mailing list for the SID project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Segmentation Fault sid&gdb


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]