similar to: lld + ThinLTO + fprofile-generate causes duplicate symbol errors

LLD revision is r331862. To add, I had initially tried it on r328903, which also reproduced the issue. On Wed, May 9, 2018 at 9:26 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > Hi Teresa, > > Thanks for looking into this. I hadn't initially tried ToT, but it > reproduces in ToT as well when I tried. > > $ ./clang --version > > clang version 7.0.0

Hi Pirama, I can't reproduce with either lld or gold, using a compiler built from head. What version is your clang? Thanks, Teresa On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The duplicate symbol errors are for __llvm_profile_filename and __llvm_profile_raw_version. > IIUC, these are supposed to be weak symbols but

On Wed, May 9, 2018 at 6:43 AM Teresa Johnson <tejohnson at google.com> wrote: > Hi Pirama, > > I can't reproduce with either lld or gold, using a compiler built from > head. What version is your clang? > (and your lld) > > Thanks, > Teresa > > On Tue, May 8, 2018 at 7:50 PM Pirama Arumuga Nainar via llvm-dev < > llvm-dev at lists.llvm.org>

Sorry, operator error. I can reproduce now. Interestingly, this does not reproduce using gold, and they utilize the same underlying LTO API. Let me dig a little using save-temps and see where they diverge. Teresa On Wed, May 9, 2018 at 9:28 AM Pirama Arumuga Nainar <pirama at google.com> wrote: > LLD revision is r331862. To add, I had initially tried it on r328903, > which also

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

Hi Teresa, Thanks for looking into this. I hadn't initially tried ToT, but it reproduces in ToT as well when I tried. $ ./clang --version clang version 7.0.0 (trunk 331879) (llvm/trunk 331888) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /ssd2/pirama/llvm-upstream/llvm-release/bin/. $ ./ld.lld --version LLD 7.0.0 (https://git.llvm.org/git/lld.git

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

I encountered an issue when enabling code coverage for Android and would like to confirm my findings and ask for suggestions. Here is my finding: When -fprofile-instr-generate, an llvm_prf_data section gets created that has entries for each function in the TU. One of the entries is FunctionAddr which holds the address of the function. Underneath, it is a relocation so it gets patched with the

Can you upload a reproducer? You can create it using the /linkrepro flag. Peter On Thu, Jun 7, 2018 at 2:50 PM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > GCC does comdats completely differently from the spec. Since you contacted > me about this off of the mailing list, I started investigating what they > do, and it is completely different. It's

The gold plugin supports many of the backend options. But Clang doesn't pass all of them to the plugin as it does to the backend. For example, to support -emulated-tls with LTO, Clang needs to pass -emulated-tls to the LTO backend. Shall I just change the driver to add -plugin-opt=-emulated-tls or is the best practice to embed this in the IR? -------------- next part -------------- An HTML

I encountered a segfault when using lld to cross-compile for Windows (+MinGW) from Linux. The problem happens with objects built by gcc. The problem is that ObjFile::CreateRegular considers a PendingComdat to be valid (and later causes an illegal pointer dereference). The following patch fixes the crash: diff --git a/COFF/InputFiles.cpp b/COFF/InputFiles.cpp index 9e2345b0a..f47d612df 100644

I'm an idiot and sent to llvm-commits instead of llvm-dev. Fixing. On 10/17/17, 5:09 PM, "llvm-commits on behalf of Shoaib Meenai via llvm-commits" <llvm-commits-bounces at lists.llvm.org on behalf of llvm-commits at lists.llvm.org> wrote: Hi all (CC beanz for cmake advice), I'm running into a cmake problem when I try to cross-compile a

The flags -fprofile-generate and -fprofile-use are currently ignored for GCC compatibility. I would like to enable them and give them similar semantics to GCC. These flags are baked pretty deeply into our build environment, so supporting them at the driver level will make our lives a lot simpler. >From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:

On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote: > The flags -fprofile-generate and -fprofile-use are currently ignored > for GCC compatibility. I would like to enable them and give them > similar semantics to GCC. These flags are baked pretty deeply into > our build environment, so supporting them at the driver level will > make our lives a lot

On Wed, Oct 25, 2017 at 09:13:54AM -0700, Xinliang David Li wrote: > On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > I've been working on implementing some basic functionality in order to > > use the llvm profiling functionality inside of a kernel (the Xen > > hypervisor).

On Thu, Apr 17, 2014 at 6:10 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > If accuracy is not critical, incrementing the counters without any guards > might be good enough. > No. Contention on the counters leads to 5x-10x slowdown. This is never good enough. --kcc Hot areas will still be hot and cold areas will not be affected. > > Yaron > > > >

On Fri, Apr 18, 2014 at 12:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > This is long thread, so I will combine several comments into single email. > > > >> - 8-bit per-thread counters, dumping into central counters on overflow. > >The overflow will happen very quickly with 8bit counter. > > Yes, but it reduces contention by 256x (a thread

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM

Yep, done that already, but it is not at all a good fit when the device is inside a drone flying around ;-) What we do have, is a fake file-system that keeps everything in memory, and after the profiling is completed we offload it for analysis. I guess I was hoping that there would be a more robust system agnostic implementation. Use of ‘mmap’ is similarly constraining. MartinO