<div dir="ltr">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.<div><br></div><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 10:30 AM, Petr Hosek <span dir="ltr"><<a href="mailto:phosek@google.com" target="_blank">phosek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_8613386652689406934gmail_msg">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 <a href="http://www.airs.com/blog/archives/42" target="_blank">blog post</a> and it is the behavior that ld and gold implements.</div><div dir="ltr" class="m_8613386652689406934gmail_msg"><br></div><div dir="ltr" class="m_8613386652689406934gmail_msg"><div dir="ltr" class="m_8613386652689406934gmail_msg">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.</div></div><div><div class="h5"><div dir="ltr" class="m_8613386652689406934gmail_msg"><div class="m_8613386652689406934gmail_msg"><div class="m_8613386652689406934gmail_msg"><br class="m_8613386652689406934gmail_msg"><div class="gmail_quote m_8613386652689406934gmail_msg"><div dir="ltr" class="m_8613386652689406934gmail_msg">On Tue, Mar 7, 2017 at 4:47 PM Cary Coutant <<a href="mailto:ccoutant@gmail.com" class="m_8613386652689406934gmail_msg" target="_blank">ccoutant@gmail.com</a>> wrote:<br class="m_8613386652689406934gmail_msg"></div><blockquote class="gmail_quote m_8613386652689406934gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> SHN_ABS means "absolute" in the context of the static link.  It's absolute<br class="m_8613386652689406934gmail_msg">
> in the sense that it is not relative to a section.  ELF symbols do not<br class="m_8613386652689406934gmail_msg">
> provide any notion of a runtime absolute address.  The wording describing<br class="m_8613386652689406934gmail_msg">
> SHN_ABS is talking about its meaning in an input ET_REL file at static link<br class="m_8613386652689406934gmail_msg">
> time.  It's wrong to extrapolate this to any more general context.<br class="m_8613386652689406934gmail_msg">
><br class="m_8613386652689406934gmail_msg">
> After the static link, i.e. in any ET_EXEC or ET_DYN object, there is only<br class="m_8613386652689406934gmail_msg">
> one kind of symbol value: The st_value field is a statically "absolute"<br class="m_8613386652689406934gmail_msg">
> address that must be adjusted at runtime by the object's runtime load bias.<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
I disagree. An absolute symbol is absolute in any context. If you have<br class="m_8613386652689406934gmail_msg">
an SHN_ABS symbol in an ET_REL file, the value of that symbol remains<br class="m_8613386652689406934gmail_msg">
unrelocated during the static linking process, and must remain<br class="m_8613386652689406934gmail_msg">
unrelocated during any dynamic linking or loading process. How could<br class="m_8613386652689406934gmail_msg">
it be otherwise? An absolute symbol either refers to a constant<br class="m_8613386652689406934gmail_msg">
(non-address) value, or to an address that is not within the object<br class="m_8613386652689406934gmail_msg">
file image. Any address within the object file image will refer to the<br class="m_8613386652689406934gmail_msg">
contents of a section, and will have a section-relative value.<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
ELF suffers from the fact that its design predates modern shared<br class="m_8613386652689406934gmail_msg">
libraries, and various features to support shared libraries (e.g.,<br class="m_8613386652689406934gmail_msg">
symbol visibility, versions, PT_DYNAMIC, PT_INTERP) have been "bolted<br class="m_8613386652689406934gmail_msg">
on". In a static-only world, the notion that symbol values in an<br class="m_8613386652689406934gmail_msg">
ET_EXEC file could be relocatable or absolute (or even undefined) has<br class="m_8613386652689406934gmail_msg">
no meaning. Of course they were all absolute -- it's a static image.<br class="m_8613386652689406934gmail_msg">
But once you introduce shared libraries, the difference between<br class="m_8613386652689406934gmail_msg">
relocatable and absolute becomes just as important in an ET_DYN as it<br class="m_8613386652689406934gmail_msg">
is in an ET_REL (and similarly for an ET_EXEC once you introduce<br class="m_8613386652689406934gmail_msg">
position-independent executables).<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
The symbols we're talking about in this discussion are<br class="m_8613386652689406934gmail_msg">
linker-generated symbols that refer to locations within the object's<br class="m_8613386652689406934gmail_msg">
image. That they've been created as absolute symbols in the past is<br class="m_8613386652689406934gmail_msg">
simple carelessness, and it's worked for the most part simply because<br class="m_8613386652689406934gmail_msg">
the difference rarely matters (or rarely did up until more aggressive<br class="m_8613386652689406934gmail_msg">
use of PIE). When it does matter, it causes unexpected behavior and we<br class="m_8613386652689406934gmail_msg">
end up in discussions like this; the surest way to avoid unexpected<br class="m_8613386652689406934gmail_msg">
behavior is to clarify the spec and be more careful when creating .<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
> In the runtime view, ELF sections are not a concept that exists, and<br class="m_8613386652689406934gmail_msg">
> neither is SHN_ABS.  The dynamic linker does not do anything with the<br class="m_8613386652689406934gmail_msg">
> st_shndx field in symbol table entries, except to notice the single special<br class="m_8613386652689406934gmail_msg">
> value SHN_UNDEF (zero) as identifying an undefined symbol.  Once the<br class="m_8613386652689406934gmail_msg">
> dynamic linker has chosen a particular symbol table entry in a particular<br class="m_8613386652689406934gmail_msg">
> object to resolve a relocation, it ignores st_shndx entirely; it simply<br class="m_8613386652689406934gmail_msg">
> takes the st_value from the symbol table entry and adds the object's<br class="m_8613386652689406934gmail_msg">
> runtime load bias.  If you have a dynamic relocation that refers to a<br class="m_8613386652689406934gmail_msg">
> SHN_ABS symbol with st_value 0, then it resolves to the runtime load bias<br class="m_8613386652689406934gmail_msg">
> of the object defining that symbol (plus 0), not to absolute 0.<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
I argue that it is not true that the concept of sections doesn't exist<br class="m_8613386652689406934gmail_msg">
in the runtime view; it's simply that the section header table is<br class="m_8613386652689406934gmail_msg">
optional for non-ET_REL objects. That doesn't mean that the concept of<br class="m_8613386652689406934gmail_msg">
a section doesn't exist, nor that the st_shndx field isn't used. It is<br class="m_8613386652689406934gmail_msg">
still necessary to distinguish between undefined and defined, and<br class="m_8613386652689406934gmail_msg">
between absolute and relocatable, and the st_shndx field is the way to<br class="m_8613386652689406934gmail_msg">
do that. There is no reasonable interpretation otherwise, and nothing<br class="m_8613386652689406934gmail_msg">
in the spec to suggest that SHN_ABS applies only to ET_REL objects.<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
(OK, I'll grant that the line "the section offset (file<br class="m_8613386652689406934gmail_msg">
interpretation) gives way to a virtual address (memory interpretation)<br class="m_8613386652689406934gmail_msg">
for which the section number is irrelevant" could be taken to suggest<br class="m_8613386652689406934gmail_msg">
that, but to do so leads to the fundamental problem where we cannot<br class="m_8613386652689406934gmail_msg">
distinguish between relocatable and absolute. It says the "section<br class="m_8613386652689406934gmail_msg">
number" is irrelevant, not the st_shndx value. That paragraph really<br class="m_8613386652689406934gmail_msg">
should be rewritten. What it's trying to communicate is that, in an<br class="m_8613386652689406934gmail_msg">
ET_EXEC or ET_DYN object, the symbol value is not relative to the<br class="m_8613386652689406934gmail_msg">
beginning of its section, as it is in an ET_REL object.)<br class="m_8613386652689406934gmail_msg">
<br class="m_8613386652689406934gmail_msg">
-cary<br class="m_8613386652689406934gmail_msg">
</blockquote></div></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>