This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


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

Re: Virtual memory and gdb/Insight


[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

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