Re: MIPS: Handle the DSP registers

[Nigel Stephens <nigel@mips.com>]

Daniel Jacobowitz wrote:
> On Tue, Dec 18, 2007 at 01:41:44PM +0000, Nigel Stephens wrote:
>   
>> Sounds like this mechanism could rapidly get unwieldy if there were many
>> disjoint, optional register sets supported by an architecture -- would
>> you need a different description for each possible permutation? For
>> example with a bare-iron target you might want to omit the
>> floating-point register descriptions for CPUs which don't have a h/w
>> FPU, so then we've got Base, Base+FPU, Base+DSP, Base+FPU+DSP. Then
>> double again for 32-bit vs 64-bit, and so on. Or have I missed something.
>>     
>
> You have, but it's a very small thing.
>
> The hand-written descriptions in the GDB source code serve three
> purposes.  They are used for gdbserver (which could be made smarter);
> they are used for GDB (but only to eliminate the build dependency on
> expat); and they are used as canonical examples for stub writers.
>
> There's at least two ways we could support a large set of combinations
> in GDB.  One is to require expat, provide XML files at the feature
> level, and generate the top level target description using strcat
> (one of CodeSourcery's stubs does it this way).   The other is to
> adjust the precompiling process, which currently generates a callable
> C function per target description, to generate functions at the
> feature level and call those from within GDB.  That's a bit nicer.
>   

Yes, FWIW my vote would be for function per feature.


> Since so far we only support MIPS with an attached FPU (due to change
> somewhere in MTI's GDB patch collection, I think?) there's only four
> descriptions, so no one's bothered to do that flexibility yet.  But
> the framework is there when we need it :-)
>
> gdbserver is not very bright; its register set is selected entirely at
> compile time and the C parts know a bit about the layout of the XML
> parts.  Eventually, it's going to grow multiple description support
> just like GDB, I think.  I just haven't needed it yet.
>
>   

OK, thanks.

Nigel