This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Properly handle protected function for ia32 and x86_64


On Tue, Feb 01, 2005 at 03:21:10PM +1030, Alan Modra wrote:
> On Sun, Jan 30, 2005 at 11:22:29AM +0100, Andreas Jaeger wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > > 	* elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
> > > 	against protected function when building shared library.
> > >
> > > 	PR 584
> > > 	* elf64-x86-64.c (is_32bit_relative_branch): New.
> > > 	(elf64_x86_64_relocate_section): Alllow R_X86_64_PC32 on a
> > > 	protected function symbol when building shared library for
> > > 	32bit relative branch instruction.
> > 
> > I approve the x86-64 part of the patch but would suggest that you wait
> > another day for comments before checking in,
> 
> I'm not happy with the i386 one, because conceptually there isn't any
> reason why the GOT of a shared library can't contain an entry for a
> protected symbol.  I believe such a shared lib will work properly, so it
> isn't appropriate to issue an error.  The problem occurs when an
> executable tries to reference such a symbol, and copy relocs are
> involved.

Please check it again. It is R_386_GOTOFF against protected FUNCTION
symbol. It has nothing to do with copy relocation. It is the function
pointer problem with protected function.

> 
> I think you should *warn* that a shared library built with protected
> data symbols may result in non-shared text pages for apps linked against
> the lib, and force elimination of the copy reloc when building apps
> against such libs.  Another issue is whether seeing a GOTOFF reloc
> against a protected symbol is a sufficient indicator of a problematic
> shared lib.  ie. Perhaps there are other relocs used when different code
> sequences in a shared lib access the lib's protected data.
> 

What you described is my proposal:

http://sources.redhat.com/ml/binutils/2005-01/msg00349.html

I will implement it when I find time.


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]