https://bugs.kde.org/show_bug.cgi?id=389412
Christian Maurer <c.mau...@gmx.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |c.mau...@gmx.at
--- Comment #3 from Christian Maurer <c.mau...@gmx.at> ---
Hi Julian,
Hi Peter,
i am able to reproduce this error with a test program and hopefully can offer
some insights.
According to https://llvm.org/docs/CoverageMappingFormat.html#function-record
section "LLVM IR Representation"
"The coverage mapping data is stored in the LLVM IR using a single global
constant structure variable called __llvm_coverage_mapping with the
__llvm_covmap section specifier."
I constructed an executable (out of a small main.cpp and a generated large
mylib.cpp), which triggers the assertion.
--- START data from executable ---
readelf -S ValgrindTestGenerated
[output: see llvmcov_analysisOffendingSections_090120.txt for __llvm, relevant
entries:]
There are 45 section headers, starting at offset 0x2995150:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[14] .text PROGBITS 00000000002c7000 000c7000
0000000000db6e77 0000000000000000 AX 0 0 16
[33] __llvm_covmap PROGBITS 0000000000000000 0101f328
000000000035fd24 0000000000000000 0 0 8
readelf -sw ValgrindTestGenerated | grep cov
Symbol table '.symtab' contains 80343 entries:
Num: Value Size Type Bind Vis Ndx Name
16: 0000000000000000 132 OBJECT LOCAL DEFAULT 33
__llvm_coverage_mapping
40024: 0000000000000088 0x35fc9c OBJECT LOCAL DEFAULT 33
__llvm_coverage_mapping
--- END data from executable ---
Situation in the elf executable:
As stated in the documentation of the "LLVM IR Representation" (link given
above) we can see, that the __llvm_covmap symbol point to regions in the
__llvm_covmap section.
Note that the last __llvm_coverage_mapping (referencing mylib.o) ends at
000000000035fd24 [0000000000000088 + 0x35fc9c] )
Also note that the last __llvm_coverage_mapping
* starts greater than 0
* starts smaller than .text
* ends in .text ( 00000000002c7000 < 0000000000000088 + 0x35fc9c <
00000000002c7000 + 0000000000db6e77 )
=> these are the error conditions!
I used the attached program (see kdebug389412_package.zip) to generate an
executable, which fulfills these conditions and triggers the assertion when run
with valgrind.
--- START generating the executable ---
mkdir ValgrindTestGenerated
cp var/main.cpp ValgrindTestGenerated
cp var/mylib.h ValgrindTestGenerated
# note: 10000 worked for me, to provide the conditions stated above
ValgrindTest 10000 > ValgrindTestGenerated/mylib.cpp
compile and link the sources in "ValgrindTestGenerated" including the options
-fprofile-instr-generate -fcoverage-mapping
--- END generating the executable ---
I used vg-in-place to run the executable and had to use --max-stackframe
./vg-in-place --max-stackframe=17200080 --tool=memcheck --num-callers=25
--leak-check=full --child-silent-after-fork=yes --error-limit=no
<pathtotheexecutable>
--- START output with some debug info added ---
in_rx is not set, assertion will occur!
text-present:Y
text-size: 14380663
text-svma: 0x2c7000
sym-svma: 0x88
text-bias: 0
sym-avmas-out.main: 0x88
sym-size-out: 3538076
valgrind: m_debuginfo/readelf.c:727 (get_elf_symbol_info): Assertion 'in_rx'
failed.
--- END output with some debug info added ---
Kind regards,
Christian
--
You are receiving this mail because:
You are watching all bug changes.
