This is the mail archive of the gdb-patches@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]

Re: [RFC] Add support for Renesas RX architecture


On Mon, Dec 7, 2009 at 3:19 PM, DJ Delorie <dj@redhat.com> wrote:
>
>> Rather, it's that such support was always planned, it just needed
>> someone to add it.
>
> For the record, here's the limitations I've found...
>
> * The opcode descriptions are generated by exploding macros to get all
> ?the prefix/operand byte permutations (about 12,000 total). ?I.e. a
> ?single variable-length opcode is converted into dozens of
> ?fixed-length opcodes. ?Regenerating takes about an hour, and
> ?maintenance is a nightmare.

That was always just a temp hack until var-length support was complete.
[at which time, btw, cgen will no longer be responsible for 4MB source
files in opcodes :-)]

btw, for reference sake, some basic changes in cgen's data structures
brought the time down for m32c from 30mins to 5mins last time I
visited this.  It's still too long, and more can be done, but it was
easy to do.

> * cgen doesn't handle the opcode-vs-decodable bits in m32c very well.
> ?The hash table has nothing left to work with (every bit is an
> ?operand in *some* opcode), so the disassembler takes a noticably
> ?long time starting up, especially given that the exploding macros
> ?create many opcodes to hash.

I can't imagine there being anything inherent in cgen that prohibits a solution.
If a hash table isn't the best tool for a particular port, we can add
something that is.

> * The disassembler always reads MAX(opsize) bytes, so the .text
> ?sections have to be padded with NOP bytes to prevent crashes.

Ditto.


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