[AIX][PGO] Enable linux style PGO on AIX

This patch switches the PGO implementation on AIX from using the runtime
registration-based section tracking to the __start_SECNAME/__stop_SECNAME
based. In

[AIX][PGO] Enable linux style PGO on AIX

This patch switches the PGO implementation on AIX from using the runtime
registration-based section tracking to the __start_SECNAME/__stop_SECNAME
based. In order to enable the recognition of __start_SECNAME/__stop_SECNAME
symbols in the AIX linker, the -bdbg:namedsects:ss needs to be used.

Reviewed By: jsji, MaskRay, davidxl

Differential Revision: https://reviews.llvm.org/D124857

show more ...

[InstrProf][NFC] Do not assume size of counter type

Existing code tended to assume that counters had type `uint64_t` and
computed size from the number of counters. Fix this code to directly
compute

[InstrProf][NFC] Do not assume size of counter type

Existing code tended to assume that counters had type `uint64_t` and
computed size from the number of counters. Fix this code to directly
compute the counters size in number of bytes where possible. When the
number of counters is needed, use `__llvm_profile_counter_entry_size()`
or `getCounterTypeSize()`. In a later diff these functions will depend
on the profile mode.

Change the meaning of `DataSize` and `CountersSize` to make them more clear.
* `DataSize` (`CountersSize`) - the size of the data (counter) section in bytes.
* `NumData` (`NumCounters`) - the number of data (counter) entries.

Reviewed By: kyulee

Differential Revision: https://reviews.llvm.org/D116179

show more ...

[profile] Fix writing binary id into profiles

This patch adds support to read all the PT_NOTE segments in the
executable to find the binary ids. Previously, it was only reading
the first PT_NOTE seg

[profile] Fix writing binary id into profiles

This patch adds support to read all the PT_NOTE segments in the
executable to find the binary ids. Previously, it was only reading
the first PT_NOTE segment, and this was missing the cases where
binary id is in the following segments. As a result, binary-id.c
and binary-id-padding.c test were failing in the following cases:
1) sanitizer-x86_64-linux bot
https://lab.llvm.org/staging/#/builders/97
2) OpenSuse Tumbleweed
https://github.com/llvm/llvm-project/issues/52695

Differential Revision: https://reviews.llvm.org/D115830

show more ...

[llvm][profile] Add padding after binary IDs

Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binar

[llvm][profile] Add padding after binary IDs

Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binary
IDs. This means padding should be emitted after binary IDs are emitted to
ensure everything else is aligned. This patch adds padding after each binary ID
to ensure the next binary ID size is 8-byte aligned. This also adds extra
checks to ensure we aren't reading corrupted data when printing binary IDs.

Differential Revision: https://reviews.llvm.org/D110365

show more ...

Revert "[compiler-rt][profile] Add padding after binary IDs"

This reverts commit 6bc9c8dfe32cc4662f2ed9041af527f69dfff13b.

Reverted because this broke some PPC buildbots.

[compiler-rt][profile] Add padding after binary IDs

Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emittin

[compiler-rt][profile] Add padding after binary IDs

Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binary
IDs. This means padding should be emitted after binary IDs are emitted to
ensure everything else is aligned. This patch accounts for that padding in
__llvm_write_binary_ids.

Differential Revision: https://reviews.llvm.org/D110188

show more ...

[profile] Add static keyword to binary id functions

This patch adds static keyword to internal functions that write
binary id to restrict visibility to the file that they are declared.

Differential

[profile] Add static keyword to binary id functions

This patch adds static keyword to internal functions that write
binary id to restrict visibility to the file that they are declared.

Differential Revision: https://reviews.llvm.org/D108154

show more ...

[profile] Only use NT_GNU_BUILD_ID if supported

The Solaris buildbots have been broken for some time by the unconditional
use of `NT_GNU_BUILD_ID`, e.g. Solaris/sparcv9
<https://lab.llvm.org/staging

[profile] Only use NT_GNU_BUILD_ID if supported

