[llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array.test
I removed this test to unblock the ARM bots while looking into failures
(r374915), and am reinstating it now with a fix.
I believe the problem was that counter ptr address I used,
'\0\0\6\0\1\0\0\1', set the high bits of the pointer, not the low bits
like I wanted. On x86_64 this superficially looks like it tests r370826,
but it doesn't, as it would have been caught before r370826. However, on
ARM (or, 32-bit hosts more generally), I suspect the high bits were
cleared, and you get a 'valid' profile.
I verified that setting the *low* bits of the pointer does trigger the
new condition:
-// Note: The CounterPtr here is off-by-one. This should trigger a malformed profile error.
-RUN: printf '\0\0\6\0\1\0\0\1' >> %t.profraw
+// Note: The CounterPtr here is off-by-one.
+//
+// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters,
+// the profile reader should error out.
+RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw
This reverts commit c7cf5b3e4b918c9769fd760f28485b8d943ed968.
llvm-svn: 374927
2019-10-15 19:53:48 +02:00
|
|
|
// Header
|
|
|
|
//
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, Magic, __llvm_profile_get_magic())
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, Version, __llvm_profile_get_version())
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, DataSize, DataSize)
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, CountersSize, CountersSize)
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, NamesSize, NamesSize)
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, CountersDelta, (uintptr_t)CountersBegin)
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, NamesDelta, (uintptr_t)NamesBegin)
|
|
|
|
// INSTR_PROF_RAW_HEADER(uint64_t, ValueKindLast, IPVK_Last)
|
|
|
|
|
|
|
|
RUN: printf '\201rforpl\377' > %t.profraw
|
[profile] Add a mode to continuously sync counter updates to a file
Add support for continuously syncing profile counter updates to a file.
The motivation for this is that programs do not always exit cleanly. On
iOS, for example, programs are usually killed via a signal from the OS.
Running atexit() handlers after catching a signal is unreliable, so some
method for progressively writing out profile data is necessary.
The approach taken here is to mmap() the `__llvm_prf_cnts` section onto
a raw profile. To do this, the linker must page-align the counter and
data sections, and the runtime must ensure that counters are mapped to a
page-aligned offset within a raw profile.
Continuous mode is (for the moment) incompatible with the online merging
mode. This limitation is lifted in https://reviews.llvm.org/D69586.
Continuous mode is also (for the moment) incompatible with value
profiling, as I'm not sure whether there is interest in this and the
implementation may be tricky.
As I have not been able to test extensively on non-Darwin platforms,
only Darwin support is included for the moment. However, continuous mode
may "just work" without modification on Linux and some UNIX-likes. AIUI
the default value for the GNU linker's `--section-alignment` flag is set
to the page size on many systems. This appears to be true for LLD as
well, as its `no_nmagic` option is on by default. Continuous mode will
not "just work" on Fuchsia or Windows, as it's not possible to mmap() a
section on these platforms. There is a proposal to add a layer of
indirection to the profile instrumentation to support these platforms.
rdar://54210980
Differential Revision: https://reviews.llvm.org/D68351
2019-09-19 20:56:43 +02:00
|
|
|
RUN: printf '\5\0\0\0\0\0\0\0' >> %t.profraw
|
[llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array.test
I removed this test to unblock the ARM bots while looking into failures
(r374915), and am reinstating it now with a fix.
I believe the problem was that counter ptr address I used,
'\0\0\6\0\1\0\0\1', set the high bits of the pointer, not the low bits
like I wanted. On x86_64 this superficially looks like it tests r370826,
but it doesn't, as it would have been caught before r370826. However, on
ARM (or, 32-bit hosts more generally), I suspect the high bits were
cleared, and you get a 'valid' profile.
I verified that setting the *low* bits of the pointer does trigger the
new condition:
-// Note: The CounterPtr here is off-by-one. This should trigger a malformed profile error.
-RUN: printf '\0\0\6\0\1\0\0\1' >> %t.profraw
+// Note: The CounterPtr here is off-by-one.
+//
+// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters,
+// the profile reader should error out.
+RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw
This reverts commit c7cf5b3e4b918c9769fd760f28485b8d943ed968.
llvm-svn: 374927
2019-10-15 19:53:48 +02:00
|
|
|
RUN: printf '\1\0\0\0\0\0\0\0' >> %t.profraw
|
[profile] Add a mode to continuously sync counter updates to a file
Add support for continuously syncing profile counter updates to a file.
The motivation for this is that programs do not always exit cleanly. On
iOS, for example, programs are usually killed via a signal from the OS.
Running atexit() handlers after catching a signal is unreliable, so some
method for progressively writing out profile data is necessary.
The approach taken here is to mmap() the `__llvm_prf_cnts` section onto
a raw profile. To do this, the linker must page-align the counter and
data sections, and the runtime must ensure that counters are mapped to a
page-aligned offset within a raw profile.
Continuous mode is (for the moment) incompatible with the online merging
mode. This limitation is lifted in https://reviews.llvm.org/D69586.
Continuous mode is also (for the moment) incompatible with value
profiling, as I'm not sure whether there is interest in this and the
implementation may be tricky.
As I have not been able to test extensively on non-Darwin platforms,
only Darwin support is included for the moment. However, continuous mode
may "just work" without modification on Linux and some UNIX-likes. AIUI
the default value for the GNU linker's `--section-alignment` flag is set
to the page size on many systems. This appears to be true for LLD as
well, as its `no_nmagic` option is on by default. Continuous mode will
not "just work" on Fuchsia or Windows, as it's not possible to mmap() a
section on these platforms. There is a proposal to add a layer of
indirection to the profile instrumentation to support these platforms.
rdar://54210980
Differential Revision: https://reviews.llvm.org/D68351
2019-09-19 20:56:43 +02:00
|
|
|
RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
|
[llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array.test
I removed this test to unblock the ARM bots while looking into failures
(r374915), and am reinstating it now with a fix.
I believe the problem was that counter ptr address I used,
'\0\0\6\0\1\0\0\1', set the high bits of the pointer, not the low bits
like I wanted. On x86_64 this superficially looks like it tests r370826,
but it doesn't, as it would have been caught before r370826. However, on
ARM (or, 32-bit hosts more generally), I suspect the high bits were
cleared, and you get a 'valid' profile.
I verified that setting the *low* bits of the pointer does trigger the
new condition:
-// Note: The CounterPtr here is off-by-one. This should trigger a malformed profile error.
-RUN: printf '\0\0\6\0\1\0\0\1' >> %t.profraw
+// Note: The CounterPtr here is off-by-one.
+//
+// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters,
+// the profile reader should error out.
+RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw
This reverts commit c7cf5b3e4b918c9769fd760f28485b8d943ed968.
llvm-svn: 374927
2019-10-15 19:53:48 +02:00
|
|
|
RUN: printf '\2\0\0\0\0\0\0\0' >> %t.profraw
|
[profile] Add a mode to continuously sync counter updates to a file
Add support for continuously syncing profile counter updates to a file.
The motivation for this is that programs do not always exit cleanly. On
iOS, for example, programs are usually killed via a signal from the OS.
Running atexit() handlers after catching a signal is unreliable, so some
method for progressively writing out profile data is necessary.
The approach taken here is to mmap() the `__llvm_prf_cnts` section onto
a raw profile. To do this, the linker must page-align the counter and
data sections, and the runtime must ensure that counters are mapped to a
page-aligned offset within a raw profile.
Continuous mode is (for the moment) incompatible with the online merging
mode. This limitation is lifted in https://reviews.llvm.org/D69586.
Continuous mode is also (for the moment) incompatible with value
profiling, as I'm not sure whether there is interest in this and the
implementation may be tricky.
As I have not been able to test extensively on non-Darwin platforms,
only Darwin support is included for the moment. However, continuous mode
may "just work" without modification on Linux and some UNIX-likes. AIUI
the default value for the GNU linker's `--section-alignment` flag is set
to the page size on many systems. This appears to be true for LLD as
well, as its `no_nmagic` option is on by default. Continuous mode will
not "just work" on Fuchsia or Windows, as it's not possible to mmap() a
section on these platforms. There is a proposal to add a layer of
indirection to the profile instrumentation to support these platforms.
rdar://54210980
Differential Revision: https://reviews.llvm.org/D68351
2019-09-19 20:56:43 +02:00
|
|
|
RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
|
[llvm-profdata] Reinstate tools/llvm-profdata/malformed-ptr-to-counter-array.test
I removed this test to unblock the ARM bots while looking into failures
(r374915), and am reinstating it now with a fix.
I believe the problem was that counter ptr address I used,
'\0\0\6\0\1\0\0\1', set the high bits of the pointer, not the low bits
like I wanted. On x86_64 this superficially looks like it tests r370826,
but it doesn't, as it would have been caught before r370826. However, on
ARM (or, 32-bit hosts more generally), I suspect the high bits were
cleared, and you get a 'valid' profile.
I verified that setting the *low* bits of the pointer does trigger the
new condition:
-// Note: The CounterPtr here is off-by-one. This should trigger a malformed profile error.
-RUN: printf '\0\0\6\0\1\0\0\1' >> %t.profraw
+// Note: The CounterPtr here is off-by-one.
+//
+// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters,
+// the profile reader should error out.
+RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw
This reverts commit c7cf5b3e4b918c9769fd760f28485b8d943ed968.
llvm-svn: 374927
2019-10-15 19:53:48 +02:00
|
|
|
RUN: printf '\10\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\0\0\6\0\1\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\0\0\6\0\2\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
// Data Section
|
|
|
|
//
|
|
|
|
// struct ProfData {
|
|
|
|
// #define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) \
|
|
|
|
// Type Name;
|
|
|
|
// #include "llvm/ProfileData/InstrProfData.inc"
|
|
|
|
// };
|
|
|
|
|
|
|
|
RUN: printf '\067\265\035\031\112\165\023\344' >> %t.profraw
|
|
|
|
RUN: printf '\02\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
// Note: The CounterPtr here is off-by-one.
|
|
|
|
//
|
|
|
|
// Octal '\11' is 9 in decimal: this should push CounterOffset to 1. As there are two counters,
|
|
|
|
// the profile reader should error out.
|
|
|
|
RUN: printf '\11\0\6\0\1\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\0\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\02\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
// Counter Section
|
|
|
|
|
|
|
|
RUN: printf '\067\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
RUN: printf '\101\0\0\0\0\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
// Name Section
|
|
|
|
|
|
|
|
RUN: printf '\3\0bar\0\0\0' >> %t.profraw
|
|
|
|
|
|
|
|
RUN: not llvm-profdata merge -o /dev/null %t.profraw 2>&1 | FileCheck %s
|
|
|
|
CHECK: Malformed instrumentation profile data
|