public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Tom de Vries <>,
Subject: Re: dwz 0.14 release?
Date: Sat, 27 Feb 2021 00:37:18 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


I propose we do a release on Monday March 1. Unless people think there
are still some release critical issues that need to be resolved first.

On Fri, Feb 19, 2021 at 02:16:12AM +0100, Mark Wielaard wrote:
> There are 53 open bugs right now. I looked briefly at all of
> them. Most are ideas for improvements of various forms. For more
> optimizations or supporting certain DWARF constructs. A couple simply
> don't have enough information to replicate the issue. Or are for
> things that are hard to support, like the mips bug (26738) or the
> emit-relocs issue (24345).
> I don't believe any of the bugs are regressions since 0.13. But the
> following 6 bugs seem good to take a quick look at to see if a fix is
> easy, but none of them seem like real showstoppers for a
> release. Since there are a lot of things fixed and new features since
> 0.13 I think we should do a release as soon as we know these aren't
> fixed in a couple of days.
> [odr] dwz.c:11404: write_die: Assertion `value && refdcu->cu_kind != CU_ALT'
>       failed. #2 
> For which you just posted a patch.

This (and bug 25439) have been fixed by commit 3312feb17 "Fix CK_BAD
propagation for --odr".

> hardlink handling leaves temporary file if not file compressed
> This is mostly an annoyance, but I haven't figured out the code to fix it.

Status still the same.

> Document that the --odr flag is currently experimental
> Would be nice to have documented what works and what still needs work
> There are a couple of ODR bugs for which I didn't know the current
> status, e.g. Bug 24198 (which is the tracker bug?)

Documentation patch has been posted:

> Emit more detailed diagnostic output for "Unknown DWARF" 
> This has improved a bit. I don't think we need to go so far as the
> reporter would like. But we could add a bit more output to some of the
> errors like we did in commit 4705796eb "Add DIE offsets in error
> messages to make it easier to find what is wrong."

With another followup commit 1e2beb218 "Print abbrev or DIE offset for
Unknown DWARF error message". The error messages can still be
improved, so lets keep the bug open for now.

> dwz: returns exit status 1, causing FTBFS in deal.ii
> This seems partially fixed, but still has a patch that looks
> plausible, but I don't really know if it is still needed.

Unclear how to test this. So still open.

> Forward pseudo-reference triggers error
> Seems like a real issue. And has a test binary that triggers the
> issue. On the other hand this test binary is slightly odd. It is
> referenced in a couple of other bug reports, but it seems unclear how
> it was ever generated. This might not be easily fixable without adding
> a new pass over the whole DIE tree. Unless someone has a clever idea.

No updates.

Some other bugs updated since last Friday:

  dwz: 1: Unknown DWARF DW_OP_0
  Thanks to the new diagnostics tracked down to possible GCC bug.

  [dwz] Unhandled DW_FORM_sdata for DW_AT_decl_line
  Filed and fixed.

  [dwz] Report unknown dwarf problem only once
  Another request for better error diagnostics

  [dwz, odr, multifile] Multifile after odr not optimal
  Filed and fixed

  [dwz, fixed-needs-testcase] CU referenced from PU
  Patch posted, needs review:

  CU referenced from PU (--odr-mode=link case)
  Patch posted, needs review:

  CU referenced from PU (--odr-mode=link case) (bis)
  Patch posted, needs, review:

  [dwz] Improve heuristics for odr
  New enhancement bug

  [dwz, testsuite] mode 4 in checksum_ref_die not exercised in test-suite
  Patch posted, needs review:

  [dwz, dwarf5] Add --dwarf-5 flag to generate .debug_sup, ref_sup and

  [dwz] Segmentation fault for on
  arm-linux-gnueabihf with binutils trunk and gcc-9 branch
  Resolved, worksforme.



  reply	other threads:[~2021-02-26 23:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10 12:06 Mark Wielaard
2021-02-11  9:15 ` Tom de Vries
2021-02-12 10:08   ` Mark Wielaard
2021-02-19  1:16     ` Mark Wielaard
2021-02-26 23:37       ` Mark Wielaard [this message]
2021-03-01 10:49         ` tdevries
2021-03-01 11:17           ` Mark Wielaard
2021-03-01 12:40             ` Tom de Vries
2021-03-05  7:26           ` Tom de Vries
2021-03-05 16:24             ` Tom de Vries
2021-03-08  7:14               ` Tom de Vries
2021-03-08  7:22                 ` Mark Wielaard

Reply instructions:

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).