From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay4-3.pub.mailoutpod1-cph3.one.com (mailrelay4-3.pub.mailoutpod1-cph3.one.com [46.30.212.13]) by sourceware.org (Postfix) with ESMTPS id B996D3836C1D for ; Tue, 9 Mar 2021 08:06:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B996D3836C1D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=carewolf.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=linux@carewolf.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carewolf.com; s=20191106; h=content-type:content-transfer-encoding:mime-version:references:in-reply-to: message-id:date:subject:cc:to:from:from; bh=eQMs38VJ4QwLgFwP7HghjZUO/TDyWTo/Qe+XqrODY64=; b=eE2XRsuBoHDSY/OwrerhrXSFiPPDjYkX8yuYS9tIyjAqPXBCSKGxaooXwVJ+Xd4OdBvq8eL5v+2kY Oa9opD/76YWuiWR3m4Bm+7+fJcjKDNdgUi7UG3GdTpZetdsGnmtK1RAwQC7nL58XDexFg2J6I5tzYt rnZaUlF3Qk8k/wpF54J/LtsP/ji0AmM3jLVPHyvVfOkcobiWWo79d2DGBfTlUECrWMmZgKSJhaA8KC MPM8yknePDgocWgsuvat3VmlHks1ts53/C00oRsmV7B4Pc3RWv9DAZbtP2dwteSrOZfBloAzvpL9qA RqrfVvjG5whNSFmI9IvPc1hg1k8G//A== X-HalOne-Cookie: 2031b47107455d008120e58e7338ef452997a046 X-HalOne-ID: 6941dc50-80ae-11eb-a8f8-d0431ea8bb10 Received: from twilight.localnet (unknown [158.181.74.243]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 6941dc50-80ae-11eb-a8f8-d0431ea8bb10; Tue, 09 Mar 2021 08:06:55 +0000 (UTC) From: Allan Sandfeld Jensen To: gcc@gcc.gnu.org, binutils@sourceware.org Cc: dwz@sourceware.org Subject: Re: DWZ 0.14 released Date: Tue, 09 Mar 2021 09:06:54 +0100 Message-ID: <7438883.9MRIfJ1mQo@twilight> In-Reply-To: <9f72f4e2-10b8-ac32-565e-b96314911d66@suse.de> References: <9f72f4e2-10b8-ac32-565e-b96314911d66@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:06:59 -0000 Btw, question for gcc/binutils Any reason the work done by tools like dwz couldn't be done in the compiler= or=20 linker? Seems a bit odd to have a post-linker that optimizes the generated= =20 code, when optimizations should already be enabled. Best regards Allan On Montag, 8. M=E4rz 2021 13:43:11 CET Tom de Vries wrote: > Hi, >=20 > DWZ 0.14 has been released. >=20 > You can download dwz from the sourceware FTP server here: >=20 > https://sourceware.org/ftp/dwz/releases/ > ftp://sourceware.org/pub/dwz/releases/ >=20 > The vital stats: >=20 > Size md5sum Name > 184KiB cf60e4a65d9cc38c7cdb366e9a29ca8e dwz-0.14.tar.gz > 144KiB 1f1225898bd40d63041d54454fcda5b6 dwz-0.14.tar.xz >=20 > There is a web page for DWZ at: >=20 > https://sourceware.org/dwz/ >=20 > DWZ 0.14 includes the following changes and enhancements: >=20 > * DWARF 5 support. The tool now handles most of DWARF version 5 > (at least everything emitted by GCC when using -gdwarf-5). >=20 > Not yet supported are DW_UT_type units (DWARF 4 .debug_types > are supported), .debug_names (.gdb_index is supported) and some > forms and sections that are only emitted by GCC when > generating Split DWARF (DW_FORM_strx and .debug_str_offsets, > DW_FORM_addrx and .debug_addr, DW_FORM_rnglistx and > DW_FORM_loclistsx). https://sourceware.org/PR24726 >=20 > * .debug_sup support. DWARF Supplementary Object Files > (DWARF 5, section 7.3.6) can now be generated when using > the --dwarf-5 option. To keep compatibility with existing DWARF > consumers this isn't the default yet. >=20 > Without the --dwarf-5 option instead of a .debug_sup section dwz > will generate a .gnu_debugaltlink section and will use > DW_FORM_GNU_strp_alt and DW_FORM_GNU_reg_alt, instead of > DW_FORM_strp_sup and DW_FORM_ref_sup >=20 > * An experimental optimization has been added that exploits the > One-Definition-Rule of C++. It's enabled using the --odr option, and > off by default. This optimization causes struct/union/class DIEs with > the same name to be considered equal. The optimization can be set to > a lower aggressiveness level using --odr-mode=3Dbasic, to possibly be > able to workaround problems without having to switch off the > optimization altogether. >=20 > * The clean-up of temporary files in hardlink mode has been fixed. >=20 > * The DIE limits --low-mem-die-limit / -l and > --max-die-limit / -L can now be disabled using respectively > -l none and -L none. Note that -l none disables the limit, whereas > -l 0 sets the limit to zero. >=20 > * The usage message has been: > - updated to show that -r and -M are exclusive. > - updated to show at -v and -? cannot be combined with other options. > - extended to list all options in detail. > - restyled to wrap at 80 chars. >=20 > * An option --no-import-optimize was added that switches off an > optimization that attempts to reduce the number of > DW_TAG_imported_unit DIEs. This can be used f.i. in case the > optimization takes too long. >=20 > * A heuristic has been added that claims more memory earlier (without > increasing the peak memory usage) to improve compression time. >=20 > * A heuristic has been added that estimates whether one of the two DIE > limits will be hit. If so, it will do an exact DIE count to verify > this. If the exact DIE count finds that the low-mem DIE limit is > indeed hit, processing is done in low-mem mode from the start, rather > than processing in regular mode first. If the exact DIE count finds > that the max DIE limit is indeed hit, processing is skipped > altogether. >=20 > * Various other performance improvements. >=20 > * A case where previously we would either hit the assertion > "dwz: dwz.c:9461: write_die: Assertion `refd !=3D NULL' failed" (in > regular mode) or a segmentation fault (in low-mem mode), now is > handled by "dwz: Couldn't find DIE at DW_FORM_ref_addr offset 0x". >=20 > * A case where a reference from a partial unit to a compile unit was > generated has been fixed. This could happen if a DIE was referenced > using a CU-relative DWARF operator. >=20 > * A case has been fixed for low-mem mode where instead of issuing > "dwz: Couldn't find DIE referenced by DW_OP_GNU_implicit_pointer" dwz > would run into a segfault instead. >=20 > * A multi-file case where we run into ".debug_line reference above end > of section" has been fixed. >=20 > * The following assertion failures were fixed: > - dwz: dwz.c:9310: write_die: Assertion ` > value && refdcu->cu_kind !=3D CU_ALT > ' failed. > - dwz: dwz.c:9920: recompute_abbrevs: Assertion ` > off =3D=3D cu_size > ' failed. >=20 > * The assert condition of this assertion has been fixed: > - write_types: Assertion `ref && ref->die_dup =3D=3D NULL'.