From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14700 invoked by alias); 24 Aug 2004 12:12:50 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14669 invoked from network); 24 Aug 2004 12:12:48 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sourceware.org with SMTP; 24 Aug 2004 12:12:48 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1BzaAQ-0007ei-00; Tue, 24 Aug 2004 08:12:46 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id E58704B102; Tue, 24 Aug 2004 08:13:06 -0400 (EDT) Date: Tue, 24 Aug 2004 12:12:00 -0000 From: Michael Chastain To: dan@imi-test.com Subject: Re: cannot subscript something of type Cc: gdb@sources.redhat.com Message-ID: <412B30D2.nailETK1H2VST@mindspring.com> References: <005601c4871d$67c8c9f0$0401a8c0@dan> <20040821021144.GA3321@nevyn.them.org> <008d01c48952$b7e0e7b0$0401a8c0@dan> <412A616D.nailD4K28EC6E@mindspring.com> <009e01c48959$a5192640$0401a8c0@dan> In-Reply-To: <009e01c48959$a5192640$0401a8c0@dan> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00312.txt.bz2 [Taking drow off the "To:" list because this probably isn't a gdb bug]. Okay, your "z1" executable manifests the same symptoms on my system, native i686-pc-linux-gnu with red-hat-8.0. (gdb) break main Breakpoint 1 at 0x8048478: file tester.cpp, line 9. (gdb) run Starting program: /berman/home/mec.gnu/tmp/dm/z1 Breakpoint 1, main () at tester.cpp:9 9 Mod[0].powered_up = 1 ; (gdb) ptype Mod type = (gdb) print Mod[0] cannot subscript something of type `' (gdb) print (S_Module) Mod[0] No symbol "S_Module" in current context. In the file z1, there are no symbols for Mod in tester.cpp! There are some residual type definitions for 'char', 'short', 'int', et cetera. Looking at the assembly code for "main", it did not come from: g++ -Wall -g tester.cpp -o tester "main" has optimized code in it, not default code. The variable 'Mod' is still present with the optimized code. (It would be very hard for the compiler to optimize away a global variable). So normally, the linker should have kept the type information for it too, if that type information was ever produced. I tried some compiler switches on a suse-9 machine but could not quite get the exact code that your compiler generated. Can you rebuild the 'tester' executable and check the exact options that you are using, for both compiling and linking? The best thing would be: script g++ -v -Wall -g tester.cpp -o tester exit ... and mail in the script, along with the new 'tester' executable. Also, you don't have to tar+compress the executable if it's only 10k again.