search for: mipstargetinfo

...advice how to support both big and little endian MIPS targets in the new LLD ELF design and escape code duplication. MIPS 32-bit big and little endian targets are very similar and differ in read/write functions. There are some options how to support both but I cannot make the best choice. 1. Make MipsTargetInfo a class template. Use the template's argument to select read/write routines. 2. Pass boolean argument to the MipsTargetInfo constructor. Use this argument to select read/write routines. 3. Create a hierarchy of MipsTargetInfo classes. Keep common code in the MipsTargetInfo class, move endian-de...

...R_MIPS_HI16 relocation, iterate remaining relocations list to find matching R_MIPS_LO16. 2. Calculate combined adddend and apply relocation or show warning if the R_MIPS_LO16 is not found. Method A requires some sort of container to keep postponed HI16 relocations. If we add the container to the `MipsTargetInfo` class we will be able to hide all this unusual scheme inside MIPS specific code and will not need to perform LO16 lookups. But the `MipsTargetInfo` becomes stateful. Method B keeps the `MipsTargetInfo` stateless but requires forward LO16 lookup for each HI16 relocation and requires to provide an...

...elocations list to find matching R_MIPS_LO16. >> 2. Calculate combined adddend and apply relocation or show warning if >> the R_MIPS_LO16 is not found. >> >> Method A requires some sort of container to keep postponed HI16 >> relocations. If we add the container to the `MipsTargetInfo` class we >> will be able to hide all this unusual scheme inside MIPS specific code >> and will not need to perform LO16 lookups. But the `MipsTargetInfo` >> becomes stateful. >> >> Method B keeps the `MipsTargetInfo` stateless but requires forward >> LO16 lookup...

...>> >> 2. Calculate combined adddend and apply relocation or show warning if >> >> the R_MIPS_LO16 is not found. >> >> >> >> Method A requires some sort of container to keep postponed HI16 >> >> relocations. If we add the container to the `MipsTargetInfo` class we >> >> will be able to hide all this unusual scheme inside MIPS specific code >> >> and will not need to perform LO16 lookups. But the `MipsTargetInfo` >> >> becomes stateful. >> >> >> >> Method B keeps the `MipsTargetInfo` statel...

...et. Now LLD in the `InputSectionBase<ELFT>::relocate` methods hides original type of GOT relocations and always use the result of `Target->getGotRefReloc()` call. In case of MIPS it is R_MIPS_GOT16. It makes impossible to perform target symbol type checking and the error generation in the `MipsTargetInfo<ELFT>::relocateOne` method. Is it really necessary to hide original relocation type? If a target has multiple GOT related relocations it might just add more `cases` to its `relocateOne` method. [1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf page 4-19 [2] ftp://www.linux-mip...