Hi, I was wondering what we still need to do to get a 0.14 release out? It would be nice to release now that we support DWARF5 as GCC11 outputs it by default now. There are some DWARF5 constructs we still don't support, but they aren't really required because they are non-default. The only real issue is the combination of DWARF5 and dwz --odr. We see the following failures in the testsuite: There are still failures with the ODR support when building the testcases with -gdwarf-5, specifically: FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh 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. Cheers, Mark
On 2/10/21 1:06 PM, Mark Wielaard wrote:
> Hi,
>
> I was wondering what we still need to do to get a 0.14 release out?
> It would be nice to release now that we support DWARF5 as GCC11 outputs
> it by default now. There are some DWARF5 constructs we still don't
> support, but they aren't really required because they are non-default.
>
> The only real issue is the combination of DWARF5 and dwz --odr. We see
> the following failures in the testsuite:
>
> There are still failures with the ODR support when building the
> testcases with -gdwarf-5, specifically:
>
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh
>
> 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?
Anyway, odr will be experimental. It still need to marked as such.
Furthermore, I still need to go through the PR list and clean up.
Thanks,
- Tom
Hi Tom, On Thu, 2021-02-11 at 10:15 +0100, Tom de Vries wrote: > On 2/10/21 1:06 PM, Mark Wielaard wrote: > > The only real issue is the combination of DWARF5 and dwz --odr. We > > see the following failures in the testsuite: > > > > There are still failures with the ODR support when building the > > testcases with -gdwarf-5, specifically: > > > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh > > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh > > > > 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? https://sourceware.org/bugzilla/show_bug.cgi?id=27400 Let me know if you need any test binaries and I'll attach them to the bug. > Anyway, odr will be experimental. It still need to marked as such. Also opened a bug for that: https://sourceware.org/bugzilla/show_bug.cgi?id=27401 And another to document the status of DWARF 5: https://sourceware.org/bugzilla/show_bug.cgi?id=27402 I'll resolve that by updating dwz.1 with an overview of the current support for DWARF 5 in dwz. > 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? Thanks, Mark
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? > > https://sourceware.org/bugzilla/show_bug.cgi?id=27400 > 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: > https://sourceware.org/bugzilla/show_bug.cgi?id=27401 > > And another to document the status of DWARF 5: > https://sourceware.org/bugzilla/show_bug.cgi?id=27402 > > 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. https://sourceware.org/bugzilla/show_bug.cgi?id=26252 [odr] dwz.c:11404: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed. #2 For which you just posted a patch. https://sourceware.org/bugzilla/show_bug.cgi?id=24275 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. https://sourceware.org/bugzilla/show_bug.cgi?id=27401 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?) https://sourceware.org/bugzilla/show_bug.cgi?id=27363 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." https://sourceware.org/bugzilla/show_bug.cgi?id=25252 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. https://sourceware.org/bugzilla/show_bug.cgi?id=25459 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. Cheers, Mark
Hi, 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. > > https://sourceware.org/bugzilla/show_bug.cgi?id=26252 > [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". > https://sourceware.org/bugzilla/show_bug.cgi?id=24275 > 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. > https://sourceware.org/bugzilla/show_bug.cgi?id=27401 > 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: https://sourceware.org/pipermail/dwz/2021q1/000980.html > https://sourceware.org/bugzilla/show_bug.cgi?id=27363 > 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. > https://sourceware.org/bugzilla/show_bug.cgi?id=25252 > 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. > https://sourceware.org/bugzilla/show_bug.cgi?id=25459 > 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: - https://sourceware.org/bugzilla/show_bug.cgi?id=27449 dwz: 1: Unknown DWARF DW_OP_0 Thanks to the new diagnostics tracked down to possible GCC bug. - https://sourceware.org/bugzilla/show_bug.cgi?id=27463 [dwz] Unhandled DW_FORM_sdata for DW_AT_decl_line Filed and fixed. - https://sourceware.org/bugzilla/show_bug.cgi?id=27474 [dwz] Report unknown dwarf problem only once Another request for better error diagnostics - https://sourceware.org/bugzilla/show_bug.cgi?id=27438 [dwz, odr, multifile] Multifile after odr not optimal Filed and fixed - https://sourceware.org/bugzilla/show_bug.cgi?id=25398 [dwz, fixed-needs-testcase] CU referenced from PU Patch posted, needs review: https://sourceware.org/pipermail/dwz/2021q1/000976.html - https://sourceware.org/bugzilla/show_bug.cgi?id=25424 CU referenced from PU (--odr-mode=link case) Patch posted, needs review: https://sourceware.org/pipermail/dwz/2021q1/000974.html - https://sourceware.org/bugzilla/show_bug.cgi?id=27464 CU referenced from PU (--odr-mode=link case) (bis) Patch posted, needs, review: https://sourceware.org/pipermail/dwz/2021q1/000975.html - https://sourceware.org/bugzilla/show_bug.cgi?id=27466 [dwz] Improve heuristics for odr New enhancement bug - https://sourceware.org/bugzilla/show_bug.cgi?id=27429 [dwz, testsuite] mode 4 in checksum_ref_die not exercised in test-suite Patch posted, needs review: https://sourceware.org/pipermail/dwz/2021q1/000957.html - https://sourceware.org/bugzilla/show_bug.cgi?id=27440 [dwz, dwarf5] Add --dwarf-5 flag to generate .debug_sup, ref_sup and strp_sup Implemented - https://sourceware.org/bugzilla/show_bug.cgi?id=24978 [dwz] Segmentation fault for two-files-too-many-dies-2.sh on arm-linux-gnueabihf with binutils trunk and gcc-9 branch Resolved, worksforme. Cheers, Mark
On 2021-02-27 00:37, Mark Wielaard wrote: > Hi, > > 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. > I'd like to postpone by a week. I've cleaned up odr state, and now I'd like to spent some time on other issues. In particular, I'd like to fix the temp file thingy. Thanks, - Tom > 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. >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=26252 >> [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". > >> https://sourceware.org/bugzilla/show_bug.cgi?id=24275 >> 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. > >> https://sourceware.org/bugzilla/show_bug.cgi?id=27401 >> 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: > https://sourceware.org/pipermail/dwz/2021q1/000980.html > >> https://sourceware.org/bugzilla/show_bug.cgi?id=27363 >> 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. > >> https://sourceware.org/bugzilla/show_bug.cgi?id=25252 >> 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. > >> https://sourceware.org/bugzilla/show_bug.cgi?id=25459 >> 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: > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27449 > dwz: 1: Unknown DWARF DW_OP_0 > Thanks to the new diagnostics tracked down to possible GCC bug. > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27463 > [dwz] Unhandled DW_FORM_sdata for DW_AT_decl_line > Filed and fixed. > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27474 > [dwz] Report unknown dwarf problem only once > Another request for better error diagnostics > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27438 > [dwz, odr, multifile] Multifile after odr not optimal > Filed and fixed > > - https://sourceware.org/bugzilla/show_bug.cgi?id=25398 > [dwz, fixed-needs-testcase] CU referenced from PU > Patch posted, needs review: > https://sourceware.org/pipermail/dwz/2021q1/000976.html > > - https://sourceware.org/bugzilla/show_bug.cgi?id=25424 > CU referenced from PU (--odr-mode=link case) > Patch posted, needs review: > https://sourceware.org/pipermail/dwz/2021q1/000974.html > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27464 > CU referenced from PU (--odr-mode=link case) (bis) > Patch posted, needs, review: > https://sourceware.org/pipermail/dwz/2021q1/000975.html > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27466 > [dwz] Improve heuristics for odr > New enhancement bug > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27429 > [dwz, testsuite] mode 4 in checksum_ref_die not exercised in > test-suite > Patch posted, needs review: > https://sourceware.org/pipermail/dwz/2021q1/000957.html > > - https://sourceware.org/bugzilla/show_bug.cgi?id=27440 > [dwz, dwarf5] Add --dwarf-5 flag to generate .debug_sup, ref_sup and > strp_sup > Implemented > > - https://sourceware.org/bugzilla/show_bug.cgi?id=24978 > [dwz] Segmentation fault for two-files-too-many-dies-2.sh on > arm-linux-gnueabihf with binutils trunk and gcc-9 branch > Resolved, worksforme. > > Cheers, > > Mark
Hi Tom,
On Mon, 2021-03-01 at 11:49 +0100, tdevries wrote:
> On 2021-02-27 00:37, Mark Wielaard wrote:
> > 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.
>
> I'd like to postpone by a week. I've cleaned up odr state, and now I'd
> like to spent some time on other issues. In particular, I'd like to fix
> the temp file thingy.
OK, but could we then pick that as a concrete goal and date for the
release please? There have been requests for a 0.14 release since
January. I did try to make sure we had up to date lists of pending bugs
and I believe there are no regressions anymore. That doesn't mean we
cannot designate some existing bugs as release critical. The temp file
thingy (PR24275) does indeed seem nasty and it would be great to get it
fixed.
So shall we say that when PR24275 is fixed and no new release critical
issues (regressions) are found by Monday March 8, then we'll do a 0.14
release?
I am a little afraid we will simply never do a release because there is
always one more thing to hack on. And the last release was in August
2019. There have been lots of bugs fixed since then and some nice new
features added.
It would be good if we did regular (say every 3 or 6 months) releases.
Just to make sure people can upgrade and get the new bug fixes and
features more regularly without having to pick arbitrary git checkouts.
Thanks,
Mark
On 3/1/21 12:17 PM, Mark Wielaard wrote: > Hi Tom, > > On Mon, 2021-03-01 at 11:49 +0100, tdevries wrote: >> On 2021-02-27 00:37, Mark Wielaard wrote: >>> 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. >> >> I'd like to postpone by a week. I've cleaned up odr state, and now I'd >> like to spent some time on other issues. In particular, I'd like to fix >> the temp file thingy. > > OK, but could we then pick that as a concrete goal and date for the > release please? Sure. > There have been requests for a 0.14 release since > January. Ahem... for much longer actually ;) > I did try to make sure we had up to date lists of pending bugs > and I believe there are no regressions anymore. That doesn't mean we > cannot designate some existing bugs as release critical. The temp file > thingy (PR24275) does indeed seem nasty and it would be great to get it > fixed. Yeah, it still gets reported by package maintainers, so I'd really like to fix this. I already have a tentative patch (on top of trunk). > So shall we say that when PR24275 is fixed and no new release critical > issues (regressions) are found by Monday March 8, then we'll do a 0.14 > release? > Sounds good. > I am a little afraid we will simply never do a release because there is > always one more thing to hack on. And the last release was in August > 2019. There have been lots of bugs fixed since then and some nice new > features added. > I agree that it's good to do a release now-ish. I also expect to run out of dwz-hack-time in a week, so I'm not so afraid of the keep-hacking scenario. > It would be good if we did regular (say every 3 or 6 months) releases. > Just to make sure people can upgrade and get the new bug fixes and > features more regularly without having to pick arbitrary git checkouts. Agreed, regular release are good (though dwz hacking has tended to happen in rare bursts, so it may not always make sense). Anyway, I intended to do a release long ago, but got all tied up in the odr stuff instead. So thanks for driving this, much appreciated :) Thanks, - Tom
On 3/1/21 11:49 AM, tdevries wrote:
> On 2021-02-27 00:37, Mark Wielaard wrote:
>> Hi,
>>
>> 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.
>>
>
> I'd like to postpone by a week. I've cleaned up odr state, and now I'd
> like to spent some time on other issues. In particular, I'd like to fix
> the temp file thingy.
>
That's fixed now.
I've done some more bugzilla enhancement marking, now the only
non-enhancement open PRs are:
- PR24441 - Some crashes found by fuzzing
- PR25459 - Forward pseudo-reference triggers error
AFAIC, from the open PR perspective, we're good for the release.
I'll do one more round of gdb testing against dwz, and then hopefully we
can release on Monday.
Thanks,
- Tom
On 3/5/21 8:26 AM, Tom de Vries wrote:
> On 3/1/21 11:49 AM, tdevries wrote:
>> On 2021-02-27 00:37, Mark Wielaard wrote:
>>> Hi,
>>>
>>> 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.
>>>
>>
>> I'd like to postpone by a week. I've cleaned up odr state, and now I'd
>> like to spent some time on other issues. In particular, I'd like to fix
>> the temp file thingy.
>>
>
> That's fixed now.
>
> I've done some more bugzilla enhancement marking, now the only
> non-enhancement open PRs are:
> - PR24441 - Some crashes found by fuzzing
> - PR25459 - Forward pseudo-reference triggers error
>
> AFAIC, from the open PR perspective, we're good for the release.
>
> I'll do one more round of gdb testing against dwz, and then hopefully we
> can release on Monday.
That's done, I've tested against both target boards cc-with-dwz and
cc-with-dwz-m. No regressions found.
Thanks,
- Tom
On 3/5/21 5:24 PM, Tom de Vries wrote:
> On 3/5/21 8:26 AM, Tom de Vries wrote:
>> On 3/1/21 11:49 AM, tdevries wrote:
>>> On 2021-02-27 00:37, Mark Wielaard wrote:
>>>> Hi,
>>>>
>>>> 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.
>>>>
>>>
>>> I'd like to postpone by a week. I've cleaned up odr state, and now I'd
>>> like to spent some time on other issues. In particular, I'd like to fix
>>> the temp file thingy.
>>>
>>
>> That's fixed now.
>>
>> I've done some more bugzilla enhancement marking, now the only
>> non-enhancement open PRs are:
>> - PR24441 - Some crashes found by fuzzing
>> - PR25459 - Forward pseudo-reference triggers error
>>
>> AFAIC, from the open PR perspective, we're good for the release.
>>
>> I'll do one more round of gdb testing against dwz, and then hopefully we
>> can release on Monday.
>
> That's done, I've tested against both target boards cc-with-dwz and
> cc-with-dwz-m. No regressions found.
I've done a review of copyright in the toplevel files. AFAICT, that
looks good.
I can do the release (that is, running the scripts in contrib/release/*
and drafting release announcement). OK, or does anybody else want to do
that?
Thanks,
- Tom
Hi Tom, Tom de Vries wrote: > On 3/5/21 5:24 PM, Tom de Vries wrote: >> On 3/5/21 8:26 AM, Tom de Vries wrote: >>> AFAIC, from the open PR perspective, we're good for the release. >>> >>> I'll do one more round of gdb testing against dwz, and then hopefully we >>> can release on Monday. >> >> That's done, I've tested against both target boards cc-with-dwz and >> cc-with-dwz-m. No regressions found. > > I've done a review of copyright in the toplevel files. AFAICT, that > looks good. Things look good for a release. > I can do the release (that is, running the scripts in contrib/release/* > and drafting release announcement). OK, or does anybody else want to do > that? Whatever is most convenient for you. If you like me to do it just ask. Thanks, Mark