[Bug 1567219] Re: Valgrind does not support compressed debug info
Bug Watch Updater
1567219 at bugs.launchpad.net
Thu Apr 7 11:24:11 UTC 2016
Launchpad has imported 27 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=303877.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-07-21T08:44:26+00:00 Paweł Sikora wrote:
for compressed debuginfo valgrind doesn't display source/line info.
Reproducible: Always
Steps to Reproduce:
$ cat t.cpp
int* p = 0;
int main()
{
*p = 0;
}
$ gcc t.cpp -gdwarf-4 -g2 -o t
$ valgrind ./t
==10551== Invalid write of size 4
==10551== at 0x4004F7: main (t.cpp:4)
$ objcopy --compress-debug-sections ./t
$ valgrind ./t
==10568== Invalid write of size 4
==10568== at 0x4004F7: main (in /home/users/pawels/bugs/t)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/0
------------------------------------------------------------------------
On 2012-07-23T11:30:09+00:00 Tom Hughes wrote:
Neither it seems do lots of other things - is this something the DWARF
standard actually allows? or just some wierd GNU extension?
In any case it's probably unlikely that valgrind would support it as it
would require linking in a copy of zlib...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/1
------------------------------------------------------------------------
On 2012-07-23T11:36:33+00:00 Tom Hughes wrote:
Technology note for anybody that looks at this in the future - the
implementation of this feature appears to be that each .debug_xxx
section is replaced by a .zdebug_xxx section that has been zlib
compressed.
Note that some binutils tools like objdump will attempt to hide this
fact and show the original section, decompressing on the fly if you try
and read it.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/2
------------------------------------------------------------------------
On 2012-07-24T07:44:36+00:00 Paweł Sikora wrote:
(In reply to comment #2)
> Technology note for anybody that looks at this in the future - the
> implementation of this feature appears to be that each .debug_xxx section is
> replaced by a .zdebug_xxx section that has been zlib compressed.
>
> Note that some binutils tools like objdump will attempt to hide this fact
> and show the original section, decompressing on the fly if you try and read
> it.
binutils/gdb contain small bfd/compress.c utility for handling .zdebug_*
sections.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/3
------------------------------------------------------------------------
On 2012-08-17T08:02:39+00:00 Jseward wrote:
(In reply to comment #1)
> In any case it's probably unlikely that valgrind would support it as it
> would require linking in a copy of zlib...
I don't see that as a big deal technically .. so that would just leave the question
of whether it is OK from a license-compatbility point of view. Assuming, of course,
that we decide to support this.
How does this relate to the DWZ initiative?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/4
------------------------------------------------------------------------
On 2012-08-17T08:04:18+00:00 Tom Hughes wrote:
It's completely unrelated to DWZ I think.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/5
------------------------------------------------------------------------
On 2013-02-28T13:35:14+00:00 Jseward wrote:
Do we need to move this forward? Is .zdebug gaining mainstream
acceptance?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/6
------------------------------------------------------------------------
On 2013-02-28T13:54:26+00:00 Tom Hughes wrote:
I think this bug is the only reference I've come across to it. As far as
I know DWZ is the more mainstream approach at the moment.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/7
------------------------------------------------------------------------
On 2013-03-03T11:04:24+00:00 Paweł Sikora wrote:
dwz is completely different thing. dwz optimizes dwarf data while objdump just compress (zlib)
whole sections. the difference is visible on non-trivial shared objects compiled with -g2 in few ways:
1). when you have a big application with 200+ big shared objects in use
then the gdb startup time is much shorter with compressed debug info.
this is a major benefit for debug/build/debug cycles.
2). relinking libraries is faster (linker reads/writes less data from deps
with compressed sections). one more benefit for debug/build cycles.
3). objdump compression is more effective than dwz.
170M libgenChip.so
65M libgenChip.so.zdebug
148M libgenChip.so.dwz
60M libgenChip.so.dwz.zdebug
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/8
------------------------------------------------------------------------
On 2015-12-16T14:28:10+00:00 Роман Донченко wrote:
> Do we need to move this forward? Is .zdebug gaining mainstream
acceptance?
Yes and yes. Debian now defaults to compressing their debugging symbols
(this change was made in debhelper v9, if anyone's curious).
On x86_64 you can at least get call stacks, since .eh_frame is
mandatory, but on, say, ARM or ARM64 it's not. So the call stacks stop
at the first C-only library.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/9
------------------------------------------------------------------------
On 2016-01-05T12:59:03+00:00 Mjw-x wrote:
(In reply to Роман Донченко from comment #9)
> > Do we need to move this forward? Is .zdebug gaining mainstream acceptance?
>
> Yes and yes. Debian now defaults to compressing their debugging symbols
> (this change was made in debhelper v9, if anyone's curious).
Debian does not seems to use GNU .zdebug compression, but a different
kind of ELF section compression. They seem to have adopted the new ELF
standardized SHF_COMPRESSED variant. Which is somewhat strange since I
don't believe any release of binutils, nor elfutils, supports that yet
(it will be in binutils 2.26 and elfutils 0.165, but those have not yet
been released). So effectively nothing supports that kind of ELF section
compression yet.
It is also a bit questionable whether this kind of compression of debug
sections is really beneficial. It prevents easy indexing and lazy
loading of data, causing huge startup delays whenever any debuginfo is
needed. It would be better to adopt dwz style compression.
> On x86_64 you can at least get call stacks, since .eh_frame is mandatory,
> but on, say, ARM or ARM64 it's not. So the call stacks stop at the first
> C-only library.
That is a different Debian bug though, gcc: Enable -fasynchronous-
unwind-tables on more arches: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=746426
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/10
------------------------------------------------------------------------
On 2016-01-05T18:23:58+00:00 Роман Донченко wrote:
(In reply to Mark Wielaard from comment #10)
> Debian does not seems to use GNU .zdebug compression,
It does, though not for all packages yet. Here's an example:
<https://packages.debian.org/jessie/debug/libopenjpeg5-dbg>.
> On x86_64 you can at least get call stacks, since .eh_frame is mandatory,
> > but on, say, ARM or ARM64 it's not. So the call stacks stop at the first
> > C-only library.
>
> That is a different Debian bug though, gcc: Enable
> -fasynchronous-unwind-tables on more arches:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746426
I wouldn't really call that a bug. Yeah, they don't build with that
flag, but they don't have to. Debugging symbols provide the same
information.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/11
------------------------------------------------------------------------
On 2016-01-05T19:42:03+00:00 Mjw-x wrote:
(In reply to Роман Донченко from comment #11)
> (In reply to Mark Wielaard from comment #10)
> > Debian does not seems to use GNU .zdebug compression,
>
> It does, though not for all packages yet. Here's an example:
> <https://packages.debian.org/jessie/debug/libopenjpeg5-dbg>.
O, indeed that one does use GNU .zdebug compression. But others like
https://packages.debian.org/stretch/libc6-dbg seem to use a different
ELF section compression method (use normal .debug names and set the
SHF_COMPRESSED flag to indicate that the section data contains a
ELF_Chdr plus compressed data).
Now I am slightly confused, what is Debian really using and why?
> > On x86_64 you can at least get call stacks, since .eh_frame is mandatory,
> > > but on, say, ARM or ARM64 it's not. So the call stacks stop at the first
> > > C-only library.
> >
> > That is a different Debian bug though, gcc: Enable
> > -fasynchronous-unwind-tables on more arches:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746426
>
> I wouldn't really call that a bug. Yeah, they don't build with that flag,
> but they don't have to. Debugging symbols provide the same information.
Except that most people won't have the debug files installed, not all
packages have them and if they use GNU .zdebug or ELF section
compression then, as this bug points out, valgrind won't be able to use
them :) Other distros do use -fasynchronous-unwind-tables on all arches
to make sure the unwind tables are always there, which does make lots of
tools (not just valgrind) happy.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/12
------------------------------------------------------------------------
On 2016-01-05T20:21:42+00:00 Роман Донченко wrote:
(In reply to Mark Wielaard from comment #12)
> (In reply to Роман Донченко from comment #11)
> > It does, though not for all packages yet. Here's an example:
> > <https://packages.debian.org/jessie/debug/libopenjpeg5-dbg>.
>
> O, indeed that one does use GNU .zdebug compression. But others like
> https://packages.debian.org/stretch/libc6-dbg seem to use a different ELF
> section compression method (use normal .debug names and set the
> SHF_COMPRESSED flag to indicate that the section data contains a ELF_Chdr
> plus compressed data).
>
> Now I am slightly confused, what is Debian really using and why?
I see what's going on now. stretch (being in development) uses a
bleeding-edge version of binutils, which appears to have changed the
semantics of --compress-debug-sections. Now it creates SHF_COMPRESSED
.debug sections rather than .zdebug sections. jessie uses binutils 2.25,
so it has the .zdebug sections.
So it does appear that SHF_COMPRESSED is the future. .zdebug, however,
is the present, so ideally Valgrind should support both.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/13
------------------------------------------------------------------------
On 2016-01-31T16:28:54+00:00 Julian-kde wrote:
Since libc and a number of binaries have now been built with this
compressed debug info on Debian (and quite possibly on its derivatives,
too), valgrind is sadly becoming less and less useful. Any progress on
this request would be much appreciated!
Thanks,
Julian
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/14
------------------------------------------------------------------------
On 2016-01-31T16:35:05+00:00 Tom Hughes wrote:
It's highly unlikely that there will be any quick progress, because any
fix would be require valgrind to be able to decompress zlib compressed
data but valgrind is not able to link to libraries so we can't just use
zlib like most programs would.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/15
------------------------------------------------------------------------
On 2016-01-31T17:19:43+00:00 Роман Донченко wrote:
FWIW, it's not necessary to use zlib itself. For example, miniz
(https://github.com/richgel999/miniz) is a single-file library that
implements zlib decoding.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/16
------------------------------------------------------------------------
On 2016-01-31T17:35:33+00:00 Tom Hughes wrote:
That's certainly useful to know about - it even has an "inflate only"
version.
It will still need some patching to stop it use memcpy/memset etc.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/17
------------------------------------------------------------------------
On 2016-01-31T21:25:47+00:00 Philippe Waroquiers wrote:
An alternative is also the simple/super small 'inflate' implementation in zlib code
zlib-1.2.8/contrib/puff.h and puff.c
This is a fully independent inflate implementation (no #include).
There are some drawbacks (2 times slower than the real zlib inflate, and as it does
not do memory allocation, inflate fails if the target buffer is too small
(and so, you must redo the inflate with a bigger buffer).
If the debug info stores the uncompressed size, then this is not a problem
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/18
------------------------------------------------------------------------
On 2016-02-29T14:55:10+00:00 Aleksandar-rikalo wrote:
Created attachment 97607
Compressed debug sections support for Valgrind - rev 1
I suggest the following solution.
The patch has been tested on MIPS32/64.
Applying the patch:
patch -p1 < compressed-dwarf-support.diff
Note: tinfl.c from miniz project (https://github.com/richgel999/miniz)
is used without modifications.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/19
------------------------------------------------------------------------
On 2016-03-04T00:54:24+00:00 Andres+bugs-kde-org wrote:
Aleksandar, great, that works for postgres on debian unstable!
I do however get a number of mostly harmless warnings:
In file included from m_debuginfo/image.c:52:0:
./tinfl.c: In function ‘tinfl_decompress_mem_to_heap’:
./tinfl.c:514:11: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pBuf); *pOut_len = 0; return NULL;
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c:523:11: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pBuf); *pOut_len = 0; return NULL;
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c: In function ‘tinfl_decompress_mem_to_callback’:
./tinfl.c:560:8: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pDict);
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c:29:0: warning: "MINIZ_HAS_64BIT_REGISTERS" redefined
#define MINIZ_HAS_64BIT_REGISTERS 1
^
m_debuginfo/image.c:51:0: note: this is the location of the previous definition
#define MINIZ_HAS_64BIT_REGISTERS ( VG_WORDSIZE == 8 )
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c: In function ‘tinfl_decompress_mem_to_heap’:
./tinfl.c:514:11: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pBuf); *pOut_len = 0; return NULL;
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c:523:11: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pBuf); *pOut_len = 0; return NULL;
^
In file included from m_debuginfo/image.c:52:0:
./tinfl.c: In function ‘tinfl_decompress_mem_to_callback’:
./tinfl.c:560:8: warning: left-hand operand of comma expression has no effect [-Wunused-value]
MZ_FREE(pDict);
^
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/20
------------------------------------------------------------------------
On 2016-03-07T14:36:21+00:00 Aleksandar-rikalo wrote:
Created attachment 97742
Avoid warnings from tinfl.c
In order to avoid these warnings we need to modify tinfl.c in some way.
I suggest the attached solution. MZ_MALLOC/REALLOC/FREE, memcpy, memset, etc. are replaced with appropriate Valgrind functions. Tinfl is also added to Makefile, so it can be used from other parts of project.
The patch can be applied after applying compressed-dwarf-support.diff.
To apply the patch use command:
patch -p1 < tinfl-modifications.diff
The alternative solution is to delete "High level decompression
functions" from tinfl.c.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/21
------------------------------------------------------------------------
On 2016-03-09T01:46:21+00:00 Quanah wrote:
These patches don't work with the current release:
../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-image.o): In function `get_slowcase':
/tmp/valgrind/valgrind-3.11.0/coregrind/m_debuginfo/image.c:636: undefined reference to `tinfl_decompress_mem_to_mem'
collect2: error: ld returned 1 exit status
make[3]: *** [memcheck-amd64-linux] Error 1
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/22
------------------------------------------------------------------------
On 2016-03-11T09:31:28+00:00 Aleksandar-rikalo wrote:
It looks strange...
Have you run ./autogen.sh before compiling ?
I've tested the same configuration (amd64, linux) with trunk and VALGRIND_3_11_0 revisions.
However, the patch is not tested on arm and ppc.
(In reply to Quanah Gibson-Mount from comment #22)
> These patches don't work with the current release:
>
> ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-image.o):
> In function `get_slowcase':
> /tmp/valgrind/valgrind-3.11.0/coregrind/m_debuginfo/image.c:636: undefined
> reference to `tinfl_decompress_mem_to_mem'
> collect2: error: ld returned 1 exit status
> make[3]: *** [memcheck-amd64-linux] Error 1
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/23
------------------------------------------------------------------------
On 2016-03-11T21:22:57+00:00 Quanah wrote:
(In reply to Aleksandar Rikalo from comment #23)
> It looks strange...
> Have you run ./autogen.sh before compiling ?
No, I didn't realize that was required. I'll give it another shot, as I
also need the patch to correctly handle software that dl_close's objects
as well (https://bugs.kde.org/show_bug.cgi?id=79362)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/24
------------------------------------------------------------------------
On 2016-03-12T22:42:29+00:00 Sami-liedes wrote:
That patch doesn't build on Debian amd64, at least on top of Debian's
version of valgrind:
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/lib/valgrind"\" -DVG_PLATFORM="\"amd64-linux\"" -m64 -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -DENABLE_LINUX_TICKET_LOCK -g -O2 -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/x86_64-linux-gnu -c -o m_debuginfo/libcoregrind_amd64_linux_a-readelf.o `test -f 'm_debuginfo/readelf.c' || echo './'`m_debuginfo/readelf.c
m_debuginfo/readelf.c:67:6: error: conflicting types for ‘Elf32_Chdr’
} Elf32_Chdr;
^
In file included from m_debuginfo/readelf.c:56:0:
/usr/include/elf.h:385:3: note: previous declaration of ‘Elf32_Chdr’ was here
} Elf32_Chdr;
^
m_debuginfo/readelf.c:76:6: error: conflicting types for ‘Elf64_Chdr’
} Elf64_Chdr;
^
In file included from m_debuginfo/readelf.c:56:0:
/usr/include/elf.h:393:3: note: previous declaration of ‘Elf64_Chdr’ was here
} Elf64_Chdr;
^
Makefile:4878: recipe for target 'm_debuginfo/libcoregrind_amd64_linux_a-readelf.o' failed
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/25
------------------------------------------------------------------------
On 2016-03-13T04:03:41+00:00 Ivo Raisr wrote:
Thank you for providing the patches.
I get the same compilation problem on Solaris
because Elf32/64_Chdr come from the VKI interface.
I think the problem lies here in coregrind/m_debuginfo/readelf.c:
============================
+#if !defined(Elf32_Chdr)
+ typedef struct {
+ Elf32_Word ch_type;
+ Elf32_Word ch_size;
+ Elf32_Word ch_addralign;
+ } Elf32_Chdr;
+#endif
...
============================
However it is incorrect to assume that a typedef can be checked via #if defined().
Morever, such definitions should be placed in the corresponding vki-* header files
(if really necessary).
After removing Elf32_Chdr, Elf64_Chdr, SHF_COMPRESSED and ELFCOMPRESS_ZLIB from
readelf.c, the patches compile fine and regression testing went ok on Solaris.
It would be also nice if a simple test is provided. Ideally the configure would check if the
corresponding command line option is supported and has an effect. Then it would enable/disable the test based on its availability.
Definitions of MINIZ_LITTLE_ENDIAN and MINIZ_HAS_64BIT_REGISTERS
(possibly others) need to be consistent across the board. Currently
these are set in image.c and tinfl.c itself, based on different
criteria. Stick to those in image.c.
Also placing tinfl.c directly into coregrind is not appropriate. If m_debuginfo is the only
consumer than tinfl.c needs to be moved there. If not, then pub_core_tinfl.h needs to present
a proper Valgrind interface usable and understandable by other parts of the core, not the tinfl.c mess.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1567219/comments/26
** Changed in: valgrind
Status: Unknown => New
** Changed in: valgrind
Importance: Unknown => Medium
** Bug watch added: Debian Bug tracker #746426
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746426
** Bug watch added: KDE Bug Tracking System #79362
https://bugs.kde.org/show_bug.cgi?id=79362
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to valgrind in Ubuntu.
https://bugs.launchpad.net/bugs/1567219
Title:
Valgrind does not support compressed debug info
Status in Valgrind:
New
Status in valgrind package in Ubuntu:
Confirmed
Bug description:
== Comment: #0 - Andreas Arnez <arnez at de.ibm.com> - 2016-04-01 12:23:20 ==
It seems that some Ubuntu debug packages are built with compressed debug info, which is not supported by Valgrind. In particular I've seen that this even applies to the dynamic loader (when libc6-dbg is installed):
$ ./vg-in-place /bin/true
==5907== Memcheck, a memory error detector
==5907== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5907== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==5907== Command: /bin/true
==5907==
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/ld-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/ld-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/ld-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/ld-2.23.so:
--5907-- Last block truncated in .debug_info; ignoring
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/ld-2.23.so:
--5907-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/libc-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/libc-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/libc-2.23.so:
--5907-- Ignoring non-Dwarf2/3/4 block in .debug_info
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/libc-2.23.so:
--5907-- Last block truncated in .debug_info; ignoring
--5907-- WARNING: Serious error when reading debug info
--5907-- When reading debug info from /lib/s390x-linux-gnu/libc-2.23.so:
--5907-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
==5907==
==5907== HEAP SUMMARY:
==5907== in use at exit: 0 bytes in 0 blocks
==5907== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5907==
==5907== All heap blocks were freed -- no leaks are possible
==5907==
==5907== For counts of detected and suppressed errors, rerun with: -v
==5907== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
== Comment: #1 - Andreas Arnez <arnez at de.ibm.com> - 2016-04-01 12:26:28 ==
Note that this issue should apply to all platforms. It has already been reported for upstream Valgrind, and a patch has been proposed:
https://bugs.kde.org/show_bug.cgi?id=303877
To manage notifications about this bug go to:
https://bugs.launchpad.net/valgrind/+bug/1567219/+subscriptions
More information about the foundations-bugs
mailing list