search for: type_unit

...structures to allow fast lookup of CUs and TUs. Likely I'll start with: * adding llvm-dwarfdump support for the DWP indexes * basic prototype of llvm-dwp just concatenating sections * handle each of the domain specific relocations in turn * abbr_offset * debug_str_offsets.dwo entries * type_unit's DW_AT_stmt_list * references to debug_loc.dwo from debug_info.dwo * this one, at first blush, makes me particularly sad, as it'll involve actually walking all the DIEs in any CUs (stmt_list isn't great either, but at least that'd only be the header - same for accessing the...

...;ll start with: >> >> * adding llvm-dwarfdump support for the DWP indexes >> * basic prototype of llvm-dwp just concatenating sections >> * handle each of the domain specific relocations in turn >> * abbr_offset >> * debug_str_offsets.dwo entries >> * type_unit's DW_AT_stmt_list >> * references to debug_loc.dwo from debug_info.dwo >> * this one, at first blush, makes me particularly sad, as it'll >> involve actually walking all the DIEs in any CUs (stmt_list isn't great >> either, but at least that'd only be...

...ted at all. 3. Performance improvement by handling fewer data. #1 leads to loading and parsing fewer bits. 4. Performance improvement by handling fewer references. Simpler reference chains allow parsing references faster.   Instead of this : type_offset->proxy_type->DW_FORM_ref_sig8->type_unit->type_offset->type.   There would be this :   type_offset->type_table->type. >> >> We evaluated the approach on LLVM and Clang codebases. The >> results obtained are summarized in the tables below: >> >> >> Memory usage statis...

...ight be pretty close 'for free'. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130930/005c191d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: type_units.diff Type: application/octet-stream Size: 24606 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130930/005c191d/attachment.obj>

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on