[LLVMdev] How to implement new ELF 64 bit relocation (N64)

[Carter, Jack]

The ELF relocation record format is different for N64 which many Mips 64 ABIs use  than for O64 which many if not all other target ABIs use.

The question I have is whether to treat N64 as a valid generic variant or should it be treated as target specific?

My contention is that it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the target specific level.

Most architectures have the following 64 bit relocation record format:

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Xword  r_info; /* Symbol index and type of relocation */
} Elf64_Rel;

typedef struct
{
Elf64_Addr      r_offset;
Elf64_Xword    r_info;
Elf64_Sxword  r_addend;
} Elf64_Rela;

Whereas N64 has the following format:

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Word  r_sym;     /* Symbol index */
Elf64_Byte  r_ssym;    /* Special symbol */
Elf64_Byte  r_type3;   /* Relocation type */
Elf64_Byte  r_type2;   /* Relocation type */
Elf64_Byte  r_type;     /* Relocation type */
} Elf64_Rel;

typedef struct
{
Elf64_Addr    r_offset; /* Address of reference */
Elf64_Word  r_sym;     /* Symbol index */
Elf64_Byte  r_ssym;    /* Special symbol */
Elf64_Byte  r_type3;   /* Relocation type */
Elf64_Byte  r_type2;   /* Relocation type */
Elf64_Byte  r_type;     /* Relocation type */
Elf64_Sxword  r_addend;
} Elf64_Rela;

The structure is the same size, but the r_info data element is now 5 separate elements. Besides the content aspects, endian byte reordering will be different for the area with each element being endianized separately.

In my mind there are 3 ways to approach this:

  1.  Treat this as target specific :
     *   ELFObjectWriter::RecordRelocation would need to be derived for N64 implementations
  2.  Treat this as generic and continue to pass r_type as an integer masking and unmasking the byte sized N64 values for N64 mode. I've implemented this and it causes no affect on other current targets.
  3.  Treat as generic and changing r_type as a union. This is technically cleaner than (2) but would need to change the r_type type declaration and assignment for each target.

My preference is to treat it as a generic format variation an first implement #2 and then the more intrusive #3.


I have attached a sample patch series, not for submittal yet, but as an example of my local implementation.


Thanks,


Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/9e2941b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-N64.patch
Type: text/x-patch
Size: 7127 bytes
Desc: 01-N64.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/9e2941b2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02-hello_rel.patch
Type: text/x-patch
Size: 9062 bytes
Desc: 02-hello_rel.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120607/9e2941b2/attachment-0001.bin>