This is an archive of the discontinued LLVM Phabricator instance.

ELF/ARM: Ignore R_ARM_V4BX but allow linking
AbandonedPublic

Authored by zatrazz on Apr 15 2015, 11:57 AM.

Details

Summary

This patch allow the ARM relocation R_ARM_V4BX to be processed by lld,
although it is not really handled in the static relocation code. The
relocation is in the form:

Relocation section '.rel.text' at offset 0x428 contains 4 entries:
Offset Info Type Sym.Value Sym. Name
00000014 00000028 R_ARM_V4BX

Meaning it does have a direct target, but rather references to an absolute
section *ABS* (in this exemple to the .text segment itself). It makes the
target Atom after file parse to not have a associated pointer and thus
generating a derrefence NULL point in ELFFile<ELFT>::findAtom. Current
approach is just ignore and return nullptr in such cases.

The problem relies that default GCC configuration
for arm-linux-gnueabi{hf} emits the relocation for the asm:

.syntax unified
.arm

.p2align 2
.type fn, %function
fn:

ldr r3, .LGOT
ldr r2, .LGOT+4

.LPIC:

add r3, pc, r3
ldr r2, [r3, r2]
cmp r2, #0
bxeq lr
b __start__

.LGOT:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC+8)

.word start(GOT)

But only with the option -march=armv4 (which is the default GCC configuration).
For arm5 and forward the relocation is not created. This a special relocation
(defined miscellaneous for ARM) that instruct the linker to replace the bx
instruction into a mov. GNU linker has some options related to which substitution
it can create for such cases.

With this patch I can dynamically link an application against a GLIBC
arm-linux-gnueabi system configured with default GCC.

Diff Detail

Event Timeline

zatrazz updated this revision to Diff 23793.Apr 15 2015, 11:57 AM
zatrazz retitled this revision from to ELF/ARM: Ignore R_ARM_V4BX but allow linking.
zatrazz updated this object.
zatrazz edited the test plan for this revision. (Show Details)
zatrazz added reviewers: ruiu, shankar.easwaran.
zatrazz added a project: lld.
zatrazz added subscribers: Unknown Object (MLST), lld.
shankarke accepted this revision.Apr 15 2015, 12:06 PM
shankarke added a reviewer: shankarke.
shankarke added a subscriber: shankarke.

LGTM.

This revision is now accepted and ready to land.Apr 15 2015, 12:06 PM
ruiu edited edge metadata.Apr 15 2015, 1:25 PM

It feels to me that creating a dangling reference having a null pointer is wrong in the first place. I think in most places we don't expect a reference having a null pointer. Conceptually it's a directed edge of a graph, so there must be a vertex when you follow an edge.

Does this really need to be treated that way? Is there any other way to handle this in the same manner as other symbols/references?

This was my very question in the first patch about it I sent:

I am not certainly that it is the right approach to handle this cases in arch-neutral
code, so I am more than willing to hear better suggestions.

And I am not aware of a similar relocation with same constraints,
so I am not sure which model will fit better. Some options I can
think is to make it reference to itself or to an special symbol.

A relocation to nothing has a symbol index which points to the local undef symbol, the first symbol in the symbol table entry. We could keep that symbol as the sentinel symbol and make the null reference point to that.

zatrazz abandoned this revision.Apr 21 2015, 11:14 AM