Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: John Demme <me@teqdruid.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: D Symbol Demangling
Date: Mon, 04 Apr 2005 20:44:00 -0000	[thread overview]
Message-ID: <1112647505.14153.46.camel@localhost.localdomain> (raw)
In-Reply-To: <425185A9.8090104@redhat.com>

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.

Thanks
John Demme

On Mon, 2005-04-04 at 11:21 -0700, Michael Snyder wrote:
> John Demme wrote:
> > Thus far, I've had partial success.  In fairly simple D programs, my
> > demangling works, but in more complex programs with mixed C and D code
> > (D is link-compatible with C) it only calls the D demangler for some of
> > the functions.
> 
> What's the granularity of mixed code?  Is it mixed within a source
> file, or just between source files?  If a source file contains only
> one language, I think gdb ought to be able to discern it reliably.
> 
> When you say "for some of the functions", what differentiates
> the ones where it successfully discerns the D language from those
> where it doesn't?
> 


  reply	other threads:[~2005-04-04 20:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-04  2:37 John Demme
2005-04-04 18:21 ` Michael Snyder
2005-04-04 20:44   ` John Demme [this message]
2005-04-04 20:47     ` Daniel Jacobowitz
2005-04-04 21:49     ` Michael Snyder
2005-04-04 22:39       ` John Demme
     [not found]       ` <1112654359.14153.50.camel@localhost.localdomain>
     [not found]         ` <4251CF00.5080002@redhat.com>
2005-04-08 16:47           ` John Demme
2005-04-08 16:52             ` Daniel Jacobowitz
2005-04-08 20:50               ` John Demme
2005-04-08 21:11                 ` Daniel Jacobowitz
2006-04-19 11:18 Thomas Kuehne
2006-04-20 13:20 ` Daniel Jacobowitz
2006-04-21 21:25   ` Thomas Kühne
2006-04-22 22:52     ` Thomas Kühne
2006-04-24 17:21       ` Jim Blandy
2006-04-24 20:53         ` Daniel Jacobowitz
2006-04-25  3:35           ` Eli Zaretskii
2006-04-25 14:13             ` DJ Delorie
2006-04-29  7:23               ` Thomas Kühne
2006-04-29 16:47                 ` DJ Delorie

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=1112647505.14153.46.camel@localhost.localdomain \
    --to=me@teqdruid.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    /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