From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Leon Pollak Cc: insight@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Virtual memory and gdb/Insight Date: Wed, 31 May 2000 02:57:00 -0000 Message-id: <3934E1AD.39F04777@cygnus.com> References: <4.3.0.20000531102122.00aa5c70@plris.com> X-SW-Source: 2000-q2/msg00228.html [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