https://sourceware.org/bugzilla/show_bug.cgi?id=19109
--- Comment #8 from Nick Clifton <nickc at redhat dot com> --- Hi Mark, > Is there anything target specific about compressed debug sections? Yes and no. If the ABI for a given target does not support compressed debug sections then technically they might be considered to be breaking the ABI. Practically, if all of the tools that consume that target's binaries know about compressed debug sections, or don't care, then their presence should not matter. Of course this PR raises the issue that not all consumers of x86 linux binaries are aware of these sections. Hence one of the features of the patch: You can choose when configuring a particular target whether or not you want compressed debug sections to be the default. The patch also allows the binutils maintainers to set a default value for this configure option on a per-target basis. So as targets, and their tools, become compressed debug section aware the default for that target can be changed to "yes". > Why can't we make the default apply to all targets? I was trying to make a patch that preserved the status quo whilst at the same time allowing toolchain builders to choose whether or not compressed debug sections are the default. Currently x86 linux toolchains default to compressing debug sections. (My assumption here is that H.J. is pushing for the adoption of this technology, which is why he made this change). The patch preserves the current default behaviour of x86 linux toolchains, but it does allow individual toolchain builders, or package maintainers, to configure with --enable-default-compressed-debug-sections=no to turn this off. We could make compressing debug sections the default for all targets, but this is bound to break something. Better for now I think to default to normal debug sections for targets until the maintainers for those targets are sure that they are ready for compressed debug sections. > From H.J. > I'd like to know if DWARF info compression in binutils will be ever > be on by default. Yes, I expect this to happen. > If no, why bother with a configure option? We just > default it to "no". If yes, when will it happen? I do not know when. My guess is that the default will stay at "no" (for non x86 toolchains). Then slowly each target will change over their default to be "yes" and at some point, we will say, "this is silly - lets just make the default be yes and specify the targets that still need a default of no". Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils