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
