Re: Pic vs. non Pic library code?
- From: Paul Pluzhnikov <ppluzhnikov-nsp@xxxxxxxxxxx>
- Date: Sun, 25 Dec 2005 15:34:23 -0800
"John Smith" <js@xxxxxxxxxxxxxxx> 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.
.
- References:
- Pic vs. non Pic library code?
- From: John Smith
- Re: Pic vs. non Pic library code?
- From: Paul Pluzhnikov
- Re: Pic vs. non Pic library code?
- From: John Smith
- Pic vs. non Pic library code?
- Prev by Date: Re: Help with "Concurrent Network Server" Design
- Next by Date: Re: about segment fault
- Previous by thread: Re: Pic vs. non Pic library code?
- Next by thread: Re: Pic vs. non Pic library code?
- Index(es):
Relevant Pages
|
