if -fPIC is meant to produce shared objects, then the error is in the
flags passed to IPA. And I take back my previous statement. The second
line clearly says -o bar.so. Hence, IPA should never change the output
to be call_shared. Is it?
Sun
On Thu, Apr 7, 2011 at 8:07 AM, Jaewook Shin <jaewookshin...@gmail.com> wrote:
> Sun,
>
> '-fPIC' is for Gen_PIC_Shared and used to make shared objects while '-fpie'
> is for Gen_PIC_Call_Shared and used to make position independent
> executables.
>
> The example shown below is intended to model a regular process of building a
> shared object from multiple source files using "-Ofast" option. So, IPA does
> not change any option but it puts read-only data symbols in a separate file
> (symtab.s). Thus, such read-only symbols should be declared as .globl, and
> should go into GOT to be used with "-shared" linker option.
>
> The example is a simplified version of the compilation process for
> 'tcl8.5.7'.
>
> Jaewook
>
>
> On Wed, Apr 6, 2011 at 3:17 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>
>> this is a operator error. Your option in the first compile invokation
>> is inconsistent with the second. The first says (more like implied, as
>> can be derived by IPA) you are doing call_shared. The second says you
>> are creating a shared object, hence, IPA should never have changed the
>> internal option passed down to call_shared.
>> Sun
>>
>> On Thu, Apr 7, 2011 at 1:34 AM, Jaewook Shin <jaewookshin...@gmail.com>
>> wrote:
>> > Hi Sun,
>> >
>> > Recently, it came to my attention that there is a bug in my patch for
>> > bug
>> > #721. It happens with the following code example and the compilation
>> > commands.
>> >
>> > $ cat bar.c
>> > #include <stdio.h>
>> >
>> > void bar()
>> > {
>> > printf("Hello bar\n");
>> > return;
>> > }
>> > $ opencc -c -m64 -ipa -fPIC bar.c
>> > $ opencc -shared -o bar.so bar.o -ipa
>> > /usr/bin/ld: /tmp/bar.so.ipaSJSpVg/1.o: relocation R_X86_64_PC32 against
>> > `.rodata_bar_so' can not be used when making a shared object; recompile
>> > with
>> > -fPIC
>> > /usr/bin/ld: final link failed: Bad value
>> > Can you review my patch below?
>> >
>> > $ svn diff
>> > Index: osprey/be/cg/x8664/exp_loadstore.cxx
>> > ===================================================================
>> > --- osprey/be/cg/x8664/exp_loadstore.cxx (revision 3537)
>> > +++ osprey/be/cg/x8664/exp_loadstore.cxx (working copy)
>> > @@ -1177,7 +1177,8 @@
>> > FmtAssert(!ST_is_thread_local(base_sym),
>> > ("Exp_Ldst: thread-local storage should not be
>> > handled
>> > here"));
>> > if (Gen_PIC_Shared || Gen_PIC_Call_Shared) {
>> > - if ( ST_is_preemptible(base_sym) ) {
>> > + if ( (Gen_PIC_Shared && !ST_is_export_local(base_sym)) ||
>> > + (Gen_PIC_Call_Shared && ST_is_preemptible(base_sym)) ) {
>> > TN *tmp = base_ofst == 0 ? tn : Build_TN_Like(tn);
>> > Build_OP( TOP_ld64, tmp, Rip_TN(),
>> > Gen_Symbol_TN( base_sym, 0,
>> > TN_RELOC_X8664_GOTPCREL ),
>> > The bug in my earlier patch is caused by having only 'preemptible'
>> > symbols
>> > to go into GOT, 'even for dynamically shared objects(.so files) that are
>> > compiled with PIC'.
>> >
>> > In the above example, the "Hello ..." string is a read-only data and
>> > needs
>> > not go into GOT for 'position-independent executables' if "-pie" is
>> > given to
>> > the linker. For dynamically shared object files when they are compiled
>> > with
>> > '-ipa', however, these read-only symbols are also placed in a separate
>> > assembly file (symtab.s) and should be declared with ".globl" so that
>> > they
>> > are visible outside the file. The linker seems to put all global symbols
>> > into the GOT table if '-shared' is given to make a shared object. Thus
>> > all
>> > accesses to the "Hello ..." string should go through GOT as well.
>> >
>> > The above fix is partially undoing a change in my earlier patch only for
>> > the
>> > PIC cases. As a result, nothing changes for the PIC cases from before my
>> > earlier patch but the CPIC cases still get the benefit of not going
>> > through
>> > GOT for read-only data. Again, this fix is verified with both SPEC INT
>> > and
>> > FP showing success for all but 416.games. I've reopened bug 721 for this
>> > new
>> > issue.
>> >
>> > Jaewook
>> >
>
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
