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

[Jason Molenda <jmolenda@apple.com>]

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