[PATCH] D26133: [ELF] Allow relative relocations to absolute symbols in PIC

[Cary Coutant via llvm-commits]

> SHN_ABS means "absolute" in the context of the static link.  It's absolute
> in the sense that it is not relative to a section.  ELF symbols do not
> provide any notion of a runtime absolute address.  The wording describing
> SHN_ABS is talking about its meaning in an input ET_REL file at static link
> time.  It's wrong to extrapolate this to any more general context.
>
> After the static link, i.e. in any ET_EXEC or ET_DYN object, there is only
> one kind of symbol value: The st_value field is a statically "absolute"
> address that must be adjusted at runtime by the object's runtime load bias.

I disagree. An absolute symbol is absolute in any context. If you have
an SHN_ABS symbol in an ET_REL file, the value of that symbol remains
unrelocated during the static linking process, and must remain
unrelocated during any dynamic linking or loading process. How could
it be otherwise? An absolute symbol either refers to a constant
(non-address) value, or to an address that is not within the object
file image. Any address within the object file image will refer to the
contents of a section, and will have a section-relative value.

ELF suffers from the fact that its design predates modern shared
libraries, and various features to support shared libraries (e.g.,
symbol visibility, versions, PT_DYNAMIC, PT_INTERP) have been "bolted
on". In a static-only world, the notion that symbol values in an
ET_EXEC file could be relocatable or absolute (or even undefined) has
no meaning. Of course they were all absolute -- it's a static image.
But once you introduce shared libraries, the difference between
relocatable and absolute becomes just as important in an ET_DYN as it
is in an ET_REL (and similarly for an ET_EXEC once you introduce
position-independent executables).

The symbols we're talking about in this discussion are
linker-generated symbols that refer to locations within the object's
image. That they've been created as absolute symbols in the past is
simple carelessness, and it's worked for the most part simply because
the difference rarely matters (or rarely did up until more aggressive
use of PIE). When it does matter, it causes unexpected behavior and we
end up in discussions like this; the surest way to avoid unexpected
behavior is to clarify the spec and be more careful when creating .

> In the runtime view, ELF sections are not a concept that exists, and
> neither is SHN_ABS.  The dynamic linker does not do anything with the
> st_shndx field in symbol table entries, except to notice the single special
> value SHN_UNDEF (zero) as identifying an undefined symbol.  Once the
> dynamic linker has chosen a particular symbol table entry in a particular
> object to resolve a relocation, it ignores st_shndx entirely; it simply
> takes the st_value from the symbol table entry and adds the object's
> runtime load bias.  If you have a dynamic relocation that refers to a
> SHN_ABS symbol with st_value 0, then it resolves to the runtime load bias
> of the object defining that symbol (plus 0), not to absolute 0.

I argue that it is not true that the concept of sections doesn't exist
in the runtime view; it's simply that the section header table is
optional for non-ET_REL objects. That doesn't mean that the concept of
a section doesn't exist, nor that the st_shndx field isn't used. It is
still necessary to distinguish between undefined and defined, and
between absolute and relocatable, and the st_shndx field is the way to
do that. There is no reasonable interpretation otherwise, and nothing
in the spec to suggest that SHN_ABS applies only to ET_REL objects.

(OK, I'll grant that the line "the section offset (file
interpretation) gives way to a virtual address (memory interpretation)
for which the section number is irrelevant" could be taken to suggest
that, but to do so leads to the fundamental problem where we cannot
distinguish between relocatable and absolute. It says the "section
number" is irrelevant, not the st_shndx value. That paragraph really
should be rewritten. What it's trying to communicate is that, in an
ET_EXEC or ET_DYN object, the symbol value is not relative to the
beginning of its section, as it is in an ET_REL object.)

-cary