From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27089 invoked by alias); 3 Dec 2008 17:27:44 -0000 Received: (qmail 27081 invoked by uid 22791); 3 Dec 2008 17:27:43 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Dec 2008 17:27:03 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 96D6710EB4; Wed, 3 Dec 2008 17:27:01 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 4102F10EB3; Wed, 3 Dec 2008 17:27:01 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1L7vV6-00059v-Q8; Wed, 03 Dec 2008 12:27:00 -0500 Date: Wed, 03 Dec 2008 17:27:00 -0000 From: Daniel Jacobowitz To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= Cc: gdb@sources.redhat.com Subject: Re: std::string and MI Message-ID: <20081203172700.GA19812@caradoc.them.org> Mail-Followup-To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , gdb@sources.redhat.com References: <200811271339.03070.apoenitz@trolltech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200811271339.03070.apoenitz@trolltech.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes 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: 2008-12/txt/msg00004.txt.bz2 On Thu, Nov 27, 2008 at 01:38:56PM +0100, André Pönitz wrote: > I get after issuing a "-stack-list-locals 2" the response > > ^done,locals=[{name="s",type="string"},{name="f",type="foo::string"}, > {name="t",type="string"}] > > Similarily, "-var-create s * s" followed by "-var-info-type s" produces > > ^done,type="string" > > In both cases the 'std::' namespace is missing from the type. I'll second Tom - I think I opened a GCC bug report about this. > Incidentally: Would it be possible to extend the MI commands that output > types to also produce the mangled types? (This could be restricted to the > cases where these actually differs from the unmangled ones, but I really > don't mind duplicated output) There's not really any such thing in the debug info. Some GCC debug info includes mangled names for functions, but it's not always there and it is never present for types. We'd have to reconstruct it from linkage names and map to parameters; it would be very hit-or-miss. -- Daniel Jacobowitz CodeSourcery