llvm dev - Jun 2012 - [LLVMdev] How to implement new ELF 64 bit relocation (N64)

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>

I'm resending this since many of the folks that would be interested in ELF
direct object relocations were out last week.

________________________________
From: Carter, Jack
Sent: Thursday, June 07, 2012 12:43 PM
To: List
Subject: How to implement new ELF 64 bit relocation (N64)

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/20120614/325efe2c/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/20120614/325efe2c/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/20120614/325efe2c/attachment-0001.bin>