relocation section header information in .elf file

Question

My apology for my poor English, really having a hard time understanding what is the sh_info field contains for relocation section, following is what I get from the ELF document:

enter image description here

It says

sh_info : contains the section header index of the section to which the relocation applies

sh_link: contains the section header index of the associated symbol table.

Clearly: sh_info is not about the symbol table section that the relocation section relates to, whose information is stored in sh_link.

Based on my understanding: when relocating a symbol, three sections are related: the relocation section, the symbol table section, and the section which contains symbols' definition for symbols in the symbol table.

Assumption 1: So I assume sh_info is about the third section mentioned ahead

-----However, when I go through the sample code for relocation, my assumption seems not match

static int elf_do_reloc(Elf32_Ehdr *hdr, Elf32_Rel *rel, Elf32_Shdr *reltab) {
Elf32_Shdr *target = elf_section(hdr, reltab->sh_info);
int addr = (int)hdr + target->sh_offset;
int *ref = (int *)(addr + rel->r_offset);

// Symbol value
int symval = 0;
if(ELF32_R_SYM(rel->r_info) != SHN_UNDEF) {
    symval = elf_get_symval(hdr, reltab->sh_link, ELF32_R_SYM(rel->r_info));
    if(symval == ELF_RELOC_ERR) return ELF_RELOC_ERR;
}

-----Sicce r_info is a field only entry in relocation section contains

which means sh_info is the index of the relocation section itself. < Assumption 2

What confuses me more is the an example someone else posts, reading elf file example

it seems the sh_info field information is nothing related to my previous 2 assumptions

Could anyone please help explain what does sh_info really contains?

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

About the "confusing example", maybe relocation part got deleted but only mention of sh_info is related to parsing of (dynamic) symbols name and (as show in image in your question) that field has different meaning for SHT_SYMTAB and SHT_DYNSYM (number of items in section + 1).

Section #0A        OFF: 0x000015F8
    Name:      .rela.plt (0x00000084)
    Type:      SHT_RELA (0x00000004)
    Flags:     -a-
    Addr:      0x004003E8
    Offset:    0x000003E8
    Size:      0x00000090
    Link:      0x00000005
    Info       0x0000000C
    
Section #05        OFF: 0x000014B8
    Name:      .dynsym (0x0000004E)
    Type:      SHT_DYNSYM (0x0000000B)
    Flags:     -a-
    Addr:      0x00400280
    Offset:    0x00000280
    Size:      0x000000A8
    Link:      0x00000006
    Info       0x00000001
    
Section #0C        OFF: 0x00001678
    Name:      .plt (0x00000089)
    Type:      SHT_PROGBITS (0x00000001)
    Flags:     -ax
    Addr:      0x004004A0
    Offset:    0x000004A0
    Size:      0x00000070
    Link:      0x00000000
    Info       0x00000000

You can see that sh_link points to .dynsym section and sh_info points to .plt section (which contains executable memory).

So sh_link is symbol table and sh_info is executable section that gets modified.

Basically your document says it all already, but here are some more references.

Chapter on Sections [Figure 4-12: sh_link and sh_info Interpretation]:

sh_link - The section header index of the associated symbol table.

sh_info - The section header index of the section to which the relocation applies.

Also there's a chapter on relocation:

A relocation section references two other sections: a symbol table and a section to modify. The section header's sh_info and sh_link members, described in ``Sections'' above, specify these relationships. Relocation entries for different object files have slightly different interpretations for the r_offset member.

In relocatable files, r_offset holds a section offset. The relocation section itself describes how to modify another section in the file; relocation offsets designate a storage unit within the second section.

In executable and shared object files, r_offset holds a virtual address. To make these files' relocation entries more useful for the dynamic linker, the section offset (file interpretation) gives way to a virtual address (memory interpretation).

And just for fun... Here are (search page) relocation types for x86 on Linux:

#define R_X86_64_NONE           0       /* No reloc */
#define R_X86_64_64             1       /* Direct 64 bit  */
#define R_X86_64_PC32           2       /* PC relative 32 bit signed */
#define R_X86_64_GOT32          3       /* 32 bit GOT entry */
#define R_X86_64_PLT32          4       /* 32 bit PLT address */
#define R_X86_64_COPY           5       /* Copy symbol at runtime */
#define R_X86_64_GLOB_DAT       6       /* Create GOT entry */
#define R_X86_64_JUMP_SLOT      7       /* Create PLT entry */
#define R_X86_64_RELATIVE       8       /* Adjust by program base */
#define R_X86_64_GOTPCREL       9       /* 32 bit signed pc relative
                                            offset to GOT */
#define R_X86_64_32             10      /* Direct 32 bit zero extended */
#define R_X86_64_32S            11      /* Direct 32 bit sign extended */
#define R_X86_64_16             12      /* Direct 16 bit zero extended */
#define R_X86_64_PC16           13      /* 16 bit sign extended pc relative */
#define R_X86_64_8              14      /* Direct 8 bit sign extended  */
#define R_X86_64_PC8            15      /* 8 bit sign extended pc relative */

relocation section header information in .elf file

1 Answers1