Roland McGrath wrote:
My sense of the priority order of our tasks at large granularity is
this:
1. basic writer data structure building (designed for the eventual fancy plans)
What are these "fancy plans"? DWARF compression (as in zlib) was
mentioned a couple times, so that might be one (although that would need
reader support, too, wouldn't it?), anything else? I expect that the
"semantic compression" will be built on top of this, as an application
rather than intrinsic feature of the library.
Also, what level do you want to write the writer on? C? There is "C++
interface for writer" item on your list of tasks, but it's not clear
whether C++ is the place where the writer will be implemented, or rather
a place where it would be wrapped.
I'm thinking that .debug_abbrev is one approach to compression that
isn't currently held back by absence of reference equality component.
To do it, one needs to be able to write/modify .debug_info, and that in
turn requires writing of/modifying .debug_loc, .debug_pub*, and
.debug_aranges. A hack that would recompute .debug_aranges and
.debug_pub* and write them to disk would be sufficient for starters, and
and I don't think I've seen any DW_OP_call_ref in any of our binaries at
all. So we could in fact have something in hand soonish...
PM