probinson added a comment. I haven't given Pavel's comments as much thought as they deserve, but here are some of mine.
It's a worthwhile point that a class ought to represent some useful and reasonably well defined abstraction. DataExtractor has one, and DWARFDataExtractor builds on that (at least in the LLVM parser) by handling relocations; the most reasonable way to handle multiple buffers would be with multiple extractors, building on top of what's there rather than hacking the insides. One aspect I am looking at is that the LLVM parser needs to handle .o files, which can have multiple .debug_types (in v4) or .debug_info (in v5) sections, because the units are broken up into COMDATs. So, the dumper needs to be able to handle an arbitrary number of either kind of section, where LLDB needs at most one of each section. One way of dealing with all this is to have a vector or deque of sections, each section has its DWARFDataExtractor and knows its own "base offset" which would be the sum of the sizes of the preceding sections. I don't know how awkward it might be to turn this into a meta-extractor that hid details from consumers, but then I think it probably would not be all that hard to have consumers be aware that there can be multiple lumps of DWARF and get the offsets right on their own. https://reviews.llvm.org/D32167 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
