Patch implements --compress-debug-sections=zlib.
In compare with D20211 (a year old patch, abandoned), it implementation
uses streaming and fully reimplemented, does not support zlib-gnu for
simplification.
This is PR32308.
Differential D31941
[ELF] - Implemented --compress-debug-sections option. grimar on Apr 11 2017, 8:50 AM. Authored by
Details Patch implements --compress-debug-sections=zlib. In compare with D20211 (a year old patch, abandoned), it implementation This is PR32308.
Diff Detail
Event TimelineComment Actions This patch doesn't use multiple cores to compress .debug section contents. In theory, if there are multiple .debug sections, we can compress them separately. Can you do that? The code that writes section contents into an in-memory buffer looks very similar to code that writes sections to the output file buffer. This needs fixing. The other approach I can think of is to do everything as a post-process. After writing everything to the output buffer, you scan .debug sections (that are at end of file), compress them in-place, and then shifts them to fill the holes created by data compression. Have you thought about that?
Comment Actions zlib format specification (http://www.zlib.org/rfc-zlib.html, 2.2. Data format) says that it has header, some data and checksum after, it not just a piece of raw bytes that we can If so it may be reasonable to implement threading compression API for LLVM and reuse it in LLD. That probably means we can go with simple streaming imprementation for start and replace code in OutputSection::finalize() with threading solution when it be implemented. What do you think ?
That should be solveable.
I thought about different post-process and droped idea (it was estimate somehow max compressed size and compress in place in writeTo. If estimated size value minus real size value would be something not too large, And your suggestion doesn't look too clean either, does it ? That would mean that we do not know final layout even during writing, what a bit wierd. And then either we need to fixup sections headers and write them after other data. Then do shifting and after that all truncate output file, right ? That is a bit too tricky for my eye. That may degradate perfomance either, probably.
Comment Actions What I was saying was that you can compress multiple sections concurrently, right? I didn't say you should try to compress single stream of data using multiple threads. I meant, since we have multiple .debug_ sections, you could compress them separately.
Comment Actions
Comment Actions OK, I understood differently. Thought you're talking about multithreaded compression for input .debug* sections.
Comment Actions
Comment Actions LGTM There is a room for improvements, but I'll do that after you submit this.
|
I think we can simplify this to nex one now ?