* Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)
@ 2019-07-14 17:52 Joel Brobecker
2019-07-16 13:02 ` Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Joel Brobecker @ 2019-07-14 17:52 UTC (permalink / raw)
To: gdb-patches
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.
Now, switching our attention to GDB 9, looking at the GDB/NEWS file,
there isn't anything super major, but the list is a good size already,
so I think we can start the process anytime that makes sense for us.
For instance, what if we started the stabilization process early
September, with a few to branch sometime around early to mid September.
With that plan, we can hopefully have branching by the GNU Cauldron,
and a release within a month of that, which places the release around
early to mid Oct. That's roughly 5 months after the 8.3 release.
Thoughts?
--
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)
2019-07-14 17:52 Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) Joel Brobecker
@ 2019-07-16 13:02 ` Tom de Vries
2019-08-12 21:44 ` Sergio Durigan Junior
0 siblings, 1 reply; 8+ messages in thread
From: Tom de Vries @ 2019-07-16 13:02 UTC (permalink / raw)
To: Joel Brobecker, gdb-patches, Sergio Durigan Junior
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).
So I wonder if this commit is a good candidate to backport.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)
2019-07-16 13:02 ` Tom de Vries
@ 2019-08-12 21:44 ` Sergio Durigan Junior
2019-08-21 9:11 ` [8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Sergio Durigan Junior @ 2019-08-12 21:44 UTC (permalink / raw)
To: Tom de Vries; +Cc: Joel Brobecker, gdb-patches
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/
^ permalink raw reply [flat|nested] 8+ messages in thread* [8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
2019-08-12 21:44 ` Sergio Durigan Junior
@ 2019-08-21 9:11 ` Tom de Vries
2019-09-04 8:19 ` [PING][8.3 " Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Tom de Vries @ 2019-08-21 9:11 UTC (permalink / raw)
To: Sergio Durigan Junior; +Cc: Joel Brobecker, gdb-patches
[ was: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) ]
On 12-08-19 23:44, Sergio Durigan Junior wrote:
> On Tuesday, July 16 2019, Tom de Vries wrote:
>> 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.
The patch does not apply cleanly on gdb-8.3-branch, but it does if I
first apply commit 677052f2a5 (Make
stap-probe.c:stap_parse_register_operand's "regname" an std::string).
I've tested the two commits on top of gdb-8.3-branch for x86_64-linux
with unix/-m32 target board.
No regression, and these progressions:
...
-FAIL: gdb.base/catch-load.exp: plain unload: continue
+PASS: gdb.base/catch-load.exp: plain unload: continue
-FAIL: gdb.base/catch-load.exp: rx unload: continue
+PASS: gdb.base/catch-load.exp: rx unload: continue
-FAIL: gdb.base/info-shared.exp: info sharedlibrary #7
+PASS: gdb.base/info-shared.exp: info sharedlibrary #7
-FAIL: gdb.base/info-shared.exp: info sharedlibrary #8
+PASS: gdb.base/info-shared.exp: info sharedlibrary #8
-FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check
$_probe_arg1 for probe m4
+PASS: gdb.base/stap-probe.exp: without semaphore, not optimized: check
$_probe_arg1 for probe m4
-FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check
$_probe_arg1 for probe m4
+PASS: gdb.base/stap-probe.exp: with semaphore, not optimized: check
$_probe_arg1 for probe m4
-FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check
$_probe_arg1 for probe m4
+PASS: 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
+PASS: gdb.base/stap-probe.exp: without semaphore, optimized: print
$_probe_arg1 for probe ps
-FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check
$_probe_arg1 for probe m4
+PASS: 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
+PASS: gdb.base/stap-probe.exp: with semaphore, optimized: print
$_probe_arg1 for probe ps
-FAIL: gdb.base/unload.exp: continuing to unloaded libfile
+PASS: gdb.base/unload.exp: continuing to unloaded libfile
-FAIL: gdb.base/unload.exp: continuing to unloaded libfile
+PASS: gdb.base/unload.exp: continuing to unloaded libfile
-FAIL: gdb.base/unload.exp: continuing to unloaded libfile2
+PASS: 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)
+PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
resolved: breakpoint on pendfunc3 pending again
+PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
resolved:
-FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
+PASS: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
-# of expected passes 65957
-# of unexpected failures 235
+# of expected passes 65973
+# of unexpected failures 219
...
OK to backport both commits to gdb-8.3-branch?
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
2019-08-21 9:11 ` [8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) Tom de Vries
@ 2019-09-04 8:19 ` Tom de Vries
2019-09-04 16:43 ` Sergio Durigan Junior
0 siblings, 1 reply; 8+ messages in thread
From: Tom de Vries @ 2019-09-04 8:19 UTC (permalink / raw)
To: Sergio Durigan Junior; +Cc: Joel Brobecker, gdb-patches
On 21-08-19 11:11, Tom de Vries wrote:
> [ was: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) ]
>
> On 12-08-19 23:44, Sergio Durigan Junior wrote:
>> On Tuesday, July 16 2019, Tom de Vries wrote:
>
>>> 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.
>
> The patch does not apply cleanly on gdb-8.3-branch, but it does if I
> first apply commit 677052f2a5 (Make
> stap-probe.c:stap_parse_register_operand's "regname" an std::string).
>
> I've tested the two commits on top of gdb-8.3-branch for x86_64-linux
> with unix/-m32 target board.
>
> No regression, and these progressions:
> ...
> -FAIL: gdb.base/catch-load.exp: plain unload: continue
> +PASS: gdb.base/catch-load.exp: plain unload: continue
> -FAIL: gdb.base/catch-load.exp: rx unload: continue
> +PASS: gdb.base/catch-load.exp: rx unload: continue
> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #7
> +PASS: gdb.base/info-shared.exp: info sharedlibrary #7
> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #8
> +PASS: gdb.base/info-shared.exp: info sharedlibrary #8
> -FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check
> $_probe_arg1 for probe m4
> +PASS: gdb.base/stap-probe.exp: without semaphore, not optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check
> $_probe_arg1 for probe m4
> +PASS: gdb.base/stap-probe.exp: with semaphore, not optimized: check
> $_probe_arg1 for probe m4
> -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check
> $_probe_arg1 for probe m4
> +PASS: 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
> +PASS: gdb.base/stap-probe.exp: without semaphore, optimized: print
> $_probe_arg1 for probe ps
> -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check
> $_probe_arg1 for probe m4
> +PASS: 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
> +PASS: gdb.base/stap-probe.exp: with semaphore, optimized: print
> $_probe_arg1 for probe ps
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
> +PASS: gdb.base/unload.exp: continuing to unloaded libfile
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
> +PASS: gdb.base/unload.exp: continuing to unloaded libfile
> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile2
> +PASS: 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)
> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
> resolved: breakpoint on pendfunc3 pending again
> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
> resolved:
> -FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
> +PASS: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
> -# of expected passes 65957
> -# of unexpected failures 235
> +# of expected passes 65973
> +# of unexpected failures 219
> ...
>
> OK to backport both commits to gdb-8.3-branch?
Ping.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
2019-09-04 8:19 ` [PING][8.3 " Tom de Vries
@ 2019-09-04 16:43 ` Sergio Durigan Junior
2019-09-09 20:53 ` Joel Brobecker
0 siblings, 1 reply; 8+ messages in thread
From: Sergio Durigan Junior @ 2019-09-04 16:43 UTC (permalink / raw)
To: Tom de Vries; +Cc: Joel Brobecker, gdb-patches
On Wednesday, September 04 2019, Tom de Vries wrote:
> On 21-08-19 11:11, Tom de Vries wrote:
>> [ was: Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) ]
>>
>> On 12-08-19 23:44, Sergio Durigan Junior wrote:
>>> On Tuesday, July 16 2019, Tom de Vries wrote:
>>
>>>> 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.
>>
>> The patch does not apply cleanly on gdb-8.3-branch, but it does if I
>> first apply commit 677052f2a5 (Make
>> stap-probe.c:stap_parse_register_operand's "regname" an std::string).
>>
>> I've tested the two commits on top of gdb-8.3-branch for x86_64-linux
>> with unix/-m32 target board.
>>
>> No regression, and these progressions:
>> ...
>> -FAIL: gdb.base/catch-load.exp: plain unload: continue
>> +PASS: gdb.base/catch-load.exp: plain unload: continue
>> -FAIL: gdb.base/catch-load.exp: rx unload: continue
>> +PASS: gdb.base/catch-load.exp: rx unload: continue
>> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #7
>> +PASS: gdb.base/info-shared.exp: info sharedlibrary #7
>> -FAIL: gdb.base/info-shared.exp: info sharedlibrary #8
>> +PASS: gdb.base/info-shared.exp: info sharedlibrary #8
>> -FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: check
>> $_probe_arg1 for probe m4
>> +PASS: gdb.base/stap-probe.exp: without semaphore, not optimized: check
>> $_probe_arg1 for probe m4
>> -FAIL: gdb.base/stap-probe.exp: with semaphore, not optimized: check
>> $_probe_arg1 for probe m4
>> +PASS: gdb.base/stap-probe.exp: with semaphore, not optimized: check
>> $_probe_arg1 for probe m4
>> -FAIL: gdb.base/stap-probe.exp: without semaphore, optimized: check
>> $_probe_arg1 for probe m4
>> +PASS: 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
>> +PASS: gdb.base/stap-probe.exp: without semaphore, optimized: print
>> $_probe_arg1 for probe ps
>> -FAIL: gdb.base/stap-probe.exp: with semaphore, optimized: check
>> $_probe_arg1 for probe m4
>> +PASS: 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
>> +PASS: gdb.base/stap-probe.exp: with semaphore, optimized: print
>> $_probe_arg1 for probe ps
>> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
>> +PASS: gdb.base/unload.exp: continuing to unloaded libfile
>> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile
>> +PASS: gdb.base/unload.exp: continuing to unloaded libfile
>> -FAIL: gdb.base/unload.exp: continuing to unloaded libfile2
>> +PASS: 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)
>> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
>> resolved: breakpoint on pendfunc3 pending again
>> +PASS: gdb.mi/mi-breakpoint-changed.exp: test_pending_resolved: pending
>> resolved:
>> -FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
>> +PASS: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
>> -# of expected passes 65957
>> -# of unexpected failures 235
>> +# of expected passes 65973
>> +# of unexpected failures 219
>> ...
>>
>> OK to backport both commits to gdb-8.3-branch?
>
> Ping.
I'm the maintainer of the SystemTap/generic probe interfaces, but I'm
not sure I can give you the green light for you in this case, because
it's about backporting to a branch. In any case, just to make sure I'm
clear: this one LGTM.
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
2019-09-04 16:43 ` Sergio Durigan Junior
@ 2019-09-09 20:53 ` Joel Brobecker
2019-09-11 20:11 ` Tom de Vries
0 siblings, 1 reply; 8+ messages in thread
From: Joel Brobecker @ 2019-09-09 20:53 UTC (permalink / raw)
To: Sergio Durigan Junior; +Cc: Tom de Vries, gdb-patches
> >> OK to backport both commits to gdb-8.3-branch?
> >
> > Ping.
>
> I'm the maintainer of the SystemTap/generic probe interfaces, but I'm
> not sure I can give you the green light for you in this case, because
> it's about backporting to a branch. In any case, just to make sure I'm
> clear: this one LGTM.
Generally speaking, the rule is that a GM needs to approve the backport.
But the nod from the associated maintainer is always a great help.
So thanks a lot, Sergio!
I looked it over, and this seems safe to have. So the backport is
approved.
One thing that would have helped a bit is if the commits were attached
to the request. It's clearly not a big issue at all, but if they had
been attached, there would have been no mistake possible fo which
commits we are talking about, and looking through them would have been
faster.
For the record, I looked at:
677052f2a5 Make stap-probe.c:stap_parse_register_operand's "regname" an std::string
7d7571f0c1 Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
--
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
2019-09-09 20:53 ` Joel Brobecker
@ 2019-09-11 20:11 ` Tom de Vries
0 siblings, 0 replies; 8+ messages in thread
From: Tom de Vries @ 2019-09-11 20:11 UTC (permalink / raw)
To: Joel Brobecker, Sergio Durigan Junior; +Cc: gdb-patches
On 09-09-19 22:53, Joel Brobecker wrote:
>>>> OK to backport both commits to gdb-8.3-branch?
>>>
>>> Ping.
>>
>> I'm the maintainer of the SystemTap/generic probe interfaces, but I'm
>> not sure I can give you the green light for you in this case, because
>> it's about backporting to a branch. In any case, just to make sure I'm
>> clear: this one LGTM.
>
> Generally speaking, the rule is that a GM needs to approve the backport.
> But the nod from the associated maintainer is always a great help.
> So thanks a lot, Sergio!
>
> I looked it over, and this seems safe to have. So the backport is
> approved.
>
Thanks for the review.
> One thing that would have helped a bit is if the commits were attached
> to the request. It's clearly not a big issue at all, but if they had
> been attached, there would have been no mistake possible fo which
> commits we are talking about, and looking through them would have been
> faster.
>
Ack, I'll try to remember this for next time.
Thanks,
- Tom
> For the record, I looked at:
> 677052f2a5 Make stap-probe.c:stap_parse_register_operand's "regname" an std::string
> 7d7571f0c1 Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-09-11 20:11 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-14 17:52 Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) Joel Brobecker
2019-07-16 13:02 ` Tom de Vries
2019-08-12 21:44 ` Sergio Durigan Junior
2019-08-21 9:11 ` [8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) Tom de Vries
2019-09-04 8:19 ` [PING][8.3 " Tom de Vries
2019-09-04 16:43 ` Sergio Durigan Junior
2019-09-09 20:53 ` Joel Brobecker
2019-09-11 20:11 ` Tom de Vries
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).