From: Andrew Pinski <pinskia@gmail.com>
To: Rong Xu <xur@google.com>
Cc: Richard Henderson <rth@redhat.com>,
Richard Biener <richard.guenther@gmail.com>,
Xinliang David Li <davidxl@google.com>,
Jan Hubicka <hubicka@ucw.cz>,
GCC Patches <gcc-patches@gcc.gnu.org>,
reply@codereview.appspotmail.com
Subject: Re: atomic update of profile counters (issue7000044)
Date: Wed, 20 Nov 2013 20:08:00 -0000 [thread overview]
Message-ID: <CA+=Sn1nP441p+t-ik2pdPV2fb5je_6kTz1rOje5_ujHh6O8S0Q@mail.gmail.com> (raw)
In-Reply-To: <CAF1bQ=R_qgrDHRyOKNr0eaN9BFOWku4bR6tFJeSRz6hoSCrjqQ@mail.gmail.com>
On Wed, Nov 20, 2013 at 10:44 AM, Rong Xu <xur@google.com> wrote:
> On Tue, Nov 19, 2013 at 5:11 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Tue, Nov 19, 2013 at 5:02 PM, Rong Xu <xur@google.com> wrote:
>>> Hi all,
>>>
>>> I merged this old patch with current trunk. I also make the following changes
>>> (1) not using weak references. Now every *profile_atomic() has it's
>>> own .o so that none of them will be in the final binary if
>>> -fprofile-generate-atomic is not specified.
>>> (2) more value profilers have the atomic version.
>>> (3) not link to libatomic. I used to link the libatomic in the
>>> presence of -fprofile-generate-atomic, per Andrew's suggestion. It
>>> used to work. But now if I can add -latomic in the SPEC, it cannot
>>> find the libatomic.so.1 (unless I specify the PATH). I did not find an
>>> easy way to statically link libatomic.a. Andrew: Do you have any
>>> suggestion? Or should we let the user link to libatomic.a if the
>>> builtins are not expanded?
>>
>> It should work for an installed GCC. For testing you might need
>> something that is included inside testsuite/lib/atomic-dg.exp which
>> sets the library path to include libatomic build directory.
>
> When I change the SPEC to include libatomic,
> the compiler can find libatomic. I.e. using
>>> gcc -O2 -fprofile-generate -fprofile-generate-atomic=3 hello_world.c
> generates a.out without any problem.
>
> But since there are both shared and static libatomic in lib64, it
> chooses to use the dynamic one.
>>> ldd a.out
> linux-vdso.so.1 => (0x00007fff56bff000)
> libatomic.so.1 => not found
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002b0720261000)
> /lib64/ld-linux-x86-64.so.2 (0x00002b072003c000)
>
>>> ./a.out
> ./a.out: error while loading shared libraries: libatomic.so.1: cannot
> open shared object file: No such file or directory
>
> while
>>> LD_LIBRARY_PATH=<gcc_install_patch>/lib64 ./a.out
> works fine.
I don't see this as an issue really as you have the same issue with
all the target libraries (not limited to libatomic or libgomp or
libgfortran).
Thanks,
Andrew Pinski
>
> I think that's the same reason we set the library path in
> testsuite/lib/atomic-dg.exp, because <gcc_install_patch>/lib64
> is not in the dynamic library search list.
>
> I could do this in the SPEC
> -Wl,-Bstatic -latomic -Wl,-Bdynamic
> which would link libatomic statically.
> I works for me. But it looks a little weird in gcc driver.
>
> Index: gcc.c
> ===================================================================
> --- gcc.c (revision 205053)
> +++ gcc.c (working copy)
> @@ -771,7 +771,8 @@
> %{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\
> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
> %(mflib) " STACK_SPLIT_SPEC "\
> - %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " SANITIZER_SPEC " \
> + %{fprofile-arcs|fprofile-generate*|coverage:-lgcov\
> + %{fprofile-generate-atomic=*:-Wl,-Bstatic -latomic
> -Wl,-Bdynamic}} " SANITIZER_SPEC " \
> %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
> %{!nostdlib:%{!nostartfiles:%E}} %{T*} }}}}}}"
> #endif
>
>
>
>> I think now we require libatomic in more cases (C11 atomic support for
>> an example).
>>
>> Thanks,
>> Andrew Pinski
>>
>>>
>>> Is this OK for trunk?
>>>
>>> Thanks,
>>>
>>> -Rong
>>>
>>> On Mon, Jan 7, 2013 at 12:55 PM, Rong Xu <xur@google.com> wrote:
>>>> Function __gcov_indirect_call_profiler_atomic (which contains call to
>>>> the atomic function) is always emitted in libgcov.
>>>> Since we only link libatomic when -fprofile-gen-atomic is specified,
>>>> we have to make the atomic function weak -- otherwise, there is a
>>>> unsat for regular FDO gen build (of course, when the builtin is not
>>>> expanded).
>>>>
>>>> An alternative it to always link libatomic together with libgcov. Then
>>>> we don't need the weak stuff. I'm not sure when one is better.
>>>>
>>>> -Rong
>>>>
>>>> On Mon, Jan 7, 2013 at 12:36 PM, Richard Henderson <rth@redhat.com> wrote:
>>>>> On 01/03/2013 04:42 PM, Rong Xu wrote:
>>>>>> It links libatomic when -fprofile-gen-atomic is specified for FDO
>>>>>> instrumentation build. Here I assume libatomic is always installed.
>>>>>> Andrew: do you think if this is reasonable?
>>>>>>
>>>>>> It also disables the functionality if target does not support weak
>>>>>> (ie. TARGET_SUPPORTS_WEAK == 0).
>>>>>
>>>>> Since you're linking libatomic, you don't need weak references.
>>>>>
>>>>> I think its ok to assume libatomic is installed, given that the
>>>>> user has had to explicitly use the command-line option.
>>>>>
>>>>>
>>>>> r~
next prev parent reply other threads:[~2013-11-20 18:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 6:45 Rong Xu
2012-12-21 9:25 ` Jan Hubicka
2012-12-21 18:38 ` Rong Xu
2012-12-28 19:33 ` Rong Xu
2012-12-28 19:35 ` Xinliang David Li
2013-01-03 1:16 ` Rong Xu
2013-01-03 1:25 ` Andrew Pinski
2013-01-03 1:29 ` Rong Xu
2013-01-03 1:31 ` Andrew Pinski
2013-01-03 9:05 ` Richard Biener
2013-01-04 0:42 ` Rong Xu
2013-01-07 20:36 ` Richard Henderson
2013-01-07 20:56 ` Rong Xu
2013-11-20 7:03 ` Rong Xu
2013-11-20 7:20 ` Andrew Pinski
2013-11-20 19:59 ` Rong Xu
2013-11-20 20:08 ` Andrew Pinski [this message]
2013-11-20 20:31 ` Andrew Pinski
2013-11-20 23:18 ` Joseph S. Myers
2013-11-21 0:07 ` Rong Xu
2013-11-21 0:14 ` Andrew Pinski
2013-11-21 1:24 ` Rong Xu
2014-05-26 6:01 ` Jan Hubicka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+=Sn1nP441p+t-ik2pdPV2fb5je_6kTz1rOje5_ujHh6O8S0Q@mail.gmail.com' \
--to=pinskia@gmail.com \
--cc=davidxl@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=reply@codereview.appspotmail.com \
--cc=richard.guenther@gmail.com \
--cc=rth@redhat.com \
--cc=xur@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).