[Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

            Bug ID: 26991
           Summary: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue
                    to a bnd violation
           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: ---

When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
I get:
...
Running
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.arch/i386-mpx-call.exp ...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: continue to a bnd violation (the
program exited)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndstatus compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndstatus compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndcfgu should not
change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndstatus should not
change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndcfgu compare before
and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndstatus compare
before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: continue to a bnd
violation (the program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: access only one
position
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: return from the fault
...

In more detail:
...
(gdb) PASS: gdb.arch/i386-mpx-call.exp: upper_bnd0: bndstatus compare before
and after
continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
p (((void *)$_siginfo._sifields._sigfault.si_addr - (void*)a))/sizeof(int) ==
1^M
$23 = 0^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: access only one position
return^M
#0  0xf7ce5e63 in __libc_start_main () from /lib/libc.so.6^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: return from the fault
....

So, for some reason the bnd violation fail to trigger, and we run to the end of
the inferior call.

When we then call return to return from the fault, we actually return from
main, and after that a lot of FAILs are generated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
With this tentative patch:
...
diff --git a/gdb/testsuite/gdb.arch/i386-mpx-call.exp
b/gdb/testsuite/gdb.arch/i386-mpx-cal
l.exp
index 41abbeebcf..5347eaecc2 100644
--- a/gdb/testsuite/gdb.arch/i386-mpx-call.exp
+++ b/gdb/testsuite/gdb.arch/i386-mpx-call.exp
@@ -138,7 +138,17 @@ proc check_bound_violation {parm parm_type is_positive} {

     global u_fault

-    gdb_test "continue" "$u_fault.*" "continue to a bnd violation"
+    set have_violation 0
+    gdb_test_multiple "continue" "continue to a bnd violation" {
+       -wrap -re "$u_fault.*" {
+           set have_violation 1
+           pass $gdb_test_name
+       }
+    }
+
+    if { ! $have_violation } {
+       return
+    }

     set message "access only one position"
     if {$is_positive == 1} {
...
we have instead just:
...
Running
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.arch/i386-mpx-call.exp ...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: continue to a bnd
violation

                === gdb Summary ===

# of expected passes            137
# of unexpected failures        11
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
As for the remaining failure.

Things are made complicated by the fact that bnd0.lbound and bnd0.ubound are
represented as 32-bit in -m32, while in the hardware they're actually 64-bit.

This is reflected in the types:
...
(gdb) ptype $bnd0
type = struct builtin_type_bound128 {
    void *lbound;
    void *ubound;
}
(gdb) ptype $bnd0raw
type = struct br128 {
    uint64_t lbound;
    uint64_t ubound_raw;
}
...

So, the interesting thing is always to print the raw value to see what's
actually written in the hw register.

So, before the FAIL we have:
...
(gdb) p /x $bnd0.lbound = $bnd0.ubound^M
$19 = 0xffffffff^M
(gdb) p /x $bnd0.ubound = 0^M
$20 = 0x0^M
(gdb) p /x $bnd0raw^M
$21 = {lbound = 0xffffffff, ubound_raw = 0xffffffffffffffff}^M
...

Now comparing that with the info found here (
https://www.felixcloutier.com/x86/bndmk ):
...
BND.LB ← SRCMEM.base;
IF 64-bit mode Then
    BND.UB ← NOT(LEA.64_bits(SRCMEM));
ELSE
    BND.UB ← Zero_Extend.64_bits(NOT(LEA.32_bits(SRCMEM)));
FI;
...
we can see that the value written into ubound_raw is not congruent with how
bndmk would write it.

Using this tentative patch:
...
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 00de4e1ccb..2ea28c68bd 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -3527,6 +3527,8 @@ i386_pseudo_register_write 
                              raw_buf);

          upper = ~upper;
+         if (size == 4)
+           upper = upper & 0xffffffff;

          /* Set register bits.  */
          memcpy (raw_buf, &lower, 8);
...
fixes that, but not the FAIL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
The mechanism of the test (as demonstrated on -m64) is as follows:
- use -mmpx -fcheck-pointer-bounds to generate pointer checks in the exec
- run the exec to after all mallocs are done, such that all variables are valid
- do inferior calls, similar to those already in the program
- a peculiarity about inferior calls is that the bounds (that is, the registers
  bnd0-3) are reset at the start of the call, see amd64_push_dummy_call
- first two inferior calls are done (default_run and verify_default_values,
where
  the memory access are done with the bounds registers set by 
  amd64_push_dummy_call to all-allowed
- then we try to do an inferior call with modified bounds registers.
  In order to do that, we set a breakpoint at *function before doing the
inferior
  call.  Once we hit the breakpoint during the inferior call, the bounds
  registers are set to none-allowed, and we continue expecting to run into an
  bounds check sigsegv.

This doesn't work for -m32 because the abi seems different.

For -m64 we have before a regular call the bnd regs setup like this:
...
(gdb) p $bnd0
$5 = {lbound = 0x7fffffffdb70, ubound = 0x7fffffffdb83} : size 20
(gdb) p &sa
$7 = (int (*)[5]) 0x7fffffffdb70
...
by this code:
...
      *x = upper (sa, sb, sc, sd, 0);  /* bkpt 1.  */
  4006ef:       48 8d 8d 60 ff ff ff    lea    -0xa0(%rbp),%rcx
  4006f6:       48 8d 55 80             lea    -0x80(%rbp),%rdx
  4006fa:       48 8d 75 a0             lea    -0x60(%rbp),%rsi
  4006fe:       48 8d 45 c0             lea    -0x40(%rbp),%rax
  400702:       41 b8 00 00 00 00       mov    $0x0,%r8d
  400708:       66 0f 1a 9d f0 fe ff    bndmov -0x110(%rbp),%bnd3
  40070f:       ff
  400710:       66 0f 1a 95 00 ff ff    bndmov -0x100(%rbp),%bnd2
  400717:       ff
  400718:       66 0f 1a 8d 10 ff ff    bndmov -0xf0(%rbp),%bnd1
  40071f:       ff
  400720:       66 0f 1a 85 20 ff ff    bndmov -0xe0(%rbp),%bnd0
  400727:       ff
  400728:       48 89 c7                mov    %rax,%rdi
  40072b:       f2 e8 bb 02 00 00       bnd callq 4009ec <upper>
...

But for -m32, we have instead this (the &sa address is in bnd3, but that's just
used as temporary):
...
(gdb) p $bnd0
$1 = {lbound = 0x804c1e0, ubound = 0x804c1f3} : size 20
(gdb) p &sa
$2 = (int (*)[5]) 0xffffcdf4
(gdb) p $bnd1
$3 = {lbound = 0xffffcde0, ubound = 0xffffcdf3} : size 20
(gdb) p $bnd2
$4 = {lbound = 0x804c1e0, ubound = 0x804c1f3} : size 20
(gdb) p $bnd3
$5 = {lbound = 0xffffcdf4, ubound = 0xffffce07} : size 20
...
because the bounds are passed in the bounds table:
...
      *x = upper (sa, sb, sc, sd, 0);  /* bkpt 1.  */
 80485ed:       83 ec 20                sub    $0x20,%esp
 80485f0:       89 e0                   mov    %esp,%eax
 80485f2:       c7 40 10 00 00 00 00    movl   $0x0,0x10(%eax)
 80485f9:       8d 55 90                lea    -0x70(%ebp),%edx
 80485fc:       89 50 0c                mov    %edx,0xc(%eax)
 80485ff:       8d 55 a4                lea    -0x5c(%ebp),%edx
 8048602:       89 50 08                mov    %edx,0x8(%eax)
 8048605:       8d 55 b8                lea    -0x48(%ebp),%edx
 8048608:       89 50 04                mov    %edx,0x4(%eax)
 804860b:       8d 55 cc                lea    -0x34(%ebp),%edx
 804860e:       89 10                   mov    %edx,(%eax)
 8048610:       8d 50 0c                lea    0xc(%eax),%edx
 8048613:       8b 48 0c                mov    0xc(%eax),%ecx
 8048616:       66 0f 1a 8d 58 ff ff    bndmov -0xa8(%ebp),%bnd1
 804861d:       ff
 804861e:       0f 1b 0c 0a             bndstx %bnd1,(%edx,%ecx,1)
 8048622:       8d 50 08                lea    0x8(%eax),%edx
 8048625:       8b 48 08                mov    0x8(%eax),%ecx
 8048628:       66 0f 1a 9d 60 ff ff    bndmov -0xa0(%ebp),%bnd3
 804862f:       ff
 8048630:       0f 1b 1c 0a             bndstx %bnd3,(%edx,%ecx,1)
 8048634:       8d 50 04                lea    0x4(%eax),%edx
 8048637:       8b 48 04                mov    0x4(%eax),%ecx
 804863a:       66 0f 1a 8d 68 ff ff    bndmov -0x98(%ebp),%bnd1
 8048641:       ff
 8048642:       0f 1b 0c 0a             bndstx %bnd1,(%edx,%ecx,1)
 8048646:       8b 10                   mov    (%eax),%edx
 8048648:       66 0f 1a 9d 70 ff ff    bndmov -0x90(%ebp),%bnd3
 804864f:       ff
 8048650:       0f 1b 1c 10             bndstx %bnd3,(%eax,%edx,1)
 8048654:       f2 e8 e5 02 00 00       bnd call 804893f <upper>
...

So, setting the bounds registers at function entry has no effect, because the
bounds are passed in the bounds table instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|testsuite                   |tdep

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tdep                        |testsuite

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch posted:
https://sourceware.org/pipermail/gdb-patches/2020-December/173768.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=346e7e192370a4d602e14466825c329ed5920c8f

commit 346e7e192370a4d602e14466825c329ed5920c8f
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Dec 11 18:26:40 2020 +0100

    [gdb/testsuite] Update gdb.arch/i386-mpx-call.exp for -m32

    When running test-case gdb.arch/i386-mpx-call.exp with target board
unix/-m32,
    we run into:
    ...
    (gdb) continue^M
    Continuing.^M
    (gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd
violation
    ...

    Let's look first for reference at -m64, where the test passes.

    The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks
in
    the exec.  Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
    call passes pointer bounds as well as arguments.  The call to upper (with
    four pointer arguments and an int argument, passed in 5 registers) is
modified
    like this:
    ...
       lea    -0xa0(%rbp),%rcx
       lea    -0x80(%rbp),%rdx
       lea    -0x60(%rbp),%rsi
       lea    -0x40(%rbp),%rax
       mov    $0x0,%r8d
    +  bndmov -0x110(%rbp),%bnd3
    +  bndmov -0x100(%rbp),%bnd2
    +  bndmov -0xf0(%rbp),%bnd1
    +  bndmov -0xe0(%rbp),%bnd0
       mov    %rax,%rdi
    -  callq  <upper>
    +  bnd callq <upper>
    ...
    passsing the four pointer bounds in bounds registers BND0-3.

    The top-level mechanism of the test is as follows:
    - run the exec to after all mallocs are done, such that all pointer
variables
      are valid
    - do inferior calls, similar to those present in the program

    The inferior call mechanism doesn't differentiate between a call to a
function
    compiled with -fcheck-pointer-bounds, and one without.  It merely resets
the
    bound registers to all-allowed state (see amd64_push_dummy_call), to make
sure
    the checks don't trigger during the inferior call.  [ This is the same as
what
    happens when executing a call without bnd prefix when the BNDPRESERVE bit
of
    the BNDCFG register is set to 0, a provision for calling an instrumented
    function using a non-instrumented call. ]

    First, two inferior calls are done (default_run and verify_default_values)
    with the bound registers unmodified by the test.  So, the memory accesses
are
    performed with the bounds registers set by amd64_push_dummy_call to
    all-allowed, and the bounds checks do not trigger.

    Then we try to do an inferior call with modified bounds registers, set to
    none-allowed.  In order to do that, we set a breakpoint at *upper before
    doing the inferior call.  Once we hit the breakpoint during the inferior
call,
    the bounds registers are set to none-allowed, and we continue expecting to
run
    into an triggered bounds check, which takes the shape of a sigsegv.

    Back to -m32.  Here, the pointer arguments are passed in memory rather than
    registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
    the Bounds Table using bndstx:
    ...
      movl   $0x0,0x10(%eax)
      lea    -0x70(%ebp),%edx
      mov    %edx,0xc(%eax)
      lea    -0x5c(%ebp),%edx
      mov    %edx,0x8(%eax)
      lea    -0x48(%ebp),%edx
      mov    %edx,0x4(%eax)
      lea    -0x34(%ebp),%edx
      mov    %edx,(%eax)
      lea    0xc(%eax),%edx
      mov    0xc(%eax),%ecx
      bndmov -0xa8(%ebp),%bnd1
      bndstx %bnd1,(%edx,%ecx,1)
      lea    0x8(%eax),%edx
      mov    0x8(%eax),%ecx
      bndmov -0xa0(%ebp),%bnd3
      bndstx %bnd3,(%edx,%ecx,1)
      lea    0x4(%eax),%edx
      mov    0x4(%eax),%ecx
      bndmov -0x98(%ebp),%bnd1
      bndstx %bnd1,(%edx,%ecx,1)
      mov    (%eax),%edx
      bndmov -0x90(%ebp),%bnd3
      bndstx %bnd3,(%eax,%edx,1)
      bnd call 804893f <upper>
    ...

    Again, the bounds registers are reset at the start of the inferior call by
    amd64_push_dummy_call, and modified by the test-case, but neither has any
    effect.  The code in upper reads the pointer bounds from the Bounds Table,
not
    from the bounds registers.

    Note that for a test.c with an out-of-bounds access:
    ...
    $ cat test.c
    void foo (int *a) { volatile int v = a[1]; }
    int main (void) { int a; foo (&a); return 0; }
    $ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
    $ ./a.out
    Saw a #BR! status 1 at 0x804848d
    ...
    and inferior call foo (&a) right before "bnd call foo" (at the point that
the
    bounds for a are setup in the bounds table) doesn't trigger a bounds
violation:
    ...
    (gdb) call foo (&a)
    (gdb)
    ...
    This is because the bounds table doesn't associate a pointer with bounds,
but
    rather a pair of pointer and pointer location.  So, the bound is setup for
&a,
    with as location the pushed argument in the frame.  The inferior call
however
    executes in a dummy frame, so the bound is checked for &a with as location
the
    pushed argument in the dummy frame, which is different, so the bounds check
    doesn't trigger.

    In conclusion, this is expected behaviour.

    Update the test-case to not expect to override effective pointer bounds
using
    the bounds registers when the bounds passing is done via the Bounds Table.

    Tested on x86_64-linux.

    gdb/testsuite/ChangeLog:

    2020-12-11  Tom de Vries  <tdevries@suse.de>

            PR testsuite/26991
            * gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
            violations by setting bounds registers if the bounds are passed in
the
            Bounds Table.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch fixed test-case committed, marking resolved-fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.