[PATCH] D85116: [compiler-rt][profile] Fix various InstrProf tests on Solaris

[Rainer Orth via Phabricator via llvm-commits]

ro added a comment.

In D85116#2233800 <https://reviews.llvm.org/D85116#2233800>, @inferno wrote:

> First, how did you verify that this patch is the culprit? While it seems plausible, I've seen too many cases where a likely candidate turned out to be innocent, wasting everyone's time.
>
> When chromium folks were rolling clang, it was the only suspect in code coverage changes - llvmorg-12-init-1771-g1bd7046e : llvmorg-12-init-3492-ga1caa302 [like git hash, these are tags, git checkout to them work ]

That's exactly what I said: "suspect ... changes": relying on one's suspicion can be totally misleading (been there, done that). Instead, please start with the failing version of llvm, reproduce the failure, backout just my patch (it's only a single line after all), rebuild and retry.

> Can you please also provide lots of additional information:
>
> Which platform are you seeing this error on?
>
> Seen on linux. See red ones on https://oss-fuzz-build-logs.storage.googleapis.com/index.html#curl [for now, i had to hardcode a older clang commit]

Linux/x86_64 I assume?  There's nothing red there right now.

> Which revision of clang were you using? Any local changes? How exactly was cmake invoked?
>
> https://github.com/google/oss-fuzz/blob/master/infra/base-images/base-clang/checkout_build_install_llvm.sh

IIUC you're using a modified version of `clang`.  Please reproduce with vanilla upstream llvm first.

> Which linker do you use?
>
> System linker on ubuntu 16.04 inside docker. GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> Can you provide the output of readelf -SW for the binary that produces the error, the version of libclang_rt.profile-*.alinked, and if possible for the input objects that have __llvm_prf_names sections?
>
> libclang_rt.profile-x86_64.a

I meant: please provide the output of `readelf -SW` *for all of the binary, `libclang_rt.profile-*.a`, and the input objects.

> readelf -SW curl_fuzzer_ldap
> ============================
>
> There are 48 section headers, starting at offset 0xdc56e8:
>
> Section Headers:
>
>   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
>   [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0

[...]

>   [16] __llvm_prf_names  PROGBITS        00000000007c2b73 3c2b73 02ac61 00   A  0   0  1

[...]

> Key to Flags:
>
>   W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
>   I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>   O (extra OS processing required) o (OS specific), p (processor specific)

However, unlike the Solaris case my patch has fixed there's only a single instance of the `__llvm_prf_names` section.  Which means this is a different cause of the "Malformed coverage data".  There are 26 different places where this error is generated in `llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp`.  So to proceed (after verifying that the error occurs with vanilla llvm and my patch is indeed the culprit), one needs to identify which of those instances hits us here.

> I dont know how to get __llvm_prf_names section

Just run `readelf -SW` over every object/static library that is linked into the problematic binary.

After the verification I asked, I'll need a simple recipe to reproduce the issue.  I hope you'll understand that I won't wade through 14 MB of log file (that doesn't even show the error) to guess what might go wrong and how.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85116/new/

https://reviews.llvm.org/D85116