From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21309 invoked by alias); 8 Jul 2002 13:47:54 -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 21301 invoked from network); 8 Jul 2002 13:47:52 -0000 Received: from unknown (HELO gaea.projecticarus.com) (195.10.228.71) by sources.redhat.com with SMTP; 8 Jul 2002 13:47:52 -0000 Received: from [192.168.128.13] (host213-1-89-124.in-addr.btopenworld.com [213.1.89.124]) by gaea.projecticarus.com (8.11.6/8.11.6) with ESMTP id g68DlpV05807 for ; Mon, 8 Jul 2002 14:47:51 +0100 Subject: Is Single step into C++ virtual thunk still broken? From: Daedalus To: gdb@sources.redhat.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 08 Jul 2002 06:47:00 -0000 Message-Id: <1026135745.26012.18.camel@pan> Mime-Version: 1.0 X-SW-Source: 2002-07/txt/msg00080.txt.bz2 I have waded through the archives but can't find anything newer than 1 year ago discussing this. I'm using latest cvs gdb and gcc3.1. and specifiying DWARF-2 debug info. When I single step into a virtual member function of a polymorphic object in my C++ app, the source display heads off to some random line in a header file, and another single step takes me back to the next source line after the virtual function. Putting a breakpoint in the actual function being called works as expected. I quote from a message by Andrew Cagney, 28 Jun 2001: ***************************** > - Skipping vtable thunks, if necessary I don't know if this was ever discussed on this list. As I understand it, v3 virtual function is sometimes called via a ``thunk''. A ``thunk'' pulls a rabbit out of a hat (finds the correct object to pass to the real function) and then passes control to the real function. At present, if GDB stepped into a thunk it would find no line info, treat it like a library and just skip it - oops, step into virtual functions via thunks doesn't work. One proposed solution is to mimic / generalize the shared library mechanism so that GDB will single step through it to the real function. I think this bug is pretty serious since, GDB will, randomly loose control over the target. I certainly think it is more serious than the constructor problem. ***************************** Is this still broke, or am I missing something? Andrew Walrond Project Icarus