diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2018-04-07 14:08:56 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2018-04-07 14:09:14 -0400 |
commit | a0be7a3671e6252c0f3353d128f84c641005fa06 (patch) | |
tree | 6a76e262f06437856fbf18f53f8979443b078193 /gdb/f-valprint.c | |
parent | 9b73db36739a72d216eb14d35edac2acfca7faa3 (diff) | |
download | gdb-a0be7a3671e6252c0f3353d128f84c641005fa06.zip gdb-a0be7a3671e6252c0f3353d128f84c641005fa06.tar.gz gdb-a0be7a3671e6252c0f3353d128f84c641005fa06.tar.bz2 |
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.
Diffstat (limited to 'gdb/f-valprint.c')
0 files changed, 0 insertions, 0 deletions