public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/26989] New: FAIL: gdb.arch/i386-mpx-call.exp: check whether processor supports MPX
@ 2020-12-01 11:56 vries at gcc dot gnu.org
2020-12-04 17:23 ` [Bug testsuite/26989] " vries at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-01 11:56 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26989
Bug ID: 26989
Summary: FAIL: gdb.arch/i386-mpx-call.exp: check whether
processor supports MPX
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: testsuite
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
On OBS (SLE-15, x86_64, unix/-m32), I run into:
...
(gdb) print have_mpx ()^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x08048ac3 in have_mpx () at
/home/abuild/rpmbuild/BUILD/gdb-10.1/gdb/testsuite/gdb.arch/i386-mpx-call.c:30^M
30 if (!__get_cpuid (1, &eax, &ebx, &ecx, &edx))^M
The program being debugged was signaled while in a function called from GDB.^M
GDB remains in the frame where the signal was received.^M
To change this behavior use "set unwindonsignal on".^M
Evaluation of the expression containing the function^M
(have_mpx) will be abandoned.^M
When the function is done executing, GDB will silently stop.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: check whether processor supports MPX
...
The test-case is compiled with -mmpx -fcheck-pointer-bounds, which means that
the feature check have_mpx itself contains mpx insns:
...
08048a56 <have_mpx>:
8048a56: 55 push %ebp
8048a57: 89 e5 mov %esp,%ebp
8048a59: 53 push %ebx
8048a5a: 83 ec 24 sub $0x24,%esp
8048a5d: 66 0f 1a 15 58 8d 04 bndmov 0x8048d58,%bnd2
8048a64: 08
8048a65: 66 0f 1b 55 e0 bndmov %bnd2,-0x20(%ebp)
8048a6a: 8d 55 e8 lea -0x18(%ebp),%edx
8048a6d: b8 04 00 00 00 mov $0x4,%eax
8048a72: 83 e8 01 sub $0x1,%eax
8048a75: f3 0f 1b 1c 02 bndmk (%edx,%eax,1),%bnd3
8048a7a: 8d 55 ec lea -0x14(%ebp),%edx
8048a7d: b8 04 00 00 00 mov $0x4,%eax
8048a82: 83 e8 01 sub $0x1,%eax
8048a85: f3 0f 1b 14 02 bndmk (%edx,%eax,1),%bnd2
8048a8a: 8d 55 f0 lea -0x10(%ebp),%edx
8048a8d: b8 04 00 00 00 mov $0x4,%eax
8048a92: 83 e8 01 sub $0x1,%eax
8048a95: f3 0f 1b 0c 02 bndmk (%edx,%eax,1),%bnd1
8048a9a: 8d 55 f4 lea -0xc(%ebp),%edx
8048a9d: b8 04 00 00 00 mov $0x4,%eax
8048aa2: 83 e8 01 sub $0x1,%eax
8048aa5: f3 0f 1b 04 02 bndmk (%edx,%eax,1),%bnd0
8048aaa: 83 ec 20 sub $0x20,%esp
8048aad: 89 e0 mov %esp,%eax
8048aaf: 8d 55 e8 lea -0x18(%ebp),%edx
8048ab2: 89 50 10 mov %edx,0x10(%eax)
8048ab5: 8d 55 ec lea -0x14(%ebp),%edx
8048ab8: 89 50 0c mov %edx,0xc(%eax)
8048abb: 8d 55 f0 lea -0x10(%ebp),%edx
8048abe: 89 50 08 mov %edx,0x8(%eax)
8048ac1: 8d 55 f4 lea -0xc(%ebp),%edx
8048ac4: 89 50 04 mov %edx,0x4(%eax)
8048ac7: c7 00 01 00 00 00 movl $0x1,(%eax)
8048acd: 8d 50 10 lea 0x10(%eax),%edx
8048ad0: 8b 48 10 mov 0x10(%eax),%ecx
8048ad3: 0f 1b 1c 0a bndstx %bnd3,(%edx,%ecx,1)
8048ad7: 8d 50 0c lea 0xc(%eax),%edx
8048ada: 8b 48 0c mov 0xc(%eax),%ecx
8048add: 0f 1b 14 0a bndstx %bnd2,(%edx,%ecx,1)
8048ae1: 8d 50 08 lea 0x8(%eax),%edx
8048ae4: 8b 48 08 mov 0x8(%eax),%ecx
8048ae7: 0f 1b 0c 0a bndstx %bnd1,(%edx,%ecx,1)
8048aeb: 8d 50 04 lea 0x4(%eax),%edx
8048aee: 8b 48 04 mov 0x4(%eax),%ecx
8048af1: 0f 1b 04 0a bndstx %bnd0,(%edx,%ecx,1)
8048af5: f2 e8 9a 00 00 00 bnd call 8048b95 <__get_cpuid>
8048afb: 83 c4 20 add $0x20,%esp
8048afe: 85 c0 test %eax,%eax
8048b00: f2 75 0b bnd jne 8048b0e <have_mpx+0xb8>
8048b03: b8 00 00 00 00 mov $0x0,%eax
8048b08: f2 e9 81 00 00 00 bnd jmp 8048b8f <have_mpx+0x139>
8048b0e: 8b 45 ec mov -0x14(%ebp),%eax
8048b11: 25 00 00 00 08 and $0x8000000,%eax
8048b16: 85 c0 test %eax,%eax
8048b18: f2 74 6f bnd je 8048b8a <have_mpx+0x134>
8048b1b: 83 ec 10 sub $0x10,%esp
8048b1e: 89 e0 mov %esp,%eax
8048b20: c7 40 04 00 00 00 00 movl $0x0,0x4(%eax)
8048b27: c7 00 00 00 00 00 movl $0x0,(%eax)
8048b2d: 8d 50 04 lea 0x4(%eax),%edx
8048b30: 8b 48 04 mov 0x4(%eax),%ecx
8048b33: 66 0f 1a 5d e0 bndmov -0x20(%ebp),%bnd3
8048b38: 0f 1b 1c 0a bndstx %bnd3,(%edx,%ecx,1)
8048b3c: f2 e8 02 01 00 00 bnd call 8048c44 <__get_cpuid_max>
8048b42: 83 c4 10 add $0x10,%esp
8048b45: 83 f8 06 cmp $0x6,%eax
8048b48: f2 77 08 bnd ja 8048b53 <have_mpx+0xfd>
8048b4b: b8 00 00 00 00 mov $0x0,%eax
8048b50: f2 eb 3c bnd jmp 8048b8f <have_mpx+0x139>
8048b53: b8 07 00 00 00 mov $0x7,%eax
8048b58: ba 00 00 00 00 mov $0x0,%edx
8048b5d: 89 d1 mov %edx,%ecx
8048b5f: 0f a2 cpuid
8048b61: 89 45 f4 mov %eax,-0xc(%ebp)
8048b64: 89 5d f0 mov %ebx,-0x10(%ebp)
8048b67: 89 4d ec mov %ecx,-0x14(%ebp)
8048b6a: 89 55 e8 mov %edx,-0x18(%ebp)
8048b6d: 8b 45 f0 mov -0x10(%ebp),%eax
8048b70: 25 00 40 00 00 and $0x4000,%eax
8048b75: 85 c0 test %eax,%eax
8048b77: f2 74 08 bnd je 8048b82 <have_mpx+0x12c>
8048b7a: b8 01 00 00 00 mov $0x1,%eax
8048b7f: f2 eb 0d bnd jmp 8048b8f <have_mpx+0x139>
8048b82: b8 00 00 00 00 mov $0x0,%eax
8048b87: f2 eb 05 bnd jmp 8048b8f <have_mpx+0x139>
8048b8a: b8 00 00 00 00 mov $0x0,%eax
8048b8f: 8b 5d fc mov -0x4(%ebp),%ebx
8048b92: c9 leave
8048b93: f2 c3 bnd ret
...
The test-run with -m64 doesn't see this problem, I'm not sure why, perhaps this
is a qemu bug were's seeing there.
Either way, running code compiled with -mmpx -fcheck-pointer-bounds on a cpu
without mpx support sounds like asking for trouble. We should just have a
have_mpx test in lib/gdb.exp.
Note btw that after the FAIL, the test continues and runs into a whole bunch of
other FAILs. Only when the call to have_mpx succeeds and return 0, is the test
marked as untested, which is not very robust.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug testsuite/26989] FAIL: gdb.arch/i386-mpx-call.exp: check whether processor supports MPX
2020-12-01 11:56 [Bug testsuite/26989] New: FAIL: gdb.arch/i386-mpx-call.exp: check whether processor supports MPX vries at gcc dot gnu.org
@ 2020-12-04 17:23 ` vries at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-04 17:23 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26989
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Looks like I was wrong about my initial idea of mpx not being supported.
There are problems with running the exec as is, without gdb.
Managed to trigger this in osc chroot shell, then managed to reproduce the sme
on my laptop using:
...
$ ( ulimit -Sv 7500; ./outputs/gdb.arch/i386-mpx-call/i386-mpx-call )
...
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x8048ad3
Unexpected status with bound exception: 4157229142
Saw a #BR! status 4157229142 at 0x^C
...
So, the first bndstx instruction has the side effect of allocating part of the
Bounds Table ( see
https://community.intel.com/t5/Intel-ISA-Extensions/BNDLDX-BNDSTX-BNDSTATUS-error-2-expected-behavior/td-p/1010212?profile.language=es
), and if there's not enough memory we end up trouble. When running this gdb,
we end up apparently with a sigsegv.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-12-04 17:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-01 11:56 [Bug testsuite/26989] New: FAIL: gdb.arch/i386-mpx-call.exp: check whether processor supports MPX vries at gcc dot gnu.org
2020-12-04 17:23 ` [Bug testsuite/26989] " vries at gcc dot gnu.org
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).