bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/19109] Cannot configure default flag_compress_debug


From: mjw at redhat dot com
Subject: [Bug gas/19109] Cannot configure default flag_compress_debug
Date: Tue, 13 Oct 2015 09:48:47 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=19109

--- Comment #12 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to address@hidden from comment #11)
> On Mon, 12 Oct 2015, address@hidden wrote:
> 
> > I'd expect the option's default to be os-dependent, not arch-dependent.
> 
> I agree, as I said in 
> <https://sourceware.org/ml/binutils/2014-12/msg00154.html>.

Agreed. Looking at that thread the unconditional enabling was somewhat
controversial. Could we make it a target independent configure option that is
off by default for the current release? Then people could first experiment with
setting the default for gas generated ET_REL files to gnu or gabi and see which
tools break and update them if possible. And experiment with how this impacts
performance. Before enabling this by default (maybe in some next version if
enough feedback is collected).

BTW. How is the impact measured? It seems a positive for simple storage of the
ET_REL files (assuming the compression always reduces the size). But how does
it compare with just compressing the whole file, which is simpler to handle and
would give larger size reduction. For exchanging data between as and ld or
other tools dealing with ET_REL files it seems dependent on runtime factors.
Basically memory/cache size vs cpu performance for compressing/decompressing.
It prevents simply mmaping the ET_REL files and applying any relocations to the
compressed sections. One always has to read and decompress before processing
any such section. At which point is that a performance benefit? If the goal is
to minimize the data needed to process by a linker tool then how does it
compare to the GNU debug fission proposal (which might be standardized for
DWARF 5) that simply makes sure there is less DWARF data seen by the linker by
storing all non-relocatable debug sections in separate .dwo files.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]