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

Hi Tom,

On Fri, Feb 12, 2021 at 11:08:42AM +0100, Mark Wielaard wrote:
> > > I haven't really investigated why that is. But we can always say
> > > that ODR support is experimental and doesn't yet work for DWARF5.
> > 
> > I can't reproduce this, can you open an PR with more details?
> Let me know if you need any test binaries and I'll attach them to the
> bug.

So, this was fixed already. And we found some subtle other bugs.

> > Anyway, odr will be experimental.  It still need to marked as such.
> Also opened a bug for that:
> And another to document the status of DWARF 5:
> I'll resolve that by updating dwz.1 with an overview of the current
> support for DWARF 5 in dwz.

I just pushed a patch for this.

> > Furthermore, I still need to go through the PR list and clean up.
> We have about 50 open bugs. I can go through them and see if any of
> them is a showstopper/regression since 0.13, but given that various
> distros have switched to current git trunk already I think what we have
> now is consistently better than 0.13. What would be the most convenient
> to mark up the bugs?

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



  reply	other threads:[~2021-02-19  1:17 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 [this message]
2021-02-26 23:37       ` Mark Wielaard
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).