From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17240 invoked by alias); 13 Feb 2007 16:13:50 -0000 Received: (qmail 17230 invoked by uid 22791); 13 Feb 2007 16:13:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.math.TU-Berlin.DE (HELO mail.math.TU-Berlin.DE) (130.149.12.212) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Feb 2007 16:13:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.math.TU-Berlin.DE (8.13.7/8.13.3) with ESMTP id l1DGDfOJ011368 for ; Tue, 13 Feb 2007 17:13:41 +0100 (MET) Received: from mail.math.TU-Berlin.DE ([127.0.0.1]) by localhost (mail.math.tu-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10911-09 for ; Tue, 13 Feb 2007 17:13:37 +0100 (MET) Received: from mersenne.math.TU-Berlin.DE (mersenne.math.TU-Berlin.DE [130.149.14.233]) by mail.math.TU-Berlin.DE (8.13.7/8.13.3) with ESMTP id l1DGDW6N011285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Feb 2007 17:13:33 +0100 (MET) Received: from mersenne.math.TU-Berlin.DE (localhost [127.0.0.1]) by mersenne.math.TU-Berlin.DE (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id l1DGDWW7009240 for ; Tue, 13 Feb 2007 17:13:32 +0100 Received: (from thor@localhost) by mersenne.math.TU-Berlin.DE (8.13.3/8.13.3/Submit) id l1DGDWVX009239 for gdb@sourceware.org; Tue, 13 Feb 2007 17:13:32 +0100 From: Thomas Richter Message-Id: <200702131613.l1DGDWVX009239@mersenne.math.TU-Berlin.DE> Subject: [BUG] Tab Expansion for C++ To: gdb@sourceware.org Date: Tue, 13 Feb 2007 16:28:00 -0000 X-Mailer: ELM [version 2.4ME+ PL108 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00103.txt.bz2 Hi folks, the TAB expansion for C++ class members in GDB is - unfortunately - close to useless. Here's an example how to reproduce the problem: Type in the following program: /* snip */ class A { // int x; public: A(int i) { x = i; } ~A(void) { } // int getA(void) const { return x; } }; int main(int argc,char **argv) { A a(5); return a.getA(); } /* snip */ Compile with: thor@mersenne:~/src> g++-4.1 -O0 -fno-inline -ggdb3 gdbtest.cpp -o gdbtest Then run GDB: thor@mersenne:~/src> gdb gdbtest GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/tls/libthread_db.so.1". Consider finding the constructor of A (clearly, a contrived example) (gdb) break A:: now type TAB to get the members of A: A __do_global_dtors_aux char A::A(int) __dso_handle completed.5556 A::getA() const __fini_array_end data_start A::~A() __fini_array_start frame_dummy _DYNAMIC __i686.get_pc_thunk.bx int _GLOBAL_OFFSET_TABLE_ __init_array_end long int _IO_stdin_used __init_array_start long long int __CTOR_END__ __libc_csu_fini long long unsigned int __CTOR_LIST__ __libc_csu_init long unsigned int __DTOR_END__ __libc_start_main@plt main __DTOR_LIST__ _edata p.5554 __FRAME_END__ _end short int __JCR_END__ _fini short unsigned int __JCR_LIST__ _fp_hw signed char __bss_start _init unsigned char __data_start _start unsigned int __do_global_ctors_aux call_gmon_start ~A (gdb) Given that this is really a pretty short program, the output can grow enourmous for any realistically sized code since *all* functions are shown here, not only those that are members of A. Interestingly, gdb *does* know that, as can be seen from the above list. Could you please, please fix this? It's a long-standing bug, and it's pretty anoying. Thanks, Thomas