public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* selecting a processor variant with gdbarch.
@ 2005-10-31  8:09 Chris Johns
  2005-10-31 14:19 ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Johns @ 2005-10-31  8:09 UTC (permalink / raw)
  To: gdb

Hello,

What is the preferred way to have gdbarch select a specific processor 
variant ?

How can a target op inform the gdbarch what the specific processor is ?

Regards
Chris

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: selecting a processor variant with gdbarch.
  2005-10-31  8:09 selecting a processor variant with gdbarch Chris Johns
@ 2005-10-31 14:19 ` Daniel Jacobowitz
  2005-11-01  9:10   ` Chris Johns
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2005-10-31 14:19 UTC (permalink / raw)
  To: Chris Johns; +Cc: gdb

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?

> How can a target op inform the gdbarch what the specific processor is ?

Not yet, but I'm working on implementing that.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: selecting a processor variant with gdbarch.
  2005-10-31 14:19 ` Daniel Jacobowitz
@ 2005-11-01  9:10   ` Chris Johns
  2005-11-07  0:22     ` Daniel Jacobowitz
  2005-11-07  0:37     ` Daniel Jacobowitz
  0 siblings, 2 replies; 5+ messages in thread
From: Chris Johns @ 2005-11-01  9:10 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb

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.

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.

> 
>>How can a target op inform the gdbarch what the specific processor is ?
> 
> 
> Not yet, but I'm working on implementing that.
> 

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.


Chris

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: selecting a processor variant with gdbarch.
  2005-11-01  9:10   ` Chris Johns
@ 2005-11-07  0:22     ` Daniel Jacobowitz
  2005-11-07  0:37     ` Daniel Jacobowitz
  1 sibling, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2005-11-07  0:22 UTC (permalink / raw)
  To: Chris Johns; +Cc: gdb

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: selecting a processor variant with gdbarch.
  2005-11-01  9:10   ` Chris Johns
  2005-11-07  0:22     ` Daniel Jacobowitz
@ 2005-11-07  0:37     ` Daniel Jacobowitz
  1 sibling, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2005-11-07  0:37 UTC (permalink / raw)
  To: gdb

[Hoping this reaches you, apologies to the list]

Chris, your From address is bouncing.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-11-07  0:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-31  8:09 selecting a processor variant with gdbarch Chris Johns
2005-10-31 14:19 ` Daniel Jacobowitz
2005-11-01  9:10   ` Chris Johns
2005-11-07  0:22     ` Daniel Jacobowitz
2005-11-07  0:37     ` Daniel Jacobowitz

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).