On Wed, Sep 16, 2020, 4:03 AM Alex Coplan <alex.cop...@arm.com> wrote:
> Hi Ian, > > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote: > > This patch to libbacktrace adds support for MiniDebugInfo, as > > requested in PR 93608. > > This appears to introduce a failure in the libbacktrace testsuite > (observed on both x86 and aarch64): > > ../gcc/libbacktrace/../test-driver: line 107: 7905 Segmentation fault > (core dumped) "$@" > $log_file 2>&1 > FAIL: mtest_minidebug I tested on x86 without seeing anything like this. Can you give me any more details? Thanks. Ian > > MiniDebugInfo stores compressed symbol tables for an executable, where > > the executable is otherwise stripped. It is documented at > > https://fedoraproject.org/wiki/Features/MiniDebugInfo and > > https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html. > > > > Unfortunately, although debug info processors are already required to > > handle data compressed using zlib aka gzip in order to handle zdebug > > and SHT_COMPRESSED, the MiniDebugInfo implementation choose to instead > > compress the debug information with xz which uses LZMA2. This in > > effect forces all debug info processors to add a second decompression > > algorithm. Note to future developers: do not do this. > > > > This libbacktrace implementation includes a new small LZMA > > decompressor that just decompresses from one buffer to another. It is > > not heavily optimized, and on my laptop runs at about 78% of the speed > > of using liblzma directly. I think this is a decent tradeoff for > > keeping the code reasonably small. > > > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > > to mainline. > > > > Ian > > Thanks, > Alex >
