For a shared object, the string is preemptible, placing that in read
only is a bug in IPA. In theory, one could place readonly into text
segment, runtime relocation of text segment requires OS support of
copy on write at startup time. It could also prevent text sharing,
which is the whole point of shared objects
Sun
On Thu, Apr 7, 2011 at 8:39 AM, Jaewook Shin <jaewookshin...@gmail.com> wrote:
> Yes, that's how it works currently, although making read-only data
> 'preemptible' in shared objects may need to be improved.
>
> Jaewook
>
> On Wed, Apr 6, 2011 at 5:15 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>
>> 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
