This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multi-threaded dwarf parsing
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: Tom Tromey <tom at tromey dot com>, Pedro Alves <palves at redhat dot com>, gdb at sourceware dot org
- Date: Wed, 24 Feb 2016 22:28:23 +0100
- Subject: Re: Multi-threaded dwarf parsing
- Authentication-results: sourceware.org; auth=none
- References: <2c38d5c574de28faa9fc94fe4ed17d45 at simark dot ca> <56CD8EC0 dot 3010304 at redhat dot com> <87lh6a6s8s dot fsf at tromey dot com> <c4dc7b1f07fe11da024684ec2de47a7e at simark dot ca> <20160224202519 dot GA10251 at host1 dot jankratochvil dot net> <345f3571aa56d4e9b6f6cbf4fa552f5f at simark dot ca>
On Wed, 24 Feb 2016 21:37:24 +0100, Simon Marchi wrote:
> What can cause CUs to be interlinked with each other?
I did not remember, from what I am checking now it is due to dwz:
https://sourceware.org/git/?p=dwz.git;a=blob;f=dwz.c
That is a DWARF size reduction tool (by DWARF optimization, not by any
compression).
All the CUs get queued there due to its DW_AT_import:
process_imported_unit_die()->maybe_queue_comp_unit()
Without dwz I could not reproduce the queueing problem. IIRC there was some
but I admit I may not remember it right.
BTW expanding one CU is also not cheap, just its .debug_info part can be
around 1MB:
readelf -wi libwebkitgtk-1.0.so.0.5.2.debug|grep '^ *<0>'|perl -lne 'BEGIN{$l=0;} /^\s*<0><([0-9a-f]+)>/ or die;$x=eval "0x$1";print(($x-$l)." ".$_);$l=$x;'|sort -nr
But that is a sub-second delay not much of a real problem.
Jan