From: Tom de Vries <tdevries@suse.de>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
Subject: [8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541)
Date: Wed, 21 Aug 2019 09:11:00 -0000 [thread overview]
Message-ID: <2b220c6a-e212-65b0-e6e6-f668602179c6@suse.de> (raw)
In-Reply-To: <877e7i3vpr.fsf@redhat.com>
[ 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
next prev parent reply other threads:[~2019-08-21 9:11 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 ` Tom de Vries [this message]
2019-09-04 8:19 ` [PING][8.3 backport] Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) 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
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=2b220c6a-e212-65b0-e6e6-f668602179c6@suse.de \
--to=tdevries@suse.de \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@redhat.com \
/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