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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1567219 Title: Valgrind does not support compressed debug info To manage notifications about this bug go to: https://bugs.launchpad.net/valgrind/+bug/1567219/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
