From: Thomas Richter <thor@mail.math.tu-berlin.de>
To: gdb@sourceware.org
Subject: [BUG] Tab Expansion for C++
Date: Tue, 13 Feb 2007 16:28:00 -0000 [thread overview]
Message-ID: <200702131613.l1DGDWVX009239@mersenne.math.TU-Berlin.DE> (raw)
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
next reply other threads:[~2007-02-13 16:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-13 16:28 Thomas Richter [this message]
2007-02-13 16:56 ` Daniel Jacobowitz
2007-02-13 17:08 ` Thomas Richter
2007-02-13 19:33 ` Daniel Jacobowitz
2007-02-14 12:08 ` Thomas Richter
2007-02-14 12:36 ` Daniel Jacobowitz
2007-02-19 11:48 ` Thomas Richter
2007-02-19 12:28 ` Daniel Jacobowitz
2007-02-19 13:03 ` Robert Dewar
2007-02-13 19:00 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200702131613.l1DGDWVX009239@mersenne.math.TU-Berlin.DE \
--to=thor@mail.math.tu-berlin.de \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox