This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Recording a file's language in the SO stab? (anyone have Sun's compiler handy?)


   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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]