From: Allan Sandfeld Jensen <email@example.com>
To: firstname.lastname@example.org, email@example.com
Subject: Re: DWZ 0.14 released
Date: Tue, 09 Mar 2021 09:06:54 +0100 [thread overview]
Message-ID: <7438883.9MRIfJ1mQo@twilight> (raw)
Btw, question for gcc/binutils
Any reason the work done by tools like dwz couldn't be done in the compiler or
linker? Seems a bit odd to have a post-linker that optimizes the generated
code, when optimizations should already be enabled.
On Montag, 8. März 2021 13:43:11 CET Tom de Vries wrote:
> DWZ 0.14 has been released.
> You can download dwz from the sourceware FTP server here:
> The vital stats:
> Size md5sum Name
> 184KiB cf60e4a65d9cc38c7cdb366e9a29ca8e dwz-0.14.tar.gz
> 144KiB 1f1225898bd40d63041d54454fcda5b6 dwz-0.14.tar.xz
> There is a web page for DWZ at:
> DWZ 0.14 includes the following changes and enhancements:
> * DWARF 5 support. The tool now handles most of DWARF version 5
> (at least everything emitted by GCC when using -gdwarf-5).
> 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
> * .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.
> 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
> * 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=basic, to possibly be
> able to workaround problems without having to switch off the
> optimization altogether.
> * The clean-up of temporary files in hardlink mode has been fixed.
> * The DIE limits --low-mem-die-limit <n> / -l <n> and
> --max-die-limit <n> / -L <n> 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.
> * 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.
> * 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.
> * A heuristic has been added that claims more memory earlier (without
> increasing the peak memory usage) to improve compression time.
> * 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
> * Various other performance improvements.
> * A case where previously we would either hit the assertion
> "dwz: dwz.c:9461: write_die: Assertion `refd != 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<n>".
> * 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.
> * 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.
> * A multi-file case where we run into ".debug_line reference above end
> of section" has been fixed.
> * The following assertion failures were fixed:
> - dwz: dwz.c:9310: write_die: Assertion `
> value && refdcu->cu_kind != CU_ALT
> ' failed.
> - dwz: dwz.c:9920: recompute_abbrevs: Assertion `
> off == cu_size
> ' failed.
> * The assert condition of this assertion has been fixed:
> - write_types: Assertion `ref && ref->die_dup == NULL'.
next prev parent reply other threads:[~2021-03-09 8:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 12:43 Tom de Vries
2021-03-09 8:06 ` Allan Sandfeld Jensen [this message]
2021-03-09 9:09 ` Mark Wielaard
2021-03-09 11:38 ` Hannes Domani
2021-03-09 11:45 ` Jakub Jelinek
2021-03-12 16:48 ` Nick Alcock
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).