Re: [PATCH: gdb/mi] -stack-list-locals testcase

[Mark Kettenis <kettenis at chello dot nl>]

   Date: Wed, 07 Jan 2004 11:31:54 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > *** mi-stack.exp.~1.10.~    2002-11-05 15:43:18.000000000 +0000
   > --- mi-stack.exp    2004-01-05 23:38:27.000000000 +0000
   > ***************
   > *** 57,63 ****
   >       # -stack-list-frames 1 3
   >         mi_gdb_test "231-stack-list-frames" \
   > !         "231\\^done,stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"8\"\},frame=\{level=\"1\",addr=\"$hex\",func=\"callee3\",.*\},frame=\{level=\"2\",addr=\"$hex\",func=\"callee2\",.*\},frame=\{level=\"3\",addr=\"$hex\",func=\"callee1\",.*\},frame=\{level=\"4\",addr=\"$hex\",func=\"main\",.*\}\\\]" \
   >                   "stack frame listing"
   >       mi_gdb_test "232-stack-list-frames 1 1" \
   >           "232\\^done,stack=\\\[frame=\{level=\"1\",addr=\"$hex\",func=\"callee3\",.*\}\\\]" \
   > --- 57,63 ----
   >       # -stack-list-frames 1 3
   >         mi_gdb_test "231-stack-list-frames" \
   > !         "231\\^done,stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"callee4\",file=\".*basics.c\",line=\"7\"\},frame=\{level=\"1\",addr=\"$hex\",func=\"callee3\",.*\},frame=\{level=\"2\",addr=\"$hex\",func=\"callee2\",.*\},frame=\{level=\"3\",addr=\"$hex\",func=\"callee1\",.*\},frame=\{level=\"4\",addr=\"$hex\",func=\"main\",.*\}\\\]" \
   >                   "stack frame listing"
   >       mi_gdb_test "232-stack-list-frames 1 1" \
   >           "232\\^done,stack=\\\[frame=\{level=\"1\",addr=\"$hex\",func=\"callee3\",.*\}\\\]" \
   > 
   > This test (and the rest of mi-stack.exp) is passing on a PPC/NetBSD gcc 2.96 stabs system.  We'll need to look at it more carefully (or check michaelc's test matrix) to see why there's a failure.  MI is more strict  with its test results. 

   Nick, what's your exact system?  On amd64 and i386 GNU/Linux systems 
   (RHEL 3, dwarf 2, gcc 2.3.2 based) mi-stack.exp I'm also seeing this 
   pass (puzzled).

I think it would be useful if Nick could post the output from "objdump
--stabs" on the generated binary.  The output of "gcc -g -S" on the
relevant source file would be even more useful.

I know for a fact that there are serious problems with the way GDB
reads line numbers for stabs.  In order to work around the bad
line-number info generated by GCC 2.95.3, we relocate the first
N_SLINE stab, which leads to incorrect behaviour, such as skipping the
first line of a function, with other compilers (such as Sun's) and
when debugging optimized code.  It's not unlikely that it influences
non-IA-32 platforms too.

I'll post a more detailed explanation in the near future.

Mark