Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Tom de Vries <tdevries@suse.de>
Cc: Joel Brobecker <brobecker@adacore.com>,  gdb-patches@sourceware.org
Subject: Re: [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
Date: Wed, 04 Sep 2019 16:43:00 -0000	[thread overview]
Message-ID: <87r24wt3ki.fsf@redhat.com> (raw)
In-Reply-To: <31f1ccbe-535f-1f69-9ba8-e51a9a8e8a12@suse.de> (Tom de Vries's	message of "Wed, 4 Sep 2019 10:19:12 +0200")

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/


  reply	other threads:[~2019-09-04 16:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-14 17:52 Updates on GDB 8.3.1 and GDB 9 releases (2019-07-14) Joel Brobecker
     [not found] ` <f08a7376-90dc-8561-4e83-7f65b831fdd9@suse.de>
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 [this message]
2019-09-09 20:53           ` Joel Brobecker
2019-09-11 20:11             ` Tom de Vries

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r24wt3ki.fsf@redhat.com \
    --to=sergiodj@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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