symbols generated for coverage at mingw show incorrect link attributes

[llvmbot]

Bugzilla Link	37514
Version	trunk
OS	Windows XP
Attachments	sources
Reporter	LLVM Bugzilla Contributor
CC	@mstorsjo,@rnk

Extended Description

Compiled LLVM/CLANG head on a current MSYS2/MINGW64

Compiling an advanced production project failed with lots of dublicate symbol errors.

For one case I was able to provide an simple example. (code attached) Its a simplification of the scenario of a header defined inline function. There are much more scenarios with the same type of errors. Under my linux system I do not get these errors.

clang++ -fprofile-instr-generate -fcoverage-mapping -o llvmbug.exe cu1.cpp cu2.cpp

will complain about profdZ7inlfuncv defined in both compilation units.

By the way there are also errors of not defined symbols lprofGetHostName __llvm_profile_filename I just defined them as described in llvm-sources in my original project to silence them :-)

[mstorsjo]

I tried building with -fprofile-instr-generate in my setup, and the other things work fine (since I'm using LLD), but lprofGetHostName still is missing, I'll send a trivial patch for that.

But even then, after running my test binary, I do get an output file default.profraw created, but it's empty, so I presume that something still is disabled somewhere.

FWIW, I retested building and running code with -fprofile-instr-generate -fcoverage-mapping now again with the current trunk version of all clang/lld/compiler-rt, and I seem to proper coverage data out of it now.

[mstorsjo]

I recently got the coverage runtime working with MSVC, but I didn't get far with mingw. Is it worth the time to fix it?

I'm not off the hand familiar with it at all, so I can't really estimate how much effort it would be and whether it'd be worth the time.

Fair enough.

Based on the report so far, it sounds like another case of GNU ld not handling comdats like link.exe (which you changed in llvm in June last year iirc, at least for some cases), and missing runtime functions.

Yes, I don't think it will be possible to make this feature work with ld.bfd. It uses too many associative comdats. But it could work with LLD.

Which part provides those runtime functions? Is it compatible with what's existing in a libgcc setup, or does it require other functions provided by some part of compiler-rt (which I use in my setups)?

The instrumentation from the -fprofile-instr-generate flag calls into the libclang_rt.profile library. I don't think it is compatible with libgcc. You can test it with check-profile. I tried it in a mingw build because I didn't want to regress it if it already worked, but I don't think it has ever worked.

Hmm, running the runtimes testsuites is a bit tricky as I mostly work with cross compilation (and only occasionally fire up a windows VM to verify things), although I'm sure it would be good for me to invest the time into getting that set up.

I tried building with -fprofile-instr-generate in my setup, and the other things work fine (since I'm using LLD), but lprofGetHostName still is missing, I'll send a trivial patch for that.

But even then, after running my test binary, I do get an output file default.profraw created, but it's empty, so I presume that something still is disabled somewhere.

[rnk]

I recently got the coverage runtime working with MSVC, but I didn't get far with mingw. Is it worth the time to fix it?

I'm not off the hand familiar with it at all, so I can't really estimate how much effort it would be and whether it'd be worth the time.

Fair enough.

Based on the report so far, it sounds like another case of GNU ld not handling comdats like link.exe (which you changed in llvm in June last year iirc, at least for some cases), and missing runtime functions.

Yes, I don't think it will be possible to make this feature work with ld.bfd. It uses too many associative comdats. But it could work with LLD.

Which part provides those runtime functions? Is it compatible with what's existing in a libgcc setup, or does it require other functions provided by some part of compiler-rt (which I use in my setups)?

The instrumentation from the -fprofile-instr-generate flag calls into the libclang_rt.profile library. I don't think it is compatible with libgcc. You can test it with check-profile. I tried it in a mingw build because I didn't want to regress it if it already worked, but I don't think it has ever worked.

[mstorsjo]

I recently got the coverage runtime working with MSVC, but I didn't get far with mingw. Is it worth the time to fix it?

I'm not off the hand familiar with it at all, so I can't really estimate how much effort it would be and whether it'd be worth the time.

Based on the report so far, it sounds like another case of GNU ld not handling comdats like link.exe (which you changed in llvm in June last year iirc, at least for some cases), and missing runtime functions.

Which part provides those runtime functions? Is it compatible with what's existing in a libgcc setup, or does it require other functions provided by some part of compiler-rt (which I use in my setups)?

[rnk]

+Martin

I recently got the coverage runtime working with MSVC, but I didn't get far with mingw. Is it worth the time to fix it?

[llvmbot]

I did some further investigation. Despite produced with MINGW clang the objects are plain PE/COFF so I tried to link them with MSVC-LINK producing similar errors about doublicate symbols. Therefore it seems so thats really an llvm error.

I did some look into symbols and section headers. The symbols which fail are in a COMDAT 5 section with a link to a COMDAT 2 section. So they should only be linked if the COMDAT 2 section is linked.

Now I am stuck since I do not understand COMDAT enough.