From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17989 invoked by alias); 18 Nov 2010 19:47:24 -0000 Received: (qmail 17807 invoked by uid 22791); 18 Nov 2010 19:47:23 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Nov 2010 19:47:14 +0000 Received: from igor (brln-4db93118.pool.mediaWays.net [77.185.49.24]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LjwWD-1OllZO3oBl-00bq8k; Thu, 18 Nov 2010 20:47:12 +0100 Message-ID: Reply-To: =?Windows-1252?Q?Martin_Schr=F6der?= From: =?Windows-1252?Q?Martin_Schr=F6der?= To: Subject: Breakpoint troubles on typedefs Date: Thu, 18 Nov 2010 19:47:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit 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: 2010-11/txt/msg00078.txt.bz2 Hello everyone. I seem to have found a bug / feature in GDB 7.2 for C++. The problem is that typedefs are not converted to their base type when one tries to set a breakpoint into a function that has a typedef'd type as parameter. Here's a simple program that triggers this bug: main.cpp - - - - - - - - - - - - - - - - - - - - - - - - - #include typedef std::string foo; void calltest(foo val) {} int main() { calltest(foo("")); } - - - - - - - - - - - - - - - - - - - - - - - - - Compiled with: "g++ -O0 -g main.cpp -o a.out" Now, when you start the program with gdb 7.2, you'll get the following whatis replies: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) whatis foo type = std::string (gdb) whatis calltest type = void (foo) - - - - - - - - - - - - - - - - - - - - - - - - - But now, try to set a breakpoints. Once with "foo" and once with "std::string"; which should be equal, as whatis has just told us. - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) break calltest(foo) Breakpoint 1 at 0x80485e7: file main.cpp, line 5. (gdb) break calltest(std::string) Can't find member of namespace, class, struct, or union named "calltest(std::string)" Hint: try 'calltest(std::string) or 'calltest(std::string) (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) n - - - - - - - - - - - - - - - - - - - - - - - - - So, you might try to see the expansion. This is what GDB returns on Tab: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) break calltest [...] calltest(foo) calltest(std::basic_string, std::allocator >) [...] - - - - - - - - - - - - - - - - - - - - - - - - - So, among the massiv amounts of text, we find both foo, and the full "std::string" typedef-expansion. Okay, so we try to set the breakpoint accordingly: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) whatis calltest(std::string) type = void (foo) (gdb) whatis calltest(std::basic_string, std::allocator >) type = void (foo) (gdb) break calltest(std::basic_string, std::allocator >) Can't find member of namespace, class, struct, or union named [...] Make breakpoint pending on future shared library load? (y or [n]) n - - - - - - - - - - - - - - - - - - - - - - - - - So ... what this tells me is that "whatis" reads the symbol table correctly, but break somehow doesn't. But wait, it gets even better. Now quit GDB and restart it. This is what you get when you issue the "break" as the very first command: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) break calltest(foo) Function "calltest(foo)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) whatis foo type = std::string (gdb) break calltest(foo) Breakpoint 1 at 0x80485e7: file main.cpp, line 5. - - - - - - - - - - - - - - - - - - - - - - - - - Interesting, isn't it? Do note that you can substitute the "whatis" with a range of commands; for example "break main", or "list" and the second call will still work. But not all commands, observe: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) break calltest(foo) Function "calltest(foo)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break calltest(foo) Function "calltest(foo)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n - - - - - - - - - - - - - - - - - - - - - - - - - Furthermore, starting with a fresh GDB will also change what the tab-expansion shows. Instead of lots and lots of types, it shows only the two "calltest" function entries; but it shows "std::string" instead of the full typedef-expansion for std::string in the second entry. Anyway, here's the platform and program versions I used for testing: OS: Ubuntu 10.10 gdb: 7.2-ubuntu g++: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 I've tested the same program with an older, self-compiled GDB 7.1, and there I get this: - - - - - - - - - - - - - - - - - - - - - - - - - (gdb) break calltest(foo) Function "calltest(foo)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) whatis foo type = std::string (gdb) break calltest(foo) Function "calltest(foo)" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break calltest(std::string) Breakpoint 1 at 0x8048627: file main.cpp, line 5. - - - - - - - - - - - - - - - - - - - - - - - - - Basically, I have no clue what could trigger this strange behaviour. It almost seems to me as if GDB 7.2 added support for typedef'd variables, but broke the "break" statement in a way that causes it to not read the symbol-table correctly anymore, but I could be a mile off with that suspicion. Any help would be appreciated, thanks, Martin Schröder.