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
