Hi Sun,
I've been investigating on this bug for the last several days now and I like to
get your advice on this to move forward. One thing I've found is that the same
problem occurs whenever "-ipa" is used at all optimization levels.
Also, the printf string's properties are shown below for the breaking case.
Breakpoint 2, EMT_Put_Elf_Symbol (sym=0x80cfec8)
At ../../osprey/be/cg/cgemit.cxx:1168
1: ST_name(ST const*) (sym) = 0x811286d ".rodata_a_out"
(gdb) p *sym
$1 = {u1 = {name_idx = 2165, tcon = 2165}, flags = 0, flags_ext = 0,
sym_class = CLASS_BLOCK, storage_class = SCLASS_EXTERN,
export_class = EXPORT_INTERNAL, tls_model = TLS_NONE, u2 = {type = 3,
pu = 3, blk = 3}, pad = 0, offset = 0, base_idx = 19457, st_idx = 19457}
The string is not preemptible; ST_is_preemptible will return false. Do you find
anything wrong in this string? The above run is compiled with "-O3 and -ipa".
Also, another thing is that it compiles OK as long as "-pie" is not provided to
the linker.
$ gcc 1.s symtab.s
$ gcc 1.s symtab.s -pie
.../bin/ld: /tmp/ccjfNbWn.o: relocation R_X86_64_32S against `.rodata_a_out'
can not be used when making a shared object; recompile with -fPIC
/tmp/ccjfNbWn.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
This seems to say that opencc might perform some optimizations that do not
place printf strings in GOT but if so, the linker will always complain with
this same message. Thus, to avoid this error, either the string should go into
GOT or "-pie" option should not be provided to the linker.
For the options, as you mentioned CPIC is a subset of PIC. In that situation,
my immediate feeling is that it should be OK to leave both PIC and CPIC on.
When both are given, disabling PIC is a loss of information but leaving both on
should not affect the later optimizations. In this sense, Feng's second fix
seems to be in the right direction.
- /* if we get both TENV:CPIC and TENV:PIC, use only TENV:CPIC */
- if (Gen_PIC_Call_Shared && Gen_PIC_Shared) Gen_PIC_Shared = FALSE;
Could you let me know what optimizations are turned off by allowing both PIC
and CPIC? In fact, I don't understand the rationale behind turning PIC off when
both are given.
I've checked the usage of Gen_PIC_Call_Shared in the source code and found only
four locations where it is used NOT in conjunction with Gen_PIC_Shared.
9266: Gen_PIC_Call_Shared,
./be/cg/cgemit.cxx
840: else if (Gen_PIC_Call_Shared && CGEXP_gp_prolog_call_shared
./be/cg/calls.cxx
1730: if (Gen_PIC_Call_Shared &&
7806: if (Gen_PIC_Call_Shared &&
./be/cg/whirl2ops.cxx
Among these, cgemit.cxx uses it to set a field of ELF file, whirl2ops.cxx uses
it in Expand_New_Call_To_Ops and Handle_Call_Site to process PICCALLs, and the
one in calls.cxx is valid only when the pointer type is 4 bytes. Thus, CPIC is
useful in some cases but it does not seem to enable generating PIE alone.
The above Feng's fix may have a big impact on other part of the code but does
anyone know any reason why the fix may entail negative results?
Sun, please elaborate if you have different ideas.
Jaewook
From: Feng Zhou [mailto:fengzho...@gmail.com]
Sent: Friday, February 11, 2011 2:50 PM
To: Shin, Jaewook
Subject: Fwd: [Open64-devel] Code Review Request (bug #721)
Hello, Jaewook
This is the email thread I had with Sun Chan on the bug. Hope this helps.
Thanks.
Sincerely
Feng Zhou
Forwarded conversation
Subject: Code Review Request (bug #721)
------------------------
From: Feng Zhou <fengzho...@gmail.com<mailto:fengzho...@gmail.com>>
Date: Wed, Jan 26, 2011 at 2:45 PM
To:
open64-devel@lists.sourceforge.net<mailto:open64-devel@lists.sourceforge.net>
Hello,
Attached is my fix to bug #721 (https://bugs.open64.net/show_bug.cgi?id=721),
can gatekeeper review this fix for me please? Thank you very much.
============
Bug Analysis
============
This bug happens with -Ofast -pie -fpie option on. However, it does not happen
at other optimization levels, say -O3. Further investigation shows that even a
very simple printf("hello world\n"); program shows the same symptoms. This is
caused by compiler generating wrong code for loading string constant ("hello
world"). When -pie option is on, the compiler should not generate
the loading code using indirect load from GOT table (e.g. movq $(.rodata),%rdi
vs. leaq .rodata(%rip),%rdi).
However, this difference is caused by the ipa. The problem is that with IPA and
-pie specified, ipa_link passes both -TENV:CPIC (-pic1) and -TENV:PIC to
subsequent compilation phases. However, these two options can not work
together, at least on X86-64. 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;
Fix to this problem is to change IPA so that it does not pass -pic1 option to
subsequent phases when the target is X8664. It seems to me that -TENV:CPIC is
unsupported on X8664 in the compiler.
-- Feng Zhou
----------
From: Sun Chan <sun.c...@gmail.com<mailto:sun.c...@gmail.com>>
Date: Wed, Jan 26, 2011 at 3:07 PM
To: Feng Zhou <fengzho...@gmail.com<mailto:fengzho...@gmail.com>>
Cc:
open64-devel@lists.sourceforge.net<mailto:open64-devel@lists.sourceforge.net>
I am not familiar with x86, my understanding of the generic SVR4 ABI
is that cpic is a subset of PIC. IOWs, even if cpic code goes through
GOT, it is just a performance issue. CPIC assumes that whatever is
being accessed do not have to go through GOT. The side effect of which
is that for symbols that are not pre-emptible, one does not have to
have got entry. This is the only case that could cause problem. But a
string in printf is not necessarily non-preemptible (I don't believe
language says so, but i could be outdated now).
Sun
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net<mailto:Open64-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
----------
From: Feng Zhou <fengzho...@gmail.com<mailto:fengzho...@gmail.com>>
Date: Mon, Feb 7, 2011 at 11:29 AM
To: Sun Chan <sun.c...@gmail.com<mailto:sun.c...@gmail.com>>
Cc:
open64-devel@lists.sourceforge.net<mailto:open64-devel@lists.sourceforge.net>
Sun,
Based on your email, I changed my fix to the following (also as attachment):
Index: osprey/common/com/config.cxx
===================================================================
--- osprey/common/com/config.cxx (revision 3471)
+++ osprey/common/com/config.cxx (working copy)
@@ -1453,9 +1453,6 @@
if ( Use_Large_GOT ) Guaranteed_Small_GOT = FALSE;
- /* if we get both TENV:CPIC and TENV:PIC, use only TENV:CPIC */
- if (Gen_PIC_Call_Shared && Gen_PIC_Shared) Gen_PIC_Shared = FALSE;
-
/* Select optimization options: */
/* Are we skipping any PUs for optimization? */
The above code, I think, affects all targets. Was there any reason of it?
--Feng Zhou
----------
From: Sun Chan <sun.c...@gmail.com<mailto:sun.c...@gmail.com>>
Date: Mon, Feb 7, 2011 at 3:24 PM
To: Feng Zhou <fengzho...@gmail.com<mailto:fengzho...@gmail.com>>
Cc:
open64-devel@lists.sourceforge.net<mailto:open64-devel@lists.sourceforge.net>
I think you are in the wrong track. I'd like to know the symbol
attribute of the string that became part of the erronous code. The bug
is not in IPA, nor the CPIC/PIC flag themselves. Those are concepts
that, if turned off, of course a lot of things will start working,
because you basically turned off every optimization that comes with
it. For printf strings, x86 opt people might have put that into "const
table" and that one arguably can make that string "hidden" or even
stronger, thus one doesn't have to go through GOT for it. But, the
caller must reconcil that fact also, the compiler might not have
generated the GOT entry, yet the call site still thinks that it needs
to. Look at CG.
Sun
------------------------------------------------------------------------------
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
