This is the mail archive of the
insight@sourceware.cygnus.com
mailing list for the Insight project.
Re: Virtual memory and gdb/Insight
- To: Leon Pollak <leonp at plris dot com>
- Subject: Re: Virtual memory and gdb/Insight
- From: Steven Johnson <sbjohnson at ozemail dot com dot au>
- Date: Wed, 31 May 2000 19:27:38 +1000
- CC: insight at sourceware dot cygnus dot com
- References: <4.3.0.20000531102122.00aa5c70@plris.com>
Leon,
Welcome to my world.
I've had this same problem for ages with Codewarrior.
RPRoxy needs to simulate the MMU Operation. I Believe RProxy is distributed
with source?
If this is so, then you will need to put some code in that performs
translation of your virtual
addresses to the targets physical addresses. Such that GDB debugs the virtual
address space, but
RProxy operates on the physical.
I was thinking of doing something like this with my Debugger (when it is
ready) using a memory map file that defines the virtual to physical mapping.
You might find it quicker just to hack a special version of RProxy to modify
the addresses to suit your target.
You could also do it in GDB, but this is harder as you would have to address
all the different targets. Further, Im not sure it affects many people :( Just
you and me. So it is probably easier to put it in the debug stub than trying
to get it integrated into GDB. Also due to the nature of target resident
monitors, this is not a problem for them. (I Hazard a guess to say that >90%
of people using GDB for embedded development use target resident monitors.)
With metrowerks I limit myself to the first contiguous page. To prevent cross
page translation affecting debugging. This may also be an option. (Although it
is not a good one).
Steven.