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