This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Tom de Vries <tdevries at suse dot de>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Mon, 12 Aug 2019 17:44:16 -0400
- Subject: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)
- References: <20190714175240.GA23822@adacore.com> <f08a7376-90dc-8561-4e83-7f65b831fdd9@suse.de>
On Tuesday, July 16 2019, Tom de Vries wrote:
> On 14-07-19 19:52, Joel Brobecker wrote:
>> Hi Everyone,
>>
>> It's been a couple months since we released 8.3 already. Our typical
>> schedule would be to try to create the corrective release ("re-spin")
>> in about a month from now. Given that...
>> - So far, there is only been one fix pushed to the branch since
>> the release; and
>> - that a month from now is mid-Aug, which is holiday time for many;
>> ... I purpose we don't do anything until end of Aug...
>>
>> Depending on when we'd like to have GDB 9 come out, we might even
>> want to skip 8.3.1 entirely? Personally, I don't mind spending the couple
>> of hours it takes to create a new release, even if it's for a couple
>> of patches. But perhaps there'll be more by then too.
>>
>
> I ran a comparison of trunk and 8.3 branch for x86_64 -m32, and got:
> ...
> $ diff -u <(grep ^FAIL: 8.3.m32/gdb.sum| sort) <(grep ^FAIL:
> trunk.m32/gdb.sum|sort) | grep '^\-'
> --- /dev/fd/63 2019-07-16 12:00:21.372197815 +0200
> -FAIL: gdb.base/catch-load.exp: plain unload: continue
> -FAIL: gdb.base/catch-load.exp: rx unload: continue
> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #7
> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #8
> -FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: print
> $_probe_arg1 for probe ps
> -FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: print
> $_probe_arg1 for probe ps
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile2
> -FAIL: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
> resolved: breakpoint on pendfunc3 pending again
> -FAIL: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
> resolved: (timeout)
> -FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
> ...
>
> The stap-probe.exp fix looks like 7d7571f0c1 "Adjust i386 registers on
> SystemTap probes' arguments (PR breakpoints/24541)".
>
> If bisected the base/info-shared.exp fix to the same commit (which I did
> not expect).
This is because GDB uses SystemTap probes behind the scenes to deal with
the linker-debugger interface. I don't have the logs here, but I'd
guess there's something nasty going on because of the -m32 stap bug...
> So I wonder if this commit is a good candidate to backport.
I'd say so. The commit is simple enough, hasn't caused any regressions
so far, and fixes a decent number of failures on -m32.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/