|
Home > Archive > Unix Programming > December 2005 > Pic vs. non Pic library code?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Pic vs. non Pic library code?
|
|
| John Smith 2005-12-24, 5:56 pm |
| I have an application where I rely on a 3rd party vendor. They wrote a
static library (*.a file) which one must use under Mac OS X, Linux x86 and
AMD64.
For the first two the vendor only supplied 1 library. For the AMD64 they
supplied two though. One of them is a "normal" one and the other is named
*_pic.a. According to their documentation they say you must use this for
creating shared objects.
Naturally this leaves some unanswered questions:
Why would only AMD64 platform have this? Shouldn't linux act the same way
under both x86 and AMD64? Also MAC OS X relies on a similar unix model with
pic/non-pic code.
I am also supplying static libraries to customers and eventually I would
have the same situation. Should I compile all my libaries with -fPIC option
to be on the safe side or should I create two versions for both pic and
non-pic code?
Thanks in advance for clearing out my doubts.
-- John
| |
| Henry Townsend 2005-12-25, 2:48 am |
| John Smith wrote:
> Why would only AMD64 platform have this? Shouldn't linux act the same way
> under both x86 and AMD64? Also MAC OS X relies on a similar unix model with
> pic/non-pic code.
Don't know about Linux but IIRC you're dead wrong about Mac OSX - all
OSX code is pic. The compiler accepts the options for compatibility but
they're dummies.
HT
| |
| Paul Pluzhnikov 2005-12-25, 2:48 am |
| "John Smith" <js@x-formation.com> writes:
> Why would only AMD64 platform have this?
On Linux/x86, the linker does not object to linking non-PIC code
into a DSO. On Linux/x86_64, it does.
The vendor suppiled *_pic.a for Linux/x86_64 because otherwise the
library would not be usable at all for creating DSOs on that
platform.
On Linux/x86 the DSO containing non-PIC code will have relocations
applied to its .text section, and thus will be less shareable then
if it contained only PIC code.
> Shouldn't linux act the same way under both x86 and AMD64?
Why should it? These are different processors, with different
capabilities, and they place different requirements on the runtime
linker.
> I am also supplying static libraries to customers and eventually I would
> have the same situation. Should I compile all my libaries with -fPIC option
> to be on the safe side or should I create two versions for both pic and
> non-pic code?
It depends. PIC code is usually slightly bigger and slightly less
efficient. If you are supplying performance-critical components,
where even 1% slowdown matters, then you should supply both PIC
and non-PIC versions.
If not, supplying a single archive with PIC code in it reduces your
maintenance load and simplifies life for your customers.
Happy holidays,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| John Smith 2005-12-25, 5:50 pm |
| > It depends. PIC code is usually slightly bigger and slightly less
> efficient. If you are supplying performance-critical components,
> where even 1% slowdown matters, then you should supply both PIC
> and non-PIC versions.
>
> If not, supplying a single archive with PIC code in it reduces your
> maintenance load and simplifies life for your customers.
>
Thanks for the explanation. So you're saying there is PIC enabled code will
always work with both binaries and shared objects?
I don't care about minor performance hits. As long as it's not anything
critical it doesn't matter. My users could not care less about a few extra
milliseconds wasted in the loader.
Happy holidays to you as well.
-- John
| |
| Paul Pluzhnikov 2005-12-25, 5:50 pm |
| "John Smith" <js@x-formation.com> writes:
> Thanks for the explanation. So you're saying there is PIC enabled code will
> always work with both binaries and shared objects?
Correct.
> My users could not care less about a few extra
> milliseconds wasted in the loader.
It's not just the startup that you pay performance hit in PIC code.
Every call (even call from your library into itself) carries a
small penalty:
non-PIC code:
foo:
call 0x12345678 <bar>
PIC code:
foo:
call 0x23456789 <PLT+48>
PLT+48:
jmp *(GOT+4) # loader sets things up such that on 2nd and
# subsequent calls this jumps directly to 'bar'
So instead of direct call, you execute 'call + jump-indirect'
There is similar overhead for non-static data references.
For most non-CPU critical tasks this is perfectly acceptable;
but sometimes it isn't.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Maxim Yegorushkin 2005-12-25, 8:48 pm |
| Paul Pluzhnikov wrote:
> On Linux/x86, the linker does not object to linking non-PIC code
> into a DSO. On Linux/x86_64, it does.
Sorry, I'm slow. Do you mean that objects on x86 are always relocatable
no matter if -fpic option is used? $(man gcc) makes no notice of that
(seeked through for fpic).
> On Linux/x86 the DSO containing non-PIC code will have relocations
> applied to its .text section, and thus will be less shareable then
> if it contained only PIC code.
Do you mean that non-PIC on x86 code has relocations in its .text
section, while PIC code has it only in a section containing GOT?
| |
| Paul Pluzhnikov 2005-12-26, 3:14 am |
| "Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> writes:
> Sorry, I'm slow. Do you mean that objects on x86 are always relocatable
> no matter if -fpic option is used?
The most commonly used defintion of "relocatable object code"
I am familiar with is this one:
http://docs.hp.com/en/B2355-90655/ch07s01.html
All UNIX compilers I've ever dealt with always produce relocatable
object code. Gcc on Linux/{x86, x86_64} certainly does (whether
-fPIC is specified or not).
However, the "relocated-ness" of foo.o has nothing to do with whether
it can be linked into a DSO or not.
>
> Do you mean that non-PIC on x86 code has relocations in its .text
> section, while PIC code has it only in a section containing GOT?
There could be other (data-like) sections besides .got with
relocations, e.g. .ctors/.dtors, but yes: generally the difference
between PIC and non-PIC DSOs is that PIC DSOs have "pure text",
i.e. text with no relocations remaining.
This is true for all platforms requiring PIC code, not just
Linux/x86.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|