From: Mark Kettenis <kettenis@jive.nl>
To: jmolenda@apple.com
Cc: gdb@sources.redhat.com
Subject: Re: Recording a file's language in the SO stab? (anyone have Sun's compiler handy?)
Date: Wed, 04 Aug 2004 07:10:00 -0000 [thread overview]
Message-ID: <200408040708.i7478hcN014697@juw15.nfra.nl> (raw)
In-Reply-To: <810EE7BD-E596-11D8-8435-000A9569836A@apple.com> (message from Jason Molenda on Tue, 3 Aug 2004 14:45:58 -0700)
From: Jason Molenda <jmolenda@apple.com>
Date: Tue, 3 Aug 2004 14:45:58 -0700
That's the real design question -- how to decide what numbers correlate
to what languages. If anyone has access to the Sun compiler, I'd
really like to find out what numbers they issue for C/C++ if they're
really doing this. Otherwise I'll be picking numbers at random.
Hi Jason,
Here are the numbers as given in Sun's Stabs Interface Manual (Version
4.0):
N_SO_AS 1 assembler source
N_SO_C 2 K & R source
N_SO_ANSI_C 3 ANSI C source
N_SO_CC 4 C++ source
N_SO_FORTRAN 5 Fotrtran source
N_SO_PASCAL 6 Pascal source
N_SO_FOTRAN90 7 Fotran90 source
The manual also says explicitly that if the value is 0, the langauge
should be inferred from the extension of the source file.
I've already done a quick implementation of this in our gdb and in the
FSF top of tree sources - it's not especially complicated. I added a
language enum to the partial_symtab structure to record it so it was
easy to pick up in set_initial_language() when we only have psymtabs
read in. That's probably not necessary to work but it didn't seem like
such a bad idea.
Can't reallu judge this.
Anyway, I wanted to bounce this off the group to see if there are any
reactions. We can add this as an Apple Local change in our gcc/gdb but
I hate to extend the debug format on our fork if we can avoid it at
all.
Yes, this seems worthwhile to have.
Mark
next prev parent reply other threads:[~2004-08-04 7:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-03 21:46 Jason Molenda
2004-08-04 7:10 ` Mark Kettenis [this message]
2004-08-04 16:51 ` Jim Blandy
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=200408040708.i7478hcN014697@juw15.nfra.nl \
--to=kettenis@jive.nl \
--cc=gdb@sources.redhat.com \
--cc=jmolenda@apple.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