Relative relocation (RELR) and libelf interface

[Mark Wielaard]

Hi,

It seems everybody implemented support for Relative relocations (RELR)
even though it doesn't seem to have been included in the ELF spec yet.
What is the status of the Elf spec updates?

elfutils libelf didn't have support for this yet, so I am looking what
the best interface is. Since there are a couple of different libelf
implementations out there it would be good to coordinate so we are
using the same types/macros.

For elf.h we have:

typedef Elf32_Word Elf32_Relr;
typedef Elf64_Xword Elf64_Relr;

#define ELF32_R_JUMP(val) ((val) >> 24)
#define ELF32_R_BITS(val) ((val) & 0xffffff)

#define ELF64_R_JUMP(val) ((val) >> 56)
#define ELF64_R_BITS(val) ((val) & 0xffffffffffffff)

Then for gelf.h we have:

typedef Elf64_Relr Gelf_Relr;

#define GELF_R_JUMP(val) ELF64_R_JUMP (val)
#define GELF_R_BITS(val) ELF64_R_BITS (val)

And then for libelf.h we would add:

ELF_T_RELR as opaque member of Elf_Type associated with contents of a
SHT_RELR section for the Elf_Data d_type.

This can then be transparently used by getdata, fsize and xlate
functions.

Also, to be consistent with Rel and Rela, we might want to add:

GElf_Relr *gelf_getrelr (Elf_Data *data, int ndx, GElf_Relr *dst);
int gelf_update_relr (Elf_Data *dst, int ndx, GElf_Relr *src);

But given that the actual Relr is really just an offset and the data is
all implicit maybe this is overkill?

Did I miss something?

Thanks,

Mark

[Roland McGrath]

It's not entirely clear a new Elf_Type is needed. As far as the encoding goes, it's really just an array of ELF_T_ADDR (I would have just used ElfNN_Addr and not bothered with ElfNN_Relr).  That's enough for the libelf layer to byte-swap and the gelf layer to zero-extend. I'm confused by your bitfield macros, since the DT_RELR / SHT_RELR format I'm familiar with doesn't have a magic high byte, it only has a magic low bit. Regardless, the consumer has to know which size the format was originally to apply it correctly, because the bitmask words imply a skip of (bit_width - 1) in the r_offset value. So the gelf layer is never going to be producing a result that can be used completely generically.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/ed1371ba98d5e369cce9db7b532c3234f4b07157.camel%40klomp.org.

[Mark Wielaard]

Hi Roland,

On Fri, Jul 14, 2023 at 11:18:07AM -0700, 'Roland McGrath' via Generic System V Application Binary Interface wrote:
> It's not entirely clear a new Elf_Type is needed. As far as the encoding
> goes, it's really just an array of ELF_T_ADDR (I would have just used
> ElfNN_Addr and not bothered with ElfNN_Relr). That's enough for the libelf
> layer to byte-swap and the gelf layer to zero-extend.

Yes, or maybe ELF_T_OFF. But we already have ElfNN_Relr (at least in
glibc elf.h) with Elf32_Word/Elf64_XWord, so it seems nicest to just
make it its own type.

> I'm confused by your
> bitfield macros, since the DT_RELR / SHT_RELR format I'm familiar with
> doesn't have a magic high byte, it only has a magic low bit. Regardless,
> the consumer has to know which size the format was originally to apply it
> correctly, because the bitmask words imply a skip of (bit_width - 1) in the
> r_offset value. So the gelf layer is never going to be producing a result
> that can be used completely generically.

Yes, I think they might have come from Gary's original proposal where
each entry had a (high byte) delta and a bitmap. Lets not add any
value macros because this isn't how things are encoded in the latest
proposal.

I hope the rest is correct.

Since I clearly picked up some bits from a previous/old proposal, what
is the final spec? Is the proposal as posted by Rahul Chaudhry on Feb
13, 2018 what was adopted?
https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/YT2RrjpMAwAJ

And should this be considered already being part of gabi?

Thanks,

Mark

[Roland McGrath]

Yes, that's the DT_RELR / SHT_RELR format now deployed: low bit clear for new effective r_offset of implied RELATIVE reloc; low bit set for (address_bits - 1) high bits of saying whether each of the corresponding next (address_bits - 1) address-size words after "current" effective r_offset have implied RELATIVE reloc; second word with low bit set adjusts the effective r_offset by (address_bits - 1) * address_size and iterates with the new bitmap, etc.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/20230715145227.GC29669%40gnu.wildebeest.org.

[Mark Wielaard]

I finally submitted my changes to elfutils libelf, eu-readelf and
eu-elflint for supporting Relative relocations by adding ELF_T_RELR to
Elf_Type.

https://inbox.sourceware.org/elfutils-devel/20230823220211...@klomp.org/T/#u
https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=relr