for question #1, yes
#2, as long as the symbol attribute and relocation is set correctly,
why should that be a problem? That IPA causes multiple .o to be used
is immaterial, the underlying situation is the same as if the same .o
is being used, isn't it.
For your previous mail, I thought I explained multiple times, CPIC and
PIC is not the same. CPIC assumes the binary will not be moved at
runtime, once set by the runtime linker. PIC can be moved at runtime.
Hence, CPIC is more restrictive than PIC.
Sun
On Mon, Feb 28, 2011 at 2:23 PM, Yiran Wang <yiran.w...@gmail.com> wrote:
> Hi Sun,
> I have sent out the message too quick.
> There are actually two issues.
> 1. The printf is called without going through PLT. It should be definitely
> wrong.
> 2. The reference to const string does not go through GOT.
> a. It should be OK without IPA, as the .rodata and .text section is in
> a same object file. (i am not sure, pls kindly confirm or ..)
> b. it is not OK, as for -Ofast, the rodata section is in symtab.o,
> while the .text section is in another object file like 1.o. (still not very
> sure, if there is some way to avoid this.)
>
> Best Regards,
> yiran
>
> On Mon, Feb 28, 2011 at 2:17 PM, Yiran Wang <yiran.w...@gmail.com> wrote:
>>
>> Hi Sun,
>> I investigate the bug a little bit, and the findings are:
>> 0. Usually, -pic and -pie is linker option, while -fpic and -fpie is
>> option for BE (for opencc). And -pie and -pic have the same effect, and
>> -fpie and -fpic have the same effect, for open64 (or it would check if an
>> executable is being compiled? that is not sth interested in here.).
>> 1. Ofast IPA would call BE with -TENV:PIC and -pic1 (which is effectively
>> -TENV:CPIC), if it is called with -TENV:PIC (or sth like -pie). While
>> without IPA, only when -fpie is specified, the BE would receive -TENV:PIC.
>> What is noticeable are:
>> a. -Ofast IPA would specify -pic1 for BE, if it receive -pic by
>> itself.
>> b. IPA would specify -fpic.
>> 2. While, the bug is about -TENV:PIC and -TENV:CPIC. If both the two
>> options are specified (i assume they are compatible to each other, is that
>> right? ), the compiler would simply failed, regardless -ipa be specified or
>> not.
>> i.e.
>> opencc -pie -pic1 hello.c
>> hello.c
>> #include<stdio.h>
>> int main()
>> {
>> char * p;
>> p = malloc(10);
>> if (p != 0) return 0;
>> return 1;
>> }
>> The linker would complain that the call to malloc should go through PLT,
>> as the compiler is emitting the following.
>> .globl malloc
>> call malloc # [0] malloc
>>
>> This issue should be sthing wrong about CG.
>> Best Regards,
>> yiran
>>
>> On Fri, Feb 18, 2011 at 11:16 AM, Sun Chan <sun.c...@gmail.com> wrote:
>>>
>>> I don't know who did this code in config_targ.cxx. Whoever did that
>>> has no clue what he's doing. I know exactly how to deal with
>>> call_shared. I believe even gcc has a lot of people who know how to
>>> take advantage of cpic now.
>>> It could be the case that with call_shared turned off, bugs have been
>>> introduced. I believe we should fix the introduced bugs instead of
>>> turning off a good optimization.
>>> Sun
>>>
>>> On Fri, Feb 18, 2011 at 9:54 AM, Zhao, Min <min.z...@hp.com> wrote:
>>> >
>>> >
>>> > Maybe a better fix is to remove config_targ.cxx
>>> > 822 if (Gen_PIC_Call_Shared)
>>> > 823 Gen_PIC_Call_Shared = FALSE;
>>> >
>>> > But the comment (// TMP: ignore cpic until we figure out what to do
>>> > with it) makes us not comfortable to keep Gen_PIC_Call_Shared to be TRUE.
>>> >
>>> > Thanks,
>>> >
>>> > Min
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Sun Chan [mailto:sun.c...@gmail.com]
>>> > Sent: Thursday, February 17, 2011 5:40 PM
>>> > To: Zhao, Min
>>> > Cc: Shin, Jaewook
>>> > Subject: Re: [Open64-devel] Code Review Request (bug #721)
>>> >
>>> > Note that CPIC is a subset of PIC. Apparently there are 2 variables
>>> > governing them. So, turn off PIC if CPIC is set is fine.
>>> > Sun
>>> >
>>> > On Fri, Feb 18, 2011 at 9:38 AM, Sun Chan <sun.c...@gmail.com> wrote:
>>> >> this is the original proposed fix:
>>> >> At first, the effect of -TNEV:PIC option is nullified by -TENV:CPIC in
>>> >> common/com/config.cxx:1457 (if (Gen_PIC_Call_Shared && Gen_PIC_Shared)
>>> >> Gen_PIC_Shared = FALSE). Then, the effect of -TENV:CPIC is reset by
>>> >> common//com/x8664/config_targ.cxx:822:
>>> >>
>>> >> // TMP: ignore cpic until we figure out what to do with it
>>> >> if (Gen_PIC_Call_Shared)
>>> >> Gen_PIC_Call_Shared = FALSE;
>>> >>
>>> >> which I think is incorrect.
>>> >>
>>> >> Can we start with what is the suggested fix now?
>>> >>
>>> >> Sun
>>> >>
>>> >> On Fri, Feb 18, 2011 at 9:28 AM, Zhao, Min <min.z...@hp.com> wrote:
>>> >>>
>>> >>> Exactly. That's why we say the option is wrong.
>>> >>>
>>> >>> In config.cxx
>>> >>> #1457 if (Gen_PIC_Call_Shared && Gen_PIC_Shared) Gen_PIC_Shared =
>>> >>> FALSE;
>>> >>>
>>> >>> In config_targ.cxx
>>> >>> #822 if (Gen_PIC_Call_Shared)
>>> >>> #823 Gen_PIC_Call_Shared = FALSE;
>>> >>>
>>> >>> In -ipa, we are NOT doing any -pic handling.
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Min
>>> >>>
>>> >>> -----Original Message-----
>>> >>> From: Sun Chan [mailto:sun.c...@gmail.com]
>>> >>> Sent: Thursday, February 17, 2011 5:08 PM
>>> >>> To: Zhao, Min
>>> >>> Cc: Shin, Jaewook
>>> >>> Subject: Re: [Open64-devel] Code Review Request (bug #721)
>>> >>>
>>> >>> this make no sense. This implies the code becomes a static object,
>>> >>> which is not correct. Neither of this flag should be tinkered with.
>>> >>> One can change PIC to PIC_Call_Shared by ipa
>>> >>> Sun
>>> >>>
>>> >>> On Fri, Feb 18, 2011 at 8:51 AM, Zhao, Min <min.z...@hp.com> wrote:
>>> >>>>
>>> >>>> NO. From the code, it seems that both Gen_PIC_Call_Shared and
>>> >>>> Gen_PIC_Shared are explicitly set to FALSE with -ipa. That's why I
>>> >>>> said we
>>> >>>> are not doing any -IPC handling in -ipa.
>>> >>>>
>>> >>>> Thanks,
>>> >>>>
>>> >>>> Min
>>> >>>>
>>> >>>> -----Original Message-----
>>> >>>> From: Sun Chan [mailto:sun.c...@gmail.com]
>>> >>>> Sent: Thursday, February 17, 2011 4:23 PM
>>> >>>> To: Zhao, Min
>>> >>>> Cc: Shin, Jaewook
>>> >>>> Subject: Re: [Open64-devel] Code Review Request (bug #721)
>>> >>>>
>>> >>>> depends on the default. I think compiler defaults to -PIC, with IPA,
>>> >>>> it can know that it is really CPIC, not .so, would you agree? So,
>>> >>>> IPA
>>> >>>> could make up these flags to down stream and linker (at least this
>>> >>>> is
>>> >>>> how it works back at SGI)
>>> >>>> Sun
>>> >>>>
>>> >>>> On Fri, Feb 18, 2011 at 8:17 AM, Zhao, Min <min.z...@hp.com> wrote:
>>> >>>>> Sun,
>>> >>>>>
>>> >>>>> Just a quick point: with -ipa, we do *NOT* have any -PIC handling
>>> >>>>> at all (since Gen_PIC_Call_Shared and Gen_PIC_Shared are false).
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>>
>>> >>>>> Min
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>
>
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
