From: Daniel Jacobowitz <drow@false.org>
To: Chris Johns <chris@contemporary.net.au>
Cc: gdb@sources.redhat.com
Subject: Re: selecting a processor variant with gdbarch.
Date: Mon, 07 Nov 2005 00:22:00 -0000 [thread overview]
Message-ID: <20051107002238.GA20613@nevyn.them.org> (raw)
In-Reply-To: <436730E3.9040700@contemporary.net.au>
On Tue, Nov 01, 2005 at 08:09:55PM +1100, Chris Johns wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Oct 31, 2005 at 07:08:53PM +1100, Chris Johns wrote:
> >
> >>Hello,
> >>
> >>What is the preferred way to have gdbarch select a specific processor
> >>variant ?
> >
> >
> >Can you be more specific about what you want?
> >
>
> On the Coldfire we have a growing number of processors with a few
> different cores each running the same code, yet with register sets that
> vary in different ways.
Wait, are you talking about multiple slightly heterogeneous cores at
the same time, or across different implementations? I'm not sure from
the above.
> When using BDM with a Coldfire you need to get at some of the processor
> specific registers to access memory controllers to enable RAM to
> download a program.
>
> We can teach a BDM target ops how to detect various processors and make
> the selection. Getting gdbarch to handle the change is what I would like
> to understand.
Take a look at the code on csl-arm-20050325-branch for more information
about this, specifically arm-tdep.c:arm_update_architecture. That's
not what it will look like in GDB HEAD once it is implemented there;
but you can find some more about the topic in the gdb@ list archives
from early this year.
> I have played around with changing the register names and types but
> regcache proved a hurdle. It sets up the cache once during
> initialisation. If I could make a a call to get regcache to
> re-initialise this hurdle could be overcome.
See the bottom of arm_update_architecture for more. The trick is to
switch to a "new" gdbarch.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-11-07 0:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 8:09 Chris Johns
2005-10-31 14:19 ` Daniel Jacobowitz
2005-11-01 9:10 ` Chris Johns
2005-11-07 0:22 ` Daniel Jacobowitz [this message]
2005-11-07 0:37 ` Daniel Jacobowitz
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=20051107002238.GA20613@nevyn.them.org \
--to=drow@false.org \
--cc=chris@contemporary.net.au \
--cc=gdb@sources.redhat.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).