[PATCH] D32887: [ELF] Emit __ehdr_start when there is a segment containing program headers

[Petr Hosek via llvm-commits]

On Tue, May 9, 2017 at 1:56 PM Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> * Add an extra walk, but only if we know the link will fail. I *think*
>   this was what the previous patch did. IMHO so far this is the best
>   option.
>

That's the one I implemented initially.


> * Report this particular undefined symbol with less information. I would
>   save this as an easy last resort.
>

I considered this option, it'd be easy to implement but it's undesirable.


> * Always define the symbol.
>

I'm fine implementing this as an initial solution.


> * Report undefined symbols in InputSection::relocateNonAlloc and
>   InputSectionBase::relocate instead of the current location (requires a
>   benchmark).
>

I considered this but haven't implemented it as it's a bigger change. I can
give it a try to see what would be the impact.


> * Remember more information during the first scan, that seems the least
>   desirable.
>

That's the current implementation.


> * Figure out earlier if we are going to allocate the headers. This is
>   hard and just a conservative heuristic. For example, it is possible to
>   construct a case where a PT_GNU_RELRO is not needed, but we don't know
>   that until we known that a .got is not needed.
>

I tried this one, but it felt too complicated, there was a lot of
duplication of code and I always managed to come up with a counter-example
where it didn't work.


> We already use the strategy of tentatively creating things and deleting
> them if we find out we don't need them, so if we can make that work in
> here that would be my preference.


IIUC this would work if we move the reporting to
InputSection::relocateNonAlloc and InputSectionBase::relocate; we can
define __ehdr_start unconditionally and later change it to undefined symbol
if we find out it's needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170509/a4229c0c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4843 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170509/a4229c0c/attachment.bin>