[llvm-bugs] [Bug 32764] New: Find ways of reducing --reproduce archive size

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32764

            Bug ID: 32764
           Summary: Find ways of reducing --reproduce archive size
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: chisophugis at gmail.com
                CC: llvm-bugs at lists.llvm.org

This isn't a huge deal, but it would be nice to have. I'm not sure how feasible
this is either. Just posting this so we have a place to dump ideas.

The size of --reproduce archives actually matters, as it is often the
difference between whether a user can conveniently attach a reproducer to a bug
report/mail or has to go find some other hosting location. In cases where the
archive would be GB's, it just becomes infeasible to post it somewhere (e.g.
libclang.so in bug 31748) 

I suspect that there are some relatively easy ways to dramatically reduce the
(compressed) archive size.

One key observations is that for most kinds of linker bugs, the linker does not
care very much about the actual contents of sections, even though the contents
of sections are typically most of the size of the --reproduce archive.

One possibility is that there might be some quick and simple
transmogrifications we can do to input files as we put them in the --reproduce
archive (this can be guarded under a flag `--reproduce-compressify` or similar)

For example, most strings (main exception is symbol names I think) could be
replaced with `aaaaaa...` and the contents of .text and data sections can also
mostly be replaced with whatever we want (one exception, if we care, are
locations modified by certain relocations that care about the content, such as
implicit addends and relaxations). Debug info can also probably be stubbed out.

The main question will be what is the right tradeoff of simplicity vs extra
compressibility (or if there even exists a good tradeoff).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170424/214d1bcf/attachment.html>