From: Florian Weimer <fw@deneb.enyo.de>
To: Kaylee Blake <klkblake@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: RFC: [PATCH] ELF: Don't require section header on ELF objects
Date: Mon, 09 Mar 2020 15:52:57 +0100 [thread overview]
Message-ID: <87lfo98trq.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <e6b6dce2-20a0-584e-15e6-4088eea45243@gmail.com> (Kaylee Blake's message of "Tue, 10 Mar 2020 00:15:27 +1030")
* Kaylee Blake:
> On 9/3/20 11:59 pm, Florian Weimer wrote:
>> * Kaylee Blake:
>>
>>>> I think that's conceptually the wrong thing to do for ELF, sorry. If
>>>> there is no section header, the object should be unlinkable. The
>>>> linker should not use the dynamic segment to locate the symbol
>>>> information, only the dynamic section (in case the link ABI and
>>>> run-time ABI are different).
>>>
>>> I'm confused by your comment about link and run-time ABIs differing;
>>> surely if the ABI at runtime differs from the ABI at link time, you are
>>> just going to crash at runtime?
>>
>> No, the typical application are fewer symbols in the DSO at link time
>> than at load time, for example for linking against an older version of
>> glibc than is installed on the system.
>
> How is that being done?
libc.so is replaced with something that contains a stub library which
only exports the intended symbols, at the right versions.
If I recall correctly, some enterprise database products are linked
using ld against such a stub library upon installation. It's a bit
weird for sure, but it's what people do.
> On my machine, the symbols in glibc found through the section header
> are identical to the ones found through the dynamic array, except
> that some of the latter are missing symbol versions, which I think
> is due to this patch not looking them up?
Ah, didn't know that the compat symbols (those with @ symbol versions
instead of @@ synbol versions) are not present in .symtab. That makes
sense, given that they are not supposed to be linked against for new
binaries. We should definitely keep hiding symbols which lack a
default symbol version.
next prev parent reply other threads:[~2020-03-09 14:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-08 17:59 H.J. Lu
2020-03-08 18:06 ` H.J. Lu
2020-03-08 23:35 ` Alan Modra
2020-03-08 23:46 ` H.J. Lu
2020-03-09 0:02 ` H.J. Lu
2020-03-09 0:02 ` Kaylee Blake
2020-03-09 0:05 ` Alan Modra
2020-03-09 1:36 ` H.J. Lu
2020-03-09 1:59 ` Kaylee Blake
2020-03-09 2:23 ` Alan Modra
2020-03-09 2:35 ` H.J. Lu
2020-03-09 4:14 ` H.J. Lu
2020-03-09 4:59 ` Kaylee Blake
2020-03-09 11:56 ` Alan Modra
2020-03-08 23:24 ` Kaylee Blake
2020-03-08 23:29 ` H.J. Lu
2020-03-08 23:38 ` Alan Modra
2020-03-08 23:45 ` H.J. Lu
2020-03-12 2:14 ` Fangrui Song
2020-03-09 8:13 ` Florian Weimer
2020-03-09 12:54 ` Kaylee Blake
2020-03-09 13:06 ` Florian Weimer
2020-03-09 13:14 ` Kaylee Blake
2020-03-09 13:16 ` Florian Weimer
2020-03-09 13:28 ` Kaylee Blake
2020-03-09 13:29 ` Florian Weimer
2020-03-09 13:45 ` Kaylee Blake
2020-03-09 13:54 ` H.J. Lu
2020-03-09 14:02 ` Kaylee Blake
2020-03-09 14:52 ` Florian Weimer [this message]
2020-03-09 15:07 ` Kaylee Blake
2020-03-09 15:29 ` Florian Weimer
2020-03-09 13:44 ` Alan Modra
2020-03-09 13:54 ` Kaylee Blake
2020-03-09 22:34 ` Alan Modra
2020-03-10 0:14 ` H.J. Lu
2020-03-09 14:34 ` Michael Matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfo98trq.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=binutils@sourceware.org \
--cc=klkblake@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).