The Solaris buildbots have been broken for some time by the unconditional
use of `NT_GNU_BUILD_ID`, e.g. Solaris/sparcv9
<https://lab.llvm.org/staging/#/builders/50/builds/4910> and Solaris/amd64
<https://lab.llvm.org/staging/#/builders/101/builds/3751>. Being a GNU
extension, it is not defined in `<sys/elf.h>`. However, providing a
fallback definition doesn't help because the code also relies on
`__ehdr_start`, another unportable GNU extension that most likely never
will be implemented in Solaris `ld`. Besides, there's reallly no point in
supporting build ids since they aren't used on Solaris at all.

This patch fixes this by making the relevant code conditional on the
definition of `NT_GNU_BUILD_ID`.

Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D107556

show more ...

Work around non-existence of ElfW(type) macro on FreeBSD

Fixes PR51331. On FreeBSD, the elf headers don't (yet) provide the
ElfW(type) macro. However, there is a similar set of macros in the
<sys/el

Work around non-existence of ElfW(type) macro on FreeBSD

Fixes PR51331. On FreeBSD, the elf headers don't (yet) provide the
ElfW(type) macro. However, there is a similar set of macros in the
<sys/elf-generic.h> header, of which `__ElfN(type)` exactly matches the
indended purpose.

Reviewed By: gulfem

Differential Revision: https://reviews.llvm.org/D107388

show more ...

[profile] Add binary id into profiles

This patch adds binary id into profiles to easily associate binaries
with the corresponding profiles. There is an RFC that discusses
the motivation, design and

[profile] Add binary id into profiles

This patch adds binary id into profiles to easily associate binaries
with the corresponding profiles. There is an RFC that discusses
the motivation, design and implementation in more detail:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151154.html

Differential Revision: https://reviews.llvm.org/D102039

show more ...

Revert "[profile] Add binary id into profiles"

Revert "[profile] Change linkage type of a compiler-rt func"
This reverts commits f984ac2715f71c38a7872fa2c2ad535b3d4fa285 and
467c7191249b76abff33853b

Revert "[profile] Add binary id into profiles"

Revert "[profile] Change linkage type of a compiler-rt func"
This reverts commits f984ac2715f71c38a7872fa2c2ad535b3d4fa285 and
467c7191249b76abff33853b1692a77f327c2422 because it broke some builds.

show more ...

[profile] Change linkage type of a compiler-rt func

This patch changes the linkage type of a compiler-rt func
(__llvm_write_binary_ids) to fix the sanitizer-windows bot
build issue introduced in cha

[profile] Change linkage type of a compiler-rt func

This patch changes the linkage type of a compiler-rt func
(__llvm_write_binary_ids) to fix the sanitizer-windows bot
build issue introduced in change f984ac271.

The issue is as the following:
C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingInternal.h(201):
error C2496: '__llvm_write_binary_ids': 'selectany' can only be applied
to data items with external linkage

show more ...

[profile] Add binary id into profiles

This patch adds binary id into profiles to easily associate binaries
with the corresponding profiles. There is an RFC that discusses
the motivation, design and

[profile] Add binary id into profiles

This patch adds binary id into profiles to easily associate binaries
with the corresponding profiles. There is an RFC that discusses
the motivation, design and implementation in more detail:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151154.html

Differential Revision: https://reviews.llvm.org/D102039

show more ...

[profile] Delete zero-size dummy sections

They were added so that if no metadata section is present,
`__start_llvm_prf_*` references would not cause "undefined symbol"
errors. By switching to undef

[profile] Delete zero-size dummy sections

They were added so that if no metadata section is present,
`__start_llvm_prf_*` references would not cause "undefined symbol"
errors. By switching to undefined weak symbols in D96936, the dummy
sections are not needed.

This patch is also needed to work around
https://sourceware.org/bugzilla/show_bug.cgi?id=27490

Differential Revision: https://reviews.llvm.org/D97648

show more ...

[profile] Make {__start_,__stop_}__llvm_prf_* symbols undefined weak

To make a kind of metadata section usage work, we want to drop the
`__start_/__stop_ references retain C identifier name sections

[profile] Make {__start_,__stop_}__llvm_prf_* symbols undefined weak

To make a kind of metadata section usage work, we want to drop the
`__start_/__stop_ references retain C identifier name sections` rule from LLD (see D96914).

If an application has no `__llvm_prf_data` input section surviving --gc-sections,
LLD will error for undefined hidden `{__start_,__stop_}__llvm_prf_*` from `libclang_rt.profile-*`.
Other `__llvm_prf_*` sections have similar issues.

Making the references weak can address the problem.
This probably enables the opportunity to drop zero size dummy sections in `InstrProfilingPlatformLinux.c`.

Reviewed By: davidxl

Differential Revision: https://reviews.llvm.org/D96936

show more ...

[profile] Add __attribute__((used)) to zero size dummy sections

D14468 added these dummy sections. This patch adds `__attribute__((used))` so
that when compiled by GCC>=11 or (expected, D96838) Clan

[profile] Add __attribute__((used)) to zero size dummy sections

D14468 added these dummy sections. This patch adds `__attribute__((used))` so
that when compiled by GCC>=11 or (expected, D96838) Clang>=13 on some ELF platforms,
these sections will get SHF_GNU_RETAIN to make sure they will not be discarded
by ld --gc-sections.

We are trying to get rid of LLD's "__start_/__stop_ references retain C identifier name sections" rule.
If LLD drops the rule in the future (we will retain compatibility for `__llvm_prf_*` for a while),
`__llvm_prf_*` will need to have the SHF_GNU_RETAIN flag, otherwise:

```
// __llvm_prf_cnts/__llvm_prf_data usually exist, but {names,vnds} may not exist.
// Such diagnostics will happen with {cnts,data} as well if no input object file is instrumented.
% clang++ -fprofile-generate a.cc -fuse-ld=lld -Wl,--gc-sections
ld.lld: error: undefined hidden symbol: __start___llvm_prf_names
>>> referenced by InstrProfilingPlatformLinux.c
>>> InstrProfilingPlatformLinux.c.o:(__llvm_profile_begin_names) in archive /tmp/RelA/lib/clang/13.0.0/lib/linux/libclang_rt.profile-x86_64.a
...
```

Differential Revision: https://reviews.llvm.org/D96902

show more ...

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

Currently, several InstrProf tests `FAIL` on Solaris (both sparc and x86):

Profile-i386 :: Posix/instrprof-visibility.cpp
Profile-i

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

Currently, several InstrProf tests `FAIL` on Solaris (both sparc and x86):

Profile-i386 :: Posix/instrprof-visibility.cpp
Profile-i386 :: instrprof-merging.cpp
Profile-i386 :: instrprof-set-file-object-merging.c
Profile-i386 :: instrprof-set-file-object.c

On sparc there's also

Profile-sparc :: coverage_comments.cpp

The failure mode is always the same:

error: /var/llvm/local-amd64/projects/compiler-rt/test/profile/Profile-i386/Posix/Output/instrprof-visibility.cpp.tmp: Failed to load coverage: Malformed coverage data

The error is from `llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp`
(`loadBinaryFormat`), l.926:

InstrProfSymtab ProfileNames;
std::vector<SectionRef> NamesSectionRefs = *NamesSection;
if (NamesSectionRefs.size() != 1)
return make_error<CoverageMapError>(coveragemap_error::malformed);

where .size() is 2 instead.

Looking at the executable, I find (with `elfdump -c -N __llvm_prf_names`):

Section Header[15]: sh_name: __llvm_prf_names
sh_addr: 0x8053ca5 sh_flags: [ SHF_ALLOC ]
sh_size: 0x86 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x3ca5 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1

Section Header[31]: sh_name: __llvm_prf_names
sh_addr: 0x8069998 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x9998 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x1

Unlike GNU `ld` (which primarily operates on section names) the Solaris
linker, following the ELF spirit, only merges input sections into an output
section if both section name and section flags match, so two separate
sections are maintained.

The read-write one comes from `lib/clang/12.0.0/lib/sunos/libclang_rt.profile-i386.a(InstrProfilingPlatformLinux.c.o)`
while the read-only one is generated by
`llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp` (`InstrProfiling::emitNameData`)
at l.1004 where `isConstant = true`.

The easiest way to avoid the mismatch is to change the definition in
`compiler-rt/lib/profile/InstrProfilingPlatformLinux.c` to `const`.

This fixes all failures observed.

Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.

Differential Revision: https://reviews.llvm.org/D85116

show more ...

Revert "[InstrProfiling] Use !associated metadata for counters, data and values"

This reverts commit 69c5ff4668cd4d1bfb6b45d71e15c12e3a23ae05.
This reverts commit 603d58b5e49c76e4a2e5bf1450b71b100a3

Revert "[InstrProfiling] Use !associated metadata for counters, data and values"

This reverts commit 69c5ff4668cd4d1bfb6b45d71e15c12e3a23ae05.
This reverts commit 603d58b5e49c76e4a2e5bf1450b71b100a3396ba.
This reverts commit ba10bedf5631eda3a17df428c88451c754633d23.
This reverts commit 39b3c41b65302a969fa5507402976a255a07c158.

show more ...

[InstrProfiling] Use !associated metadata for counters, data and values

The !associated metadata may be attached to a global object declaration
with a single argument that references another global

[InstrProfiling] Use !associated metadata for counters, data and values

The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.

Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.

Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.

Differential Revision: https://reviews.llvm.org/D76802

show more ...

Revert "[InstrProfiling] Use !associated metadata for counters, data and values"

This reverts commit 39b3c41b65302a969fa5507402976a255a07c158 due to
a failing associated.ll test.

[InstrProfiling] Use !associated metadata for counters, data and values

The !associated metadata may be attached to a global object declaration
with a single argument that references another global

[InstrProfiling] Use !associated metadata for counters, data and values

The !associated metadata may be attached to a global object declaration
with a single argument that references another global object. This
metadata prevents discarding of the global object in linker GC unless
the referenced object is also discarded.

Furthermore, when a function symbol is discarded by the linker, setting
up !associated metadata allows linker to discard counters, data and
values associated with that function symbol. This is not possible today
because there's metadata to guide the linker. This approach is also used
by other instrumentations like sanitizers.

Note that !associated metadata is only supported by ELF, it does not have
any effect on non-ELF targets.

Differential Revision: https://reviews.llvm.org/D76802

show more ...

Reland compiler-rt support for order file instrumentation.

r355343 was landed and was reverted in r355363 due to build breakage.
This patch adds Linux/Windows support on top of r355343.

In this pat

Reland compiler-rt support for order file instrumentation.

r355343 was landed and was reverted in r355363 due to build breakage.
This patch adds Linux/Windows support on top of r355343.

In this patch, Darwin should be working with testing case. Linux should be working,
I will enable the testing case in a follwup diff. Windows/Other should be building.
Correct implementation for Other platforms will be added.

Thanks David for reviewing the original diff, helping me with issues on Linux, and
giving suggestions for adding support for Other platforms.

llvm-svn: 355701

show more ...

Revert compiler-rt diffs for order file instrumentation to get bot green!

This caused issues on Linux/Windows and other platforms.

r355343 355350 355350

llvm-svn: 355363

Attemp to fix build brokage due to D57530.

By adding implementations for __llvm_profile_begin_orderfile for non-Darwin platforms.

llvm-svn: 355350

[InstrProf] Implement static profdata registration

Summary:
The motivating use case is eliminating duplicate profile data registered
for the same inline function in two object files. Before this cha

[InstrProf] Implement static profdata registration

Summary:
The motivating use case is eliminating duplicate profile data registered
for the same inline function in two object files. Before this change,
users would observe multiple symbol definition errors with VC link, but
links with LLD would succeed.

Users (Mozilla) have reported that PGO works well with clang-cl and LLD,
but when using LLD without this static registration, we would get into a
"relocation against a discarded section" situation. I'm not sure what
happens in that situation, but I suspect that duplicate, unused profile
information was retained. If so, this change will reduce the size of
such binaries with LLD.

Now, Windows uses static registration and is in line with all the other
platforms.

Reviewers: davidxl, wmi, inglorion, void, calixte

Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D57929

llvm-svn: 353547

show more ...