2
votes

I am writing some custom ELF binary postprocessing code which works on .o files. Part of the processing includes performing relocation on the binary data. The input files are generated by the GNU assembler from my own assembly code.

Look at these crazy relocations which the GNU assembler generated:

Relocation section '.rel.bss' at offset 0x3b8 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000010b 00000301 R_386_32 00000000 .bss 00000110 00000301 R_386_32 00000000 .bss

First of all, it doesn't make any sense to relocate data in .bss. By definition, the data in .bss is all zeroes and cannot be adjusted to become something else.

Second of all, it doesn't make any sense to relocate values relative to the base address of their own section. That would be a no-op.

So what gives?? What are these relocations supposed to mean?

(The asm code which went into this binary contains something like:

.bss
keybuffer:
.space 256

...and later:

.bss
anotherbuffer:
.space 4

That is where the offsets you can see above came from.)

1
Correct me if I'm wrong, isn't the BSS section allocated by the loader just like any other section? It is just that it takes no space in the object file. Also data in the BSS section can be overwritten just like with the DATA section, right? If so why shouldn't it be subject to relocation? I'm not an expert of GAS output but what part of it indicates to "relocate values relative to the base address of their own section"? - Margaret Bloom
@MargaretBloom, since the BSS section takes no space in the object file, it can't contain any pointers, so there is no reason you would apply relocations (= adjusting the value of a pointer in binary data) to it. In the above readelf -r output, you can see that there are relocations for BSS, and the "symbol value" which the (non-existent) pointers in BSS are relocated relative to is byte 0 of BSS = the base address of BSS. - Alex D
@AlexD: Won't you have written code without moving to the .text section? - ninjalj
by definition data in .bss is INITIALIZED to zeros, and is then read/write at runtime, so it can be adjusted. Understand that .o files leave holes for the linker to patch up. when you take this and link it in, does the problem go away? Do the numbers become sane? - old_timer

1 Answers

6
votes

It looks like you have code or data that references these variables in your .bss section. Just creating an assembly file with only your example code doesn't reproduce the problem:

$ cat t115.a
        .bss
keybuffer:
        .space  256

        .bss
anotherbuffer:
        .space  4

$ as --32 t115.a
$ readelf -r a.out

There are no relocations in this file.

However I can reproduce the problem by referencing the symbols in the .bss section:

$ cat t115a.s
        .bss
keybuffer:
        .space  256

        .bss
        mov     $keybuffer, %eax
        .long   anotherbuffer

        .bss
anotherbuffer:
        .space  4

$ as --32 t115a.s
$ readelf -r a.out

Relocation section '.rel.bss' at offset 0xe0 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000101  00000301 R_386_32          00000000   .bss
00000105  00000301 R_386_32          00000000   .bss

The fact that the offset 0000010b in your example output is not even suggests to me that you've accidentally put code in your .bss section.

The relocations are what you would expect. They aren't relative to section .bss they're applied against the local symbol .bss, whose value is the address of the start of .bss section in this file. With the R_386_32 relocation type the value of the symbol is added to the value stored at the target of the relocation (the "addend"). Since in this case the target of the relocation is in a section without any contents (.bss) the value of the addend is 0. If it were an section that had contents (eg. .text or .data) the target of the relocation would contain an offset from the start of the .bss section in the object file.