elf flags information in ArchSpec


We are planning to implement support for various MIPS ABIs (O32, N32, O64 and N64) and application specific extensions (ASE) like DSP and SIMD.

Additionally we are planning to implement microMIPS ISA as an extension to the existing MIPS32/64 bit cores.

Currently there are around 20 MIPS cores added in the ArchSpec.

If we consider the various combinations of ABI+ASE+Core then number of cores for MIPS in (ArchSpec::Core) would increase significantly.

We would like to keep the number of base cores (mips32, mips32r2, mips64 etc.) as it is and evaluate ABIs/ASEs dynamically using elf::ELFHeader::e_flags.

We would need to extend the ArchSpec with the information contained in elf::ELFHeader::e_flags.

ArchSpec will have say “m_flags”, which will be set to elf::ELFHeader::e_flags.

Then this information can be used in

  • ABI plugin to know the ABI contained in the ELF

  • EmulateInstruction plugin to know the ASE (MicroMips for example) and then Emulate the instructions accordingly.

Please let us know your thoughts on this.


This sounds good to me and I think makes sense for ARM as well (based on my understanding). But the real question is what Greg/Jim/ec think.


What parts of the elf::ELFHeader::e_flags aren't able to be represented by the llvm::Triple contained within the ArchSpec?

I would prefer it if an ELF file can set the ArchSpec correctly (including the llvm::Triple). If there is more info needed let me know what that info is and we can figure out how to get it into ArchSpec so it can abstract away the ELF specific bits.


Hi Greg,

The llvm::Triple does not give ABI (32, 64, eabi ,n32 and o64) and Application Specific Extension (ASE) information (like microMIPS) for MIPS.
Thus we would like to use elf::ELFHeader::e_flags so that we can get this information at run-time.


Other platforms like ARM use the environment part to specify the ABI.
Why can't MIPS do that?


I would support to put it into the SubArch instead of to the Environment as Android is treated as an Environment and that one is orthogonal to this information. It would match with the solution on ARM where we put the version into SubArch.