This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Advice on architecture with a very large register bank


I'm updating GDB for the OpenRISC 1000 architecture. This has 32 general
purpose registers and nearly 25,000 special purpose registers (SPRs) -
12 banks of 2048.

The special purpose registers cover processor status, MMU control (TLB's
match registers, translation registers), caches, debug via JTAG etc.
They are loaded and stored by two privileged instructions and are *not*
memory mapped.

How should I best handle these in GDB? Since they form part of the state
of the machine, they should be visible. However if I declare them as
registers (which they are), I presume regcache will be huge and
performance terrible.

I could add commands just to display and set SPR's (the current
solution), but this then precludes their use in other GDB contexts. I
also can't see how to implement this within the target operations
structure, so that it would work via the Remote Serial Protocol.

If anyone else has experience of architectures with huge register banks,
I'll be very interested to hear how you deal with this issue.

Thanks,


Jeremy

-  
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]