This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: SIGTRAP question
- To: Nicole Cook <cook at maya dot com>
- Subject: Re: [ECOS] SIGTRAP question
- From: Jonathan Larmour <jlarmour at redhat dot co dot uk>
- Date: Thu, 11 May 2000 20:24:06 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- Organization: Red Hat UK Ltd.
- References: <391B06D5.D33E916F@maya.com>
Nicole Cook wrote:
>
> I keep running into this problem while debugging with ecos gdb stubs - I
> can't seem to figure out where the SIGTRAP is coming from. I'm running
> arm-elf-gdb on linux, debugging an aebC. I can't figure out where the
> sigtrap is coming from - it just never returns from the function? Is
> there something set in the stubs to trigger this trap?
The stubs set replace instructions with breakpoint instructions (usually
illegal instructions actually) when single stepping or setting breakpoints.
When one of those is hit, it is then reported to GDB. But if GDB doesn't
think it's set a breakpoint instruction there, it will just report the
SIGTRAP.
> Breakpoint 2, IDE_onPowerUp () at lba.c:611
> (gdb) s
It's odd that you get no output here after a step.
> (gdb) s
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x401a5e4 in ?? ()
That's an address in ROM. By any chance is it the same address you get when
you connect to the board with "target remote"? If so, it looks like the
board is resetting itself, or jumping to the reset address at least.
Jifl
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault