https://bugs.kde.org/show_bug.cgi?id=476548
--- Comment #3 from Jan Palus <jpalus+...@fastmail.com> ---
I've done some debugging and possibly found the culprit.
The assertion di->rodata_size == a_shdr.sh_size failed because left hand side
was 8 while the other was 3. However in readelf output for both stripped binary
and debuginfo file I see rodata size as 3. So assumed right hand side must be
correct. So I've checked why valgrind thinks it's 8 for debuginfo file and
found this:
2482 if (0 == VG_(strncmp)(name, ".rodata", 7)) {
2483 if ((inrx||inrw1) && !di->rodata_present) { /* first .rodata* */
2484 di->rodata_svma = svma;
2485 di->rodata_avma = svma;
2486 di->rodata_size = size;
2487 di->rodata_debug_svma = svma;
2488 } else if ((inrx||inrw1) && di->rodata_present) { /* not first
.rodata* */
2489 Addr tmp = VG_ROUNDUP(di->rodata_size + di->rodata_svma,
alyn);
2490 if (svma == tmp) { /* adjacent to previous .rodata* */
2491 di->rodata_size = size + tmp - di->rodata_svma;
2492 } else {
2493 BAD(".rodata"); /* is OK, but we cannot handle multiple
.rodata* */
2494 }
2495 }
https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_debuginfo/readelf.c;h=fb64ed9769d28e7f64762c8a34ebab8e353bc21f;hb=HEAD#l2482
It extends rodata_size with size of adjacent sections with name starting with
".rodata".
Both debuginfo and stripped binary have adjacent .rodata and .rodata.cst4
sections with size 3 and 4 respectively which I believe after aligning make 8:
[Nr] Name Type Address Off Size ES Flg
Lk Inf Al
[12] .rodata PROGBITS 000000000020059c 00059c 000003 00 A
0 0 1
[13] .rodata.cst4 PROGBITS 00000000002005a0 0005a0 000004 04 AM
0 0 4
I would assume same logic for accumulating size is not reflected here:
https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_debuginfo/readelf.c;h=fb64ed9769d28e7f64762c8a34ebab8e353bc21f;hb=HEAD#l3362
--
You are receiving this mail because:
You are watching all bug changes.
