[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more non-PIC static libs in shared libs

On Sun, Jan 12, 2003 at 09:53:29PM +0100, Daniel Kobras wrote:
> On Sun, Jan 12, 2003 at 02:57:11PM -0500, Daniel Jacobowitz wrote:
> > Woah, the version maps are for a completely different issue than
> Ah, sorry.  Seems I read a bit more context into your post than was
> intended.  TEXTREL and hand-crafted assembly was what this thread
> started out with.
> >   Is this library being compiled -fPIC or not?
> The C part of course is compiled with -fPIC, but...
> >   Does this library contain hand assembly or not?
> ... there are a couple of optimized x86-assembly files.
> >   What are the relocations against?  readelf -r can show you the
> > contents of .rel.text.
> .rel.text is empty--the lib is lintian-clean.  But still the TEXTREL
> flag is set (on i386), and therefore prelinking might fail.  Policy so
> far only talks about compiling shared libs with -fPIC, it doesn't
> mention assembly.  In order to support prelinking, some folks prefer to
> require TEXTREL being unset.  The technical implications of this change
> are still unclear, however (to me, at least): Is there a way to massage
> an asm-optimized shared lib into non-TEXTREL form that doesn't degrade
> performance? Even if the asm code is not position-independent and
> already occupies all available registers? (In other words, if it's x86
> assembly. ;-)

The question is what relocations the assembly uses.  Looking at the
linker... if there are any relocations in .rel.dyn which apply to
read-only sections, i.e. .text usually, then the library is
inadequately PIC.  Are you branching to externally visible functions
from assembly without using the GOT?  Take a look through .rel.dyn; see
if you can find the problem relocations by their offsets, and post the
affected assembly code.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Reply to: