This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Recording a file's language in the SO stab? (anyone have Sun's compiler handy?)
- From: Mark Kettenis <kettenis at jive dot nl>
- To: jmolenda at apple dot com
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 4 Aug 2004 09:08:43 +0200 (CEST)
- Subject: Re: Recording a file's language in the SO stab? (anyone have Sun's compiler handy?)
- References: <810EE7BD-E596-11D8-8435-000A9569836A@apple.com>
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