Virtual memory and gdb/Insight

Virtual memory and gdb/Insight

[Leon Pollak]

Hello, all.
	Please, excuse me, if the theme I arise is solved already, but I didn't 
see any  reminiscences about this.

	I am using Insight for remote debugging of my PowerPC (MPC860) target via 
BDM interface. I don't think that this is important, but still - the scheme 
is as following:
[Linux PC with Insight] <------->Ethernet<----------->[Windows PC with 
rproxy]<--------->Wiggler BDM<---------->[Target Board].
To clarify: rproxy is the program working as remote target for gdb and as 
BDM controller for target (see http://www.std.com/qqi/ ).

Now, everything worked fine up to the moment when I switched on the MMU, 
which was supposed to translate some addresses in my application (I wanted 
to unite to banks of RAM with the space between them).
At that moment, the following occurs - when I stop the program via BDM, the 
MMU is disabled (that is what Motorola states and this happens), so that 
looking in to variables, memory and etc. shows nothing but 0xFFFF..., 
because the virtual address isn't translated into real one.

My question to Motorola staff was answered as following: your problem can 
be solved only by the intelligent software debugger.
Consult this with vendor of your debug system.

And that is what I am doing.
Any reply will be highly appreciated.

leonp@plris.com

Re: Virtual memory and gdb/Insight

[Steven Johnson]

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.

Re: Virtual memory and gdb/Insight

[Andrew Cagney]

[FYI, reply-to set to gdb@sourceware.cygnus.com.  This is a generic GDB
problem and not specific to the insight interface]

Leon Pollak wrote:
> 
> Hello, all.
>         Please, excuse me, if the theme I arise is solved already, but I didn't
> see any  reminiscences about this.
> 
>         I am using Insight for remote debugging of my PowerPC (MPC860) target via
> BDM interface. I don't think that this is important, but still - the scheme
> is as following:
> [Linux PC with Insight] <------->Ethernet<----------->[Windows PC with
> rproxy]<--------->Wiggler BDM<---------->[Target Board].
> To clarify: rproxy is the program working as remote target for gdb and as
> BDM controller for target (see http://www.std.com/qqi/ ).
> 
> Now, everything worked fine up to the moment when I switched on the MMU,
> which was supposed to translate some addresses in my application (I wanted
> to unite to banks of RAM with the space between them).
> At that moment, the following occurs - when I stop the program via BDM, the
> MMU is disabled (that is what Motorola states and this happens), so that
> looking in to variables, memory and etc. shows nothing but 0xFFFF...,
> because the virtual address isn't translated into real one.
> 
> My question to Motorola staff was answered as following: your problem can
> be solved only by the intelligent software debugger.
> Consult this with vendor of your debug system.

Fixing this problem involves adding functionality to GDB (or the remote
server) so that it can emulate virtual->physical memory translations. 
GDB doesn't currently support this feature :-(

This is part of a fairly generic problem.  Another common example is
with kernel debugging using that same interface.  GDB can tell you what
the raw CPU is doing.  It can't display thread information or allow you
to manipulate the more abstract kernel threads.

I'd like to see this problem solved and getting a solution implemented
is in the back of my mind.  Unfortunatly, it does involve many
significant changes.  You can view multi-arch as one small step - there
are many others.

Have a read of the GDB TODO file.

	Andrew