aboutsummaryrefslogtreecommitdiff
path: root/gdb/f-valprint.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2018-04-07 14:08:56 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2018-04-07 14:09:14 -0400
commita0be7a3671e6252c0f3353d128f84c641005fa06 (patch)
tree6a76e262f06437856fbf18f53f8979443b078193 /gdb/f-valprint.c
parent9b73db36739a72d216eb14d35edac2acfca7faa3 (diff)
downloadgdb-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