[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 303877] valgrind doesn't support compressed debuginfo sections.
From:       Aleksandar Rikalo via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2016-04-13 13:58:27
Message-ID: bug-303877-17878-rVSLzq5Gjs () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=303877

--- Comment #34 from Aleksandar Rikalo <aleksandar.rikalo@imgtec.com> ---
(In reply to Ivo Raisr from comment #31)

Thank You for reviewing.

I have fixed all things that you mention. The full patch is attached, and the
new version of tests is also attached.

> 2) When including "tinfl.c", do we want to define "TINFL_HEADER_FILE_ONLY"?
> 20) I don't see any coregrind/Makefile changes to build m_debuginfo/tinfl.c?

In case we use #include "tinfl.c" without defining TINFL_HEADER_FILE_ONLY, we
don't need tinfl.c in Makefile.
If we include header only (by defining TINFL_HEADER_FILE_ONLY before #include)
then tinfl.c needs to be compiled separately (this solution is applied in rev2
patch). 

> 5) CEnt.data has now non-fixed size. Why CACHE_ENTRY_SIZE is still used in
> various places
> around image.c; for example in alloc_CEnt() and realloc_CEnt()?

CACHE_ENTRY_SIZE is still in use as default (and minimal) size of cache entry.
Larger entries will be allocated in case size of the uncompressed data is
grater than CACHE_ENTRY_SIZE.

> However I don't have any system with toolchain supporting '-gz' at hand.
> I assume you tested on MIPS. Anyone can test on a different architecture or
> distribution?

It seems that nobody has GCC which supports -gz, so the test is useless for
now.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]