public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Leon Pollak <leonp@plris.com>
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	[thread overview]
Message-ID: <3934E1AD.39F04777@cygnus.com> (raw)
In-Reply-To: <4.3.0.20000531102122.00aa5c70@plris.com>

[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

      parent reply	other threads:[~2000-05-31  2:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-31  1:13 Leon Pollak
2000-05-31  2:34 ` Steven Johnson
2000-05-31  2:57 ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3934E1AD.39F04777@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=insight@sourceware.cygnus.com \
    --cc=leonp@plris.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).