search

NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
50.95k stars 5.81k forks source link

TriCore Naming Convention Issue #2399

Open cyber-wizard-sedridor opened 3 years ago

cyber-wizard-sedridor commented 3 years ago

Hello,

While this isn't anything that will affect the performance of Ghidra or make it any better or worse at decompiling tricore code, I've noticed a few issues with the current tricore naming conventions.

While TriCore is a base architecture that Ghidra decompiles/parses, the variations of TriCore that Ghidra supports ("tc29x", "tc172x", etc) are referring to series of Microcontrollers developed by Infineon, not actually versions of the TriCore architecture itself. For example, the tc29x.pspec refers specifically to the Infineon AURIX TC29x microcontroller, which is based on the TriCore 1.6 architecuture.

Because of this, it might be a bit better to name the variants something like "AURIX TC29x", rather than just "TC29x", to show that it's the microcontroller version/variation, not TriCore version.

Additionally, the current manual index files have fairly misleading names: tricore.idx and tricore2.idx. The tricore.idx file is actually defining the TriCore v1.3 instruction set, and the tricore2.idx file is defining the AURIX TC2xx-specific instruction set (which is based on TriCore v1.6), making the name "tricore2" not quite correct.

I know these are sort of nitpicking issues, but I figured they should be straightened out before more TriCore-based microcontrollers are added to the repo. If we add more TriCore v1.6-based microcontrollers, for example, referring them to the same tricore2.idx file wouldn't be correct, due to it referencing AURIX TC2xx specifically.

One other thing to note: I know that TC2XX's User Manual Volume 2 defines the entire instruction set for AURX TC2XX-based processors, but is this instruction set different than the TriCore V1.6 architecture that it's based on? Are additional, generation-specific instructions added? (I have no idea - if a TriCore god out there knows, feel free to comment! :smile: )

I think a choice should be made: Should the .idx files be based on the overarching TriCore specification (v1.3, v1.6, etc) or the specific microcontroller that's being defined in the pspec? (AURIX TC21x, AURIX TC22x, AURIX TC23x, etc)

I'm hoping this can help to straighten out some of the naming conventions to make adding additional TriCore architectures or TriCore-based microcontrollers easier in the future.

Thanks! :mage_man:

nuschpl commented 9 months ago

choice should be made: Should the .idx files be based on the overarching TriCore specification (v1.3, v1.6, etc) or the specific microcontroller that's being defined in the pspec? (AURIX TC21x, AURIX TC22x, AURIX TC23x, etc)

@GhidorahRex Any chance you could suggest the way that will be further merged in PR ? Both the free manpower and arch/uC documentation are around but we need to know the direction.

GhidorahRex commented 9 months ago

The names for the pspec files are fine - they denote specific processor variants. Based on the documentation I could find at the infineon site, TC1xx processors are v1.3 (the TC17xx AUDOMAX are a mix of 1.3 and 1.6), TC2xx are v1.6, and TC3xx are v1.6.2. I don't think there's any confusion between TC29x and AURIX TC29x so I'm not sure what the purpose of adding the additional name there. I haven't done any research on the differences between 1.6 and 1.6.2, in which case we may need a separate TC3xx or we may be able to just continue using the default one and update it for v1.6.2 - some additional research would need to be done here.

As far as using the tricore2.idx file for additional 1.6 processors, that should be fine. Although the pdf name suggests otherwise, the document is not for just the TC2xx processors. The actual document (TriCore® TC1.6P & TC1.6E Instruction Set) specifically mentions "Unless stated otherwise in the text, all descriptions are common to all TriCore versions listed in this preface," so it's more general than just the TC2xx. I haven't investigated individual instructions for backwards compatibility, but if 1.3 instructions behave the same in 1.3 and 1.6, then we could reduce the .idx files to a single file with two document listings, which would be simpler. We do that in many other places.

Generally speaking, the index files should be based on the ISA referenced where possible. For some processors, there are instructions specific to individual processor lines, but that isn't the case here.

I'll raise the issue and figure out what the consensus is for the issues.