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!
------------------------------------------------------------------------------
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

Reply via email to