This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Allow pie links to create PLT entries
- From: Magnus Granberg <zorry at gentoo dot org>
- To: binutils at sourceware dot org
- Date: Fri, 30 Jan 2015 22:04:32 +0100
- Subject: Re: Allow pie links to create PLT entries
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmyEG-m74+vcKFzuFTzVB-1cQvp1K_k3Hji=9ZnFci7CtA at mail dot gmail dot com> <CAAs8HmwvFzb6+6D+9PXCTLv+G+jFt9saMwq6wcfs7LWd2-of7Q at mail dot gmail dot com> <CAMe9rOpo58kfeufRO0w=8t=+=aK7T0QKkRzW5caAvvhXPUqZEQ at mail dot gmail dot com>
fredag 30 januari 2015 12.15.29 skrev H.J. Lu:
> >>>>>
> >>>>> movslq 0x1655(%rip),%rax # 401b80 <i>
> >>>>> mov 0x401b30(,%rax,4),%esi # a[i]
> >>
> >> If you link it with -pie, you will have TEXTREL in executable.
> >> Do you want relocations in text sections in PIE?
> >
> > I have been told TEXTRELs are not preferred though I never understood why.
> >
> > Just to make sure I understand, are you saying that the absolute
> > address in the case of -pie will be a text relocation? I think that
>
> It is not about absolute address. It is about symbol address. Since
> the address of symbol, a, in
>
> movl a(,%rdi,4), %eax
>
> is unknown at link-time, linker has to generate relocation in text
> section to resolve it at run-time.
The sections need to be writeble and you can do change in that section and
that is not good from a security piont of view. You may even get performance
penalties. I see no point to use no -fPIE objects in executable when you can
get gcc to handel it with some patches. Gentoo Hardened have been building
executable with -fPIE and linke with -pie for ages and it even a tread on gcc-
patches ml to get support to Gcc 5.0
/Magnus G.
>
> > is not true because this mov instruction
> >
> > mov 0x401b30(,%rax,4),%esi
> >
> > does not allow a 64-bit absolute value which is needed for -pie. What
> > I was instead suggesting is to make that PC-relative like:
> >
> > mov 0xabcd(%rip,%rax,4),%esi
> >
> > which would not need a text relocation. However, I do not think such
> > an insn is supported yet, thought it would be useful.
>
> That will be useful.