Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)

Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)

[Joel Brobecker]

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

Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)

[Tom de Vries]

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

Re: Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14)

[Sergio Durigan Junior]

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/

[8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[Tom de Vries]

[ 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

[PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[Tom de Vries]

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

Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[Sergio Durigan Junior]

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/

Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[Joel Brobecker]

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

Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)

[Tom de Vries]

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