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
> > TEXTREL.
>
> 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: