]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/testsuite/ChangeLog
Fix gdb.mi/mi-stack.exp when gcc generates a stack protector
authorSimon Marchi <simon.marchi@polymtl.ca>
Sat, 7 Apr 2018 18:08:56 +0000 (14:08 -0400)
committerSimon Marchi <simon.marchi@polymtl.ca>
Sat, 7 Apr 2018 18:09:14 +0000 (14:09 -0400)
commita0be7a3671e6252c0f3353d128f84c641005fa06
tree6a76e262f06437856fbf18f53f8979443b078193
parent9b73db36739a72d216eb14d35edac2acfca7faa3
Fix gdb.mi/mi-stack.exp when gcc generates a stack protector

I see some failures in the gdb.mi/mi-stack.exp test.  The test runs to
the callee4 function:

  int callee4 (void)
  {
    int A=1;
    int B=2;
    int C;
    int D[3] = {0, 1, 2};

    C = A + B;
    return 0;
  }

and expects to be stopped at the A=1 line.  However, when gcc generates
some stack protection code, it will stop at the { instead, as shown by
this disassembly (after I did "break callee4" and "run"):

  (gdb) disassemble /s
  Dump of assembler code for function callee4:
  /home/simark/src/binutils-gdb/gdb/testsuite/gdb.mi/mi-stack.c:
  26 {
     0x00005555555546ca <+0>: push   %rbp
     0x00005555555546cb <+1>: mov    %rsp,%rbp
     0x00005555555546ce <+4>: sub    $0x20,%rsp
  => 0x00005555555546d2 <+8>: mov    %fs:0x28,%rax
     0x00005555555546db <+17>: mov    %rax,-0x8(%rbp)
     0x00005555555546df <+21>: xor    %eax,%eax

  27   int A=1; /* callee4 begin */
     0x00005555555546e1 <+23>: movl   $0x1,-0x20(%rbp)

  28   int B=2;
     0x00005555555546e8 <+30>: movl   $0x2,-0x1c(%rbp)

The rest of the test relies on execution stopping on the A=1, so many things
fail after that.  This patch uses mi_continue_to_line instead, to stop at the
A=1 line precisely.

gdb/testsuite/ChangeLog:

* gdb.mi/mi-stack.exp (test_stack_frame_listing): Use
mi_continue_to_line.
* gdb.mi/mi-stack.c (callee4): Add comment.
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.mi/mi-stack.c
gdb/testsuite/gdb.mi/mi-stack.exp