[PATCH] D20024: [ELF] - Protect first entries of got.plt with RelRo.

[Rui Ueyama via llvm-commits]

On Fri, May 6, 2016 at 2:20 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Fri, May 06, 2016 at 03:36:10PM -0400, Rafael Espíndola via
> llvm-commits wrote:
> > On 6 May 2016 at 14:27, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
> > > On 6 May 2016 at 14:23, Rui Ueyama <ruiu at google.com> wrote:
> > >> Can we simply drop it? I'm wondering if other libc's or dynamic
> linkers use
> > >> it.
> > >
> > > From what is written in the abi it looks like it would only be used by
> > > self relocating programs (i.e.: ld.so).
> > >
> > > But those could do just what musl does.
> > >
> > > Let me give it a try.
> >
> > http://reviews.llvm.org/D20028
>
> Let's not produce nightmares for poor porters that have to hunt for the
> obscure bugs it can create please.


I think if it works without it, the code shouldn't have been added in the
first place. Or, in other words, if the code was not present, do we still
want to add this piece of code just because ld.bfd and ld.gold do this? I
don't think so.

Being said that, it's odd that both bfd and gold add that field. There
might be a reason that we don't know yet?

> As for the rest of this patch: I think I agree with Rui. The added
> > value is really small. If going for safety you should really disable
> > lazy loading or even just compile with -fno-plt.
>
> I agree on this part though, it seems pointless complexity for an edge
> case, that doesn't give much.
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160506/3d92c4f4/attachment.html>