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

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

[Jason Molenda]

We've got a bunch of customers with big bunches of code that are 
written in e.g. C++ but whose files end in ".c".  With stabs, gdb uses 
the source filename extension to set the language, so these developers 
usually have lots of problems.  Luckily, fixing this is not hard.

The SO stab entry doesn't use the "desc" part of its nlist structure 
for anything.  That's 16 bits of joyful emptiness, and I want to 
appropriate it to record the source language.

It looks like Sun did something similar; stabs.texi says

> @findex N_SO
> Before any other stabs occur, there must be a stab specifying the 
> source
> file.  This information is contained in a symbol of stab type
> @code{N_SO}; the string field contains the name of the file.  The
> value of the symbol is the start address of the portion of the
> text section corresponding to that file.
>
> With the Sun Solaris2 compiler, the desc field contains a
> source-language code.
> @c Do the debuggers use it?  What are the codes? -djm


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.

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.

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.


Jason

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

[Mark Kettenis]

   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

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

[Jim Blandy]

Mark Kettenis <kettenis@jive.nl> writes:
>    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.

Seems good to me, too.