This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RDI_read: data abort
- To: Shaun Jackman <shaunj at gray-interfaces dot com>
- Subject: Re: RDI_read: data abort
- From: Grant Edwards <grante at visi dot com>
- Date: Sun, 10 Sep 2000 17:00:01 -0500
- Cc: gdb at sources dot redhat dot com
- References: <00090814512400.01248@ed>
On Fri, Sep 08, 2000 at 02:45:14PM -0600, Shaun Jackman wrote:
> (gdb) c
> Continuing.
> RDI_execute: branch through location 0
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> RDI_read: data abort, no memory at specified address?
> RDI_read: data abort, no memory at specified address?
> Error accessing memory address 0xe59ff010: Resource temporarily unavailable.
> (gdb)
>
> What would cause this error? What generated the SIGTRAP? (not a bp)
One of the problems with the RDI target is that ADP defines a _bunch_ of
signals which are then mapped to the list of signals that GDB understands.
There are a bunch of RDI signals that don't really have any corresponding
GDB signals, so they get mapped to things like "TRAP". Somebody needs to
re-design the mapping so that there is a 1:1 correspondance, and then you
can tell exactly what signal RDI signal generated the trap.
The other problem is the the JEENI generates a misleading signal when it
can't talk to the debug macrocell via JTAG.
When I've seen SIGTRAPS that didn't come from breakpoints, it was because
the debug macrocell wasn't responding due to: nTRST being held low, or
other problems with the JTAG signal -- having other devices in the JTAG
chain seems to cause problems.
> Why is the resource "temporarily" unavailable? does GDB think it's coming back?
> maybe it's gone for tea...
--
Grant Edwards
grante@visi.com