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