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

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 8 10:50:22 PST 2017


In executables and DSOs, if the st_shndx is neither of the special values
SHN_ABS or SHN_UNDEF, the st_value is interpreted to be relative to the
image base, not the start of the section. So you can pick an arbitrary
st_shndx that is neither of those two values, such as 1. That is how we
represent __ehdr_start for example.

Peter

On Wed, Mar 8, 2017 at 10:30 AM, Petr Hosek <phosek at google.com> wrote:

> Rafael suggested using any section value other than SHN_ABS and SHN_UNDEF,
> but that means the symbol is going to have a section relative value which
> means the section must have the address 0x0. The only candidate I can think
> of is .shstrtab or creating a new synthetic section. It was my
> understanding that the purpose of SHN_ABS is to express that: symbols that
> are not relative to any other section. Those symbols exists, even in ET_DYN
> objects, e.g. _gp and _gp_disp on MIPS. This is also what Ian described in
> his blog post <http://www.airs.com/blog/archives/42> and it is the
> behavior that ld and gold implements.
>
> I'd really like to come up with an acceptable solution because we cannot
> currently link our C library with LLD as a consequence of this issue.
>
> On Tue, Mar 7, 2017 at 4:47 PM Cary Coutant <ccoutant at gmail.com> wrote:
>
> > 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
>
>


-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170308/ae19fa3e/attachment.html>


More information about the llvm-commits mailing list