<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 10, 2014 at 5:49 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> writes:<br>
> On Mon, Nov 10, 2014 at 3:12 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br>
><br>
>     >Interesting. This issue doesn't arise with sanitizers, because we put<br>
>     sanitizer runtimes *before* the user inputs, and force it into the<br>
>     executable by wrapping it in "-whole-archive". I wonder if<br>
>     >we can do the same trick for profile runtime. I don't really know that,<br>
>     but it seems we have both GCDA profiling and new InstrProfiling stuff<br>
>     there, so pulling all of them into the executable<br>
>     >is not desirable, is it?<br>
><br>
>     I can't answer if we *should* do it put the profile runtime first, but I<br>
>     tested doing so and the change worked for me.<br>
><br>
> What do you mean? We can't put it first, because user libraries depend on it.<br>
> We fail when we put it last either, because<br>
> of this specific case, where user provides "-lc" + "-nostdlib".<br>
><br>
> We can workaround this by forcing to link in libprofile deps even if -nostdlib<br>
> is specified (assuming the user passing<br>
> this weird combination knows what (s)he is doing).<br>
><br>
> Or we can design a magic flag "--profile-lib", or smth. like this, which<br>
> would be matched and replaced by the path to actual static profile runtime in<br>
> the driver. Then you'd be able<br>
> to write ("clang++ -nostdlib a.o b.o --profile-lib -lc -lpthread").<br>
<br>
</span>Can we just teach clang where to find compiler-rt libraries and spell<br>
this like so?<br>
<br>
    clang++ -nostdlib a.o b.o -lclang_rt.profile -lc -lpthread<br>
<br>
I don't think I'd mind that so much, as it makes sense for clang to know<br>
where to find it's own runtime libraries.<br></blockquote><div><br></div><div>All compiler-rt libs are target-specific, so that would have to be -lclang_rt.profile-x86_64.</div><div>Forcing user to write triple-dependent linker invocation is not nice... However,</div><div>what we *might* do, is to restructure the way we layout resource directory, and</div><div>make triple-specific folders. That is, replace this:</div><div>  lib/clang/3.6.0/lib/linux/libclang_rt.profile-x86_64.a</div><div>with this:</div><div>  lib/clang/3.6.0/lib/x86_64-linux-gnu/libclang_rt.profile.a</div><div>... and then setup correct -L flag depending on the target triple. FWIW, I do something</div><div>similar in the internal compiler setup.</div><div>This is a rather intrusive change, though.<br></div><div><br></div><div>Also, this can work for profile or builtins runtimes, but won't work for sanitizers,</div><div>as they require complex changes to the linker invocation.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div>