From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23229 invoked by alias); 7 Jan 2004 17:34:23 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23218 invoked from network); 7 Jan 2004 17:34:21 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 7 Jan 2004 17:34:21 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i07HYDwm000812; Wed, 7 Jan 2004 18:34:13 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i07HYD8a000785; Wed, 7 Jan 2004 18:34:13 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i07HYDMk000782; Wed, 7 Jan 2004 18:34:13 +0100 (CET) Date: Wed, 07 Jan 2004 17:34:00 -0000 Message-Id: <200401071734.i07HYDMk000782@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: nick@nick.uklinux.net, gdb-patches@sources.redhat.com In-reply-to: <3FFC347A.2030605@gnu.org> (message from Andrew Cagney on Wed, 07 Jan 2004 11:31:54 -0500) Subject: Re: [PATCH: gdb/mi] -stack-list-locals testcase References: <16319.64137.458928.417189@nick.uklinux.net> <3FC3F85F.8050007@gnu.org> <16332.423.456414.834703@nick.uklinux.net> <16341.13503.256676.933542@nick.uklinux.net> <3FD75E64.1020508@gnu.org> <16346.10340.488095.107663@nick.uklinux.net> <16351.48550.8915.678388@nick.uklinux.net> <3FF9DA74.7000304@gnu.org> <16377.64533.42018.863120@nick.uklinux.net> <3FFA0A4A.1020908@gnu.org> <3FFC347A.2030605@gnu.org> X-SW-Source: 2004-01/txt/msg00167.txt.bz2 Date: Wed, 07 Jan 2004 11:31:54 -0500 From: Andrew Cagney > *** 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