agreed. One of IPA's optimization is to attempt make PIC == PIE performance-wise
Sun
2010/8/4 Peng Yuan <yingbo....@gmail.com>:
> I agree with your points.
>
> So for the checkin,
> 1) Objects in libopen64rt_shared.a should be compiled with -fPIC.
> 2) Make sure libopen64rt_shared.a can be used for executable. Otherwise, we
> cannot modify open64 driver code for the issue. Because libopen64rt.a is
> used for executable originally, and libopen64rt_shared.a is for shared
> library. The two libraries have different objects inside.
> 3) If 2) is OK, PIE linking with -fPIC objects is OK. PIE and PIC are the
> same.
>
> From a performance point of view, there is difference between PIE and PIC.
> compiler may generate more efficient -fPIE code than -fPIC. For -fPIC,
> compiler assumes any global symbol can be overridden by other module and
> generates GOT accesses for variables and functions. For -fPIE, there is no
> need to generate GOT for a global symbol defined in current module, and can
> improve variable access performance and also do inlining for functions. I
> believe the small library contributes little to performance. Never care the
> tirval difference.
>
> For example,
> int biluochun = 100;
>
> int foo ()
> {
> return biluochun;
> }
>
> -fPIC will generate GOT for variable biluochun. For -fPIE, the variable
> never need GOT. (But if compiler generates GOT, it is also correct, though
> verbose.)
>
>
> 2010/8/4 Sun Chan <sun.c...@gmail.com>
>>
>> for embedded execution, PIE != PIC, otherwise, they are the same, no?
>> For a PIE relocatable, there is no need for dynamic relocation, that
>> is the job of linkers. If the shared.a is not compiled with PIC (or
>> PIE) it is wrong. A function being reentrant happen to be able to be
>> PIE is an accident (i.e. not related in its original purpose), not a
>> necessary condition.
>> Sun
>>
>> 2010/8/3 Peng Yuan <yingbo....@gmail.com>:
>> > The checkin will affect the use of the library. I suspect the corectness
>> > of
>> > using libopen64rt_shared.a for PIE executable, which the checkin works.
>> >
>> > On Wed, Aug 4, 2010 at 12:01 PM, Sun Chan <sun.c...@gmail.com> wrote:
>> >>
>> >> but this is a problem with the library itself, not the checkin.
>> >> Sun
>> >>
>> >> On Tue, Aug 3, 2010 at 8:55 PM, Peng Yuan <yingbo....@gmail.com> wrote:
>> >> > If libopen64rt_shared.a can be used for executable except for shared
>> >> > library, I'll support the checkin. Not perfect, but it can work for
>> >> > the
>> >> > current trunk. Otherwise we must notice the PIE issue.
>> >> >
>> >> > I just explain the PIE linking. I don't konw the function of
>> >> > libopen64rt.a
>> >> > and libopen64rt.a. Why does open64 need them? Why memset.o and
>> >> > cacheinfo.o
>> >> > are removed from libopen64rt_shared.a?
>> >> >
>> >> > All objects participating in -pie link must be compiled with -fPIE.
>> >> > PIE
>> >> > is
>> >> > not PIC. PIE is for executable (-pie link) and PIC is for shared
>> >> > library
>> >> > (-shared link). So we cannot replace PIE objects with PIC objects.
>> >> >
>> >> > It is a mere coincidence that there is no linker error with
>> >> > libopen64rt_shared.a at -fPIE. Only cacheinfo.o has dynamic
>> >> > relocation
>> >> > info
>> >> > (GOT/PLT) at PIE/PIC, but it is removed from libopen64rt_shared.a
>> >> > (see
>> >> > below).
>> >> >
>> >> > The generation of the two libraries:
>> >> > ar cru libopen64rt.a fastcopy_gh.o malloc_opt.o memset.o cacheinfo.o
>> >> > ar cru libopen64rt_shared.a fastcopy_gh.o malloc_opt.o memset.o
>> >> > cacheinfo.o
>> >> > ar dv libopen64rt_shared.a memset.o cacheinfo.o
>> >> >
>> >> > The two libraries use the same objects. Note objects in
>> >> > libopen64rt_shared.a
>> >> > are NOT compiled with -fPIC.
>> >> >
>> >> > Why "non -fPIC" libopen64rt_shared.a also works for -shared?
>> >> > Just a mere coincidence... I look through malloc_opt.c and
>> >> > fastcopy_gh.s
>> >> > which constitute libopen64rt_shared.a. The codes are simple and have
>> >> > no
>> >> > global symbols, so they don't need GOT/PLT and there is no difference
>> >> > between -fPIC and "non -fPIC". Note if we add new functions to the
>> >> > library,
>> >> > we must pay attention to this issue!
>> >> >
>> >> >
>> >> > On Wed, Aug 4, 2010 at 6:48 AM, Steve Ellcey <s...@cup.hp.com> wrote:
>> >> >>
>> >> >> This patch is my proposed fix for bug 577, The problem is that when
>> >> >> linking a program using the -pie (-fPIE, -fpie) option to create a
>> >> >> position independent executable we link in libopen64rt.a which
>> >> >> contains
>> >> >> non-PIC code and this causes us to get a link-time error.
>> >> >>
>> >> >> My fix is to link in libopen64rt_shared.a instead of libopen64rt.a
>> >> >> when
>> >> >> linking PIE code since the code in libopen64rt_shared.a is built
>> >> >> with
>> >> >> the -fPIC option. We already link in libopen64rt_shared.a instead
>> >> >> of
>> >> >> libopen64rt.a when building shared libraries.
>> >> >>
>> >> >> I tested the patch on a small test case that calls bzero (one of the
>> >> >> functions defined in libopen64rt) and verified that it fixes the bug
>> >> >> on
>> >> >> x86 and since the libopen64rt libraries are only used for x86
>> >> >> targets
>> >> >> this won't affect any other targets.
>> >> >>
>> >> >> Can a gatekeeper approve this patch?
>> >> >>
>> >> >> Steve Ellcey
>> >> >> s...@cup.hp.com
>> >> >>
>> >> >>
>> >> >> Defect report:
>> >> >>
>> >> >> http://bugs.open64.net/show_bug.cgi?id=577
>> >> >>
>> >> >>
>> >> >> Patch:
>> >> >>
>> >> >> Index: osprey/driver/phases.c
>> >> >> ===================================================================
>> >> >> --- osprey/driver/phases.c (revision 3298)
>> >> >> +++ osprey/driver/phases.c (working copy)
>> >> >> @@ -2124,7 +2124,8 @@ add_final_ld_args (string_list_t *args,
>> >> >> // Bug 3995.
>> >> >> if (!option_was_seen(O_fno_fast_stdlib) &&
>> >> >> !option_was_seen(O_nolibopen64rt)) { // bug 9611
>> >> >> - if (option_was_seen(O_shared)) {
>> >> >> + if (option_was_seen(O_shared) || option_was_seen(O_pie)
>> >> >> ||
>> >> >> + option_was_seen(O_fpie) || option_was_seen(O_fPIE))
>> >> >> {
>> >> >> add_library(args, "open64rt_shared");
>> >> >> } else {
>> >> >> add_library(args, "open64rt");
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> The Palm PDK Hot Apps Program offers developers who use the
>> >> >> Plug-In Development Kit to bring their C/C++ apps to Palm for a
>> >> >> share
>> >> >> of $1 Million in cash or HP Products. Visit us here for more
>> >> >> details:
>> >> >> http://p.sf.net/sfu/dev2dev-palm
>> >> >> _______________________________________________
>> >> >> Open64-devel mailing list
>> >> >> Open64-devel@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Regards,
>> >> > Peng Yuan (袁鹏)
>> >> > Performance that will make your eyes water!
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > The Palm PDK Hot Apps Program offers developers who use the
>> >> > Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> >> > of $1 Million in cash or HP Products. Visit us here for more details:
>> >> > http://p.sf.net/sfu/dev2dev-palm
>> >> > _______________________________________________
>> >> > Open64-devel mailing list
>> >> > Open64-devel@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Peng Yuan (袁鹏)
>> > Performance that will make your eyes water!
>> >
>
>
>
> --
> Regards,
> Peng Yuan (袁鹏)
> Performance that will make your eyes water!
>
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
