From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24121 invoked by alias); 4 Apr 2005 22:39:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24070 invoked from network); 4 Apr 2005 22:39:50 -0000 Received: from unknown (HELO md0.mail.umd.edu) (128.8.31.162) by sourceware.org with SMTP; 4 Apr 2005 22:39:50 -0000 Received: from teqdruid.student.umd.edu (teqdruid.student.umd.edu [129.2.222.235]) by md0.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id ASU23162 (AUTH teqdruid); Mon, 4 Apr 2005 18:39:46 -0400 (EDT) Subject: Re: D Symbol Demangling From: John Demme Cc: gdb-patches@sources.redhat.com In-Reply-To: <4251B646.7010801@redhat.com> References: <1112582221.14153.32.camel@localhost.localdomain> <425185A9.8090104@redhat.com> <1112647505.14153.46.camel@localhost.localdomain> <4251B646.7010801@redhat.com> Content-Type: text/plain Date: Mon, 04 Apr 2005 22:39:00 -0000 Message-Id: <1112654401.14153.52.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00048.txt.bz2 On Mon, 2005-04-04 at 14:48 -0700, Michael Snyder wrote: > John Demme wrote: > > By link compatible, I mean that I'll compile a D file with a D compiler > > to a .o file, then I can link it with another .o file compiled with, > > say, gcc. So a source file can be either C or D, but not both (barring > > some sort of bizarre scripting situations.) An important note here, > > however, is that because D can call C functions, some of the symbols in > > a D object file won't be mangled. > > > > I've been having trouble figuring out what differentiates the functions. > > On the surface, the more complex ones don't work, but in my test, > > there's only simple one. > > > > Do I appear to be interfacing with GDB correctly? If so, I'll triple > > check my code. > > Looks ok at first glance. Do I understand that the D compiler > is not gcc or gcc-derived? That raises the question of whether > the debug info in the D-compiled .o file is "correct" as far as > gdb is concerned. Something unexpected about that info might > cause gdb to "lose its place", eg. in determining which functions > belong to the D-compiled module. > > That's correct. It uses Walter Bright's C backend. In fact, the DWARF2 information that it generates it total crap, as in just plain wrong in some/most cases. There is a gcc-derived version of it. I'll give that a try. Thanks John