RFA/patch stabs reader: Recognize language hint in SO stab

RFA/patch stabs reader: Recognize language hint in SO stab

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Hi, this follows up to the note I posted to gdb a couple days ago,

http://sources.redhat.com/ml/gdb/2004-08/msg00015.html

The patch below uses the 'desc' 16-bit field in the SO stab's nlist 
record to indicate the language of the compilation unit, akin to the 
DW_AT_language DWARF attribute.  The Sun compiler has used it like this 
for a long time; we even had the language values in 
include/aout/stab_gnu.h but they were not used.  (I added the Fortran90 
value from Mark's e-mail, thanks Mark).

The stabs reader currently checks the filename suffix of the source 
file or header files to detect the type of the language.  My change 
will use the value of the desc field, if present, and will only use the 
filename suffix heuristics if no desc field setting has already been 
seen.

The most potentially controversial part of this patch, I expect, is 
that I needed to add two language codes for languages in use on MacOS X 
-- Objective-C and Objective-C++.  I don't have a way of communicating 
these codes back to Sun, and I don't want to have Sun and gcc using the 
same value for different languages, so I added ObjC/ObjC++ up at value 
50 (the Sun languages range from 1 to 7).  The number 50 was, 
obviously, chosen completely at random.

Eli, I added a table documenting these values to stabs.texinfo.  Do you 
think this is a correct use of a texinfo table?  I am not very 
experienced with texinfo.

Devang Patel will add the compiler support for this once we get 
agreement on the language code values here on the gdb list.

As always, I'm not committed to the particularly names of functions or 
method of implementing this -- I'll incorporate any feedback speedily 
and re-post.

Thanks!

[include/ChangeLog]
004-08-05  Jason Molenda  (jmolenda@apple.com)

         * aout/stab_gnu.h: Update N_SO table with FORTRAN90 addition 
from
         Sun's Stabs Interface Manual (Version 4.0).  Add Objective-C and
         Objective-C++ non-Sun language codes.

[gdb/ChangeLog]
2004-08-05  Jason Molenda  (jmolenda@apple.com)

         * dbxread.c (read_so_stab_language_hint): New function.
         (read_dbx_symtab): Prefer language from SO stab's desc field
         over language based on the suffix of the source filename.
         (start_psymtab): Only use the source filename suffix if the
         language hasn't been already set.
         (process_one_symbol): When expanding psymtab to symtab, use the
         desc field to set the language if it contains anything 
meaningful.

[gdb/doc/ChangeLog]
2004-08-05  Jason Molenda  (jmolenda@apple.com)

         * stabs.texinfo (Paths and Names of the Source Files):  
Document the
         meaning of values in the 'desc' field of a SO stab.



[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 8758 bytes --]

Index: include/aout/stab_gnu.h
===================================================================
RCS file: /cvs/src/src/include/aout/stab_gnu.h,v
retrieving revision 1.2
diff -u -p -r1.2 stab_gnu.h
--- include/aout/stab_gnu.h	14 Mar 2001 02:27:43 -0000	1.2
+++ include/aout/stab_gnu.h	5 Aug 2004 19:57:58 -0000
@@ -40,6 +40,9 @@ LAST_UNUSED_STAB_CODE
 #define	N_SO_CC		4	/* C++ */
 #define	N_SO_FORTRAN	5
 #define	N_SO_PASCAL	6
+#define N_SO_FORTRAN90  7
+#define N_SO_OBJC      50       /* Non-Sun language code: Objective-C */
+#define N_SO_OBJCPLUS  51       /* Non-Sun language code: Objective-C++ */
 
 /* Solaris2: Floating point type values in basic types.  */
 
Index: gdb/dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.69
diff -u -p -r1.69 dbxread.c
--- gdb/dbxread.c	1 Jul 2004 20:25:53 -0000	1.69
+++ gdb/dbxread.c	5 Aug 2004 19:57:58 -0000
@@ -292,6 +292,8 @@ static struct partial_symtab *start_psym
 					     struct partial_symbol **,
 					     struct partial_symbol **);
 
+static enum language read_so_stab_language_hint (short unsigned n_desc);
+
 /* Free up old header file tables */
 
 void
@@ -1506,7 +1508,11 @@ read_dbx_symtab (struct objfile *objfile
 
 	    /* Null name means end of .o file.  Don't start a new one. */
 	    if (*namestring == '\000')
-	      continue;
+              {
+                /* Reset the current language */
+                psymtab_language = language_unknown;
+	        continue;
+              }
 
 	    /* Some compilers (including gcc) emit a pair of initial N_SOs.
 	       The first one is a directory name; the second the file name.
@@ -1522,6 +1528,9 @@ read_dbx_symtab (struct objfile *objfile
 	        continue;		
 	      }
 
+            /* Try getting the file's language from SO stab's 'desc' field */
+            psymtab_language = read_so_stab_language_hint (nlist.n_desc);
+
 	    /* Some other compilers (C++ ones in particular) emit useless
 	       SOs for non-existant .c files.  We ignore all subsequent SOs that
 	       immediately follow the first.  */
@@ -1547,16 +1556,23 @@ read_dbx_symtab (struct objfile *objfile
 	       read_dbx_symtab function returns */
 
 	    namestring = set_namestring (objfile, nlist);
-	    tmp_language = deduce_language_from_filename (namestring);
 
-	    /* Only change the psymtab's language if we've learned
-	       something useful (eg. tmp_language is not language_unknown).
-	       In addition, to match what start_subfile does, never change
-	       from C++ to C.  */
-	    if (tmp_language != language_unknown
-		&& (tmp_language != language_c
-		    || psymtab_language != language_cplus))
-	    psymtab_language = tmp_language;
+            /* psymtab_language may have already been set by a SO stab
+               from the compiler.  If not, try to guess it from the
+               source filename extension.  */
+            if (psymtab_language == language_unknown)
+              {
+	        tmp_language = deduce_language_from_filename (namestring);
+
+	        /* Only change the psymtab's language if we've learned
+	           something useful (eg. tmp_language is not language_unknown).
+	           In addition, to match what start_subfile does, never change
+	           from C++ to C.  */
+	        if (tmp_language != language_unknown
+		    && (tmp_language != language_c
+		        || psymtab_language != language_cplus))
+	          psymtab_language = tmp_language;
+              }
 
 	    if (pst == NULL)
 	    {
@@ -1580,16 +1596,23 @@ read_dbx_symtab (struct objfile *objfile
 	    /* Mark down an include file in the current psymtab */
 
 	    namestring = set_namestring (objfile, nlist);
-	    tmp_language = deduce_language_from_filename (namestring);
 
-	    /* Only change the psymtab's language if we've learned
-	       something useful (eg. tmp_language is not language_unknown).
-	       In addition, to match what start_subfile does, never change
-	       from C++ to C.  */
-	    if (tmp_language != language_unknown
-		&& (tmp_language != language_c
-		    || psymtab_language != language_cplus))
-	    psymtab_language = tmp_language;
+            /* psymtab_language may have already been set by a SO stab
+               from the compiler.  If not, try to guess it from the
+               source filename extension.  */
+            if (psymtab_language == language_unknown)
+              {
+	        tmp_language = deduce_language_from_filename (namestring);
+
+	        /* Only change the psymtab's language if we've learned
+	           something useful (eg. tmp_language is not language_unknown).
+	           In addition, to match what start_subfile does, never change
+	           from C++ to C.  */
+	        if (tmp_language != language_unknown
+		    && (tmp_language != language_c
+		        || psymtab_language != language_cplus))
+	          psymtab_language = tmp_language;
+              }
 
 	    /* In C++, one may expect the same filename to come round many
 	       times, when code is coming alternately from the main file
@@ -2153,8 +2176,9 @@ start_psymtab (struct objfile *objfile, 
      if successful.  */
   elfstab_offset_sections (objfile, result);
 
-  /* Deduce the source language from the filename for this psymtab. */
-  psymtab_language = deduce_language_from_filename (filename);
+  /* As a last resort, use the source filename to determine the language. */
+  if (psymtab_language == language_unknown)
+    psymtab_language = deduce_language_from_filename (filename);
 
   return result;
 }
@@ -2877,6 +2901,9 @@ process_one_symbol (int type, int desc, 
 	  if (previous_stab_code == (unsigned char) N_SO)
 	    {
 	      patch_subfile_names (current_subfile, name);
+              /* Set the language if the SO stab indicates it.  */
+              if (read_so_stab_language_hint (desc) != language_unknown)
+                current_subfile->language = read_so_stab_language_hint (desc);
 	      break;		/* Ignore repeated SOs */
 	    }
 	  end_symtab (valu, objfile, SECT_OFF_TEXT (objfile));
@@ -3468,6 +3495,35 @@ stabsect_build_psymtabs (struct objfile 
   dbx_symfile_read (objfile, 0);
 }
 \f
+/* The compiler may indicate the source language in the SO stab's "desc" 
+   field.  This was originally a Sun extension, but being tres useful,
+   it's been adopted by gcc as well.  */
+static enum language
+read_so_stab_language_hint (short unsigned n_desc)
+{
+  switch (n_desc) 
+    {
+    case N_SO_AS:
+      return language_asm;
+    case N_SO_C:
+      return language_c;
+    case N_SO_ANSI_C:
+      return language_c;
+    case N_SO_CC:
+      return language_cplus;
+    case N_SO_FORTRAN:
+      return language_fortran;
+    case N_SO_PASCAL:
+      return language_pascal;
+    case N_SO_FORTRAN90:
+      return language_fortran;
+    case N_SO_OBJC:
+      return language_objc;
+    default:
+      return language_unknown;
+    }
+}
+\f
 static struct sym_fns aout_sym_fns =
 {
   bfd_target_aout_flavour,
Index: gdb/doc/stabs.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/stabs.texinfo,v
retrieving revision 1.15
diff -u -p -r1.15 stabs.texinfo
--- gdb/doc/stabs.texinfo	14 Jun 2004 22:26:34 -0000	1.15
+++ gdb/doc/stabs.texinfo	5 Aug 2004 19:57:58 -0000
@@ -422,9 +422,33 @@ file.  This information is contained in 
 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
+Some compilers use the desc field to indicate the language of the
+source file.  Sun's compilers started this usage, and the first
+constants are derived from their documentation.  Languages added
+by gcc/gdb start at 0x32 to avoid conflict with languages Sun may
+add in the future.  A desc field with a value 0 indicates that no
+language has been specified via this mechanism.
+
+@table @code
+@item 0x1     N_SO_AS
+Assembly language
+@item 0x2     N_SO_C
+K&R traditional C
+@item 0x3     N_SO_ANSI_C
+ANSI C
+@item 0x4     N_SO_CC
+C++
+@item 0x5     N_SO_FORTRAN
+Fortran
+@item 0x6     N_SO_PASCAL
+Pascal
+@item 0x7     N_SO_FORTRAN90
+Fortran90
+@item 0x32    N_SO_OBJC
+Objective-C
+@item 0x33    N_SO_OBJCPLUS
+Objective-C++
+@end table
 
 Some compilers (for example, GCC2 and SunOS4 @file{/bin/cc}) also
 include the directory in which the source was compiled, in a second

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Jason Molenda]

I knew I forgot something:  Testing.

I tested the patch on an x86 Linux box with gcc 3.4.0 with -gstabs+; 
there was no change with or without the patch.  The compiler wasn't 
setting the desc field in the SO stabs, of course, so I made a small 
C++ program

#include <iostream>

int foo (int a);
int
main()
{
    int a = 10;
    std::cout << "hi there" << a << std::endl;
    return foo (a);
}

int foo (int a)
{
   return a + 5;
}


called "a.c", and modified the stabs by hand to

         .file   "a.c"
         .stabs  "/tmp/",100,0,0,.Ltext0
         .stabs  "a.c",100,0,4,.Ltext0

The value 4 is N_SO_CC.  Without this change, this is what gdb looks 
like:

(gdb) b foo
Breakpoint 1 at 0x80488ed: file a.c, line 13.
(gdb) r
Starting program: /tmp/a.out
hi there10

Breakpoint 1, _Z3fooi (a=10) at a.c:14
14        return a + 5;
(gdb)


With this change, we get

(gdb) b foo
Breakpoint 1 at 0x80488ed: file a.c, line 14.
(gdb) r
Starting program: /tmp/a.out
hi there10

Breakpoint 1, foo (a=10) at a.c:14
14        return a + 5;
Current language:  auto; currently c++
(gdb)


Huzzah.

(obviously this is just an example of incorrect behavior -- when you're 
working with real C++ code the inability to detect the fact that it's a 
C++ program causes all sorts of problems.)

J

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Andrew Cagney]

> I knew I forgot something:  Testing.

Can this be turned into a proper testcase?  gdb.stabs/ I guess?  The 
last thing we want is to accidently break this.

Andrew

> I tested the patch on an x86 Linux box with gcc 3.4.0 with -gstabs+; there was no change with or without the patch.  The compiler wasn't setting the desc field in the SO stabs, of course, so I made a small C++ program
> 
> #include <iostream>
> 
> int foo (int a);
> int
> main()
> {
>    int a = 10;
>    std::cout << "hi there" << a << std::endl;
>    return foo (a);
> }
> 
> int foo (int a)
> {
>   return a + 5;
> }
> 
> 
> called "a.c", and modified the stabs by hand to
> 
>         .file   "a.c"
>         .stabs  "/tmp/",100,0,0,.Ltext0
>         .stabs  "a.c",100,0,4,.Ltext0
> 
> The value 4 is N_SO_CC.  Without this change, this is what gdb looks like:
> 
> (gdb) b foo
> Breakpoint 1 at 0x80488ed: file a.c, line 13.
> (gdb) r
> Starting program: /tmp/a.out
> hi there10
> 
> Breakpoint 1, _Z3fooi (a=10) at a.c:14
> 14        return a + 5;
> (gdb)
> 
> 
> With this change, we get
> 
> (gdb) b foo
> Breakpoint 1 at 0x80488ed: file a.c, line 14.
> (gdb) r
> Starting program: /tmp/a.out
> hi there10
> 
> Breakpoint 1, foo (a=10) at a.c:14
> 14        return a + 5;
> Current language:  auto; currently c++
> (gdb)
> 
> 
> Huzzah.
> 
> (obviously this is just an example of incorrect behavior -- when you're working with real C++ code the inability to detect the fact that it's a C++ program causes all sorts of problems.)
> 
> J

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Michael Chastain]

Oof, I will file this under "things to add to test suite in my
copious spare time."

Actually I think the best place for this would be in gdb.asm or
gdb.stabs.  Someone can hand-craft an assembly file with stab entries
for all the different languages, and then the test script can set
breakpoints on each supposed language.

Not today, though, my hands are full.

Michael C

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Eli Zaretskii]

> From: Jason Molenda <jmolenda@apple.com>
> Date: Thu, 5 Aug 2004 13:09:08 -0700
> 
> Eli, I added a table documenting these values to stabs.texinfo.  Do you 
> think this is a correct use of a texinfo table?

It is correct usage, if what you want in the result is this:

 `0x1     N_SO_AS'
     Assembly language
 `0x2     N_SO_C'
     K&R traditional C
 `0x3     N_SO_ANSI_C'
     ANSI C

In other words, "@table @code" typesets the entire argument of each
@item in the @code face (in Info, that is emulated by enclosing it in
single quotes), and indents the text after the @item line by 4 spaces.
Therefore, if the indentation and the general formatting of @table is
okay with you, I think the following will look better:

    +@table @asis
    +@item @code{N_SO_AS} (0x1)
    +Assembly language
    +@item @code{N_SO_C} (0x2)
    +K&R traditional C

etc., you get the point.  This typesets only the N_SO_* symbols as
@code, and also emphasizes the symbolic names rather than the numeric
values, which I think is what we want.

Thanks.

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Andrew Cagney]

>> I knew I forgot something:  Testing.
> 
> 
> Can this be turned into a proper testcase?  gdb.stabs/ I guess?  The last thing we want is to accidently break this.

Jason,

just so we're all on the same page here, this is a task for the 
contributor[s] and not the testsuite maintainer (MichaelC is busy enough 
without also implementing these testcases :-).

I'd actually submit the testcase separatly, and even first, I think 
you'll find it gets reviewed promptly.

Andrew

Re: RFA/patch stabs reader: Recognize language hint in SO stab

[Jason Molenda]

On Aug 24, 2004, at 1:44 PM, Andrew Cagney wrote:

>>> I knew I forgot something:  Testing.
>> Can this be turned into a proper testcase?  gdb.stabs/ I guess?  The 
>> last thing we want is to accidently break this.
>
> Jason,
>
> just so we're all on the same page here, this is a task for the 
> contributor[s] and not the testsuite maintainer (MichaelC is busy 
> enough without also implementing these testcases :-).


See, my silent answer to his question was "No".  So we can move on, 
right?  :)


J

Re: RFA/doc-patch stabs reader: Recognize language hint in SO stab

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Fri, Aug 06, 2004 at 11:51:32AM +0300, Eli Zaretskii wrote:
> > From: Jason Molenda <jmolenda@apple.com>
> > Date: Thu, 5 Aug 2004 13:09:08 -0700
> > 
> > Eli, I added a table documenting these values to stabs.texinfo.  Do you 
> > think this is a correct use of a texinfo table?

[...]

> Therefore, if the indentation and the general formatting of @table is
> okay with you, I think the following will look better:
> 
>     +@table @asis
>     +@item @code{N_SO_AS} (0x1)
>     +Assembly language
> 
> etc., you get the point.  


Thanks for the feedback, Eli.  Attached is an updated patch to the
documentation.  The FSF has just accepted the generation of this
code, the original patch posted here:

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00917.html

And approved here:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01572.html

So I'd like to get the documentation checked in to gdb, at least.
Can you approve this?  The patch goes through makeinfo and texi2html
without any warnings; the generated HTML looks fine.

Thanks.

Jason
(sending from my molenda.com acct instead of apple.com because of
irrelevant/uninteresting technical difficulties.)

2004-09-20  Jason Molenda  (jason-cl@molenda.com)

	* stabs.texinfo (Paths and Names of the Source Files): Document the
	meaning of values in the 'desc' field of a SO stab.

[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 1532 bytes --]

Index: stabs.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/stabs.texinfo,v
retrieving revision 1.15
diff -u -p -r1.15 stabs.texinfo
--- stabs.texinfo	14 Jun 2004 22:26:34 -0000	1.15
+++ stabs.texinfo	20 Sep 2004 19:21:10 -0000
@@ -422,9 +422,33 @@ file.  This information is contained in 
 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
+Some compilers use the desc field to indicate the language of the
+source file.  Sun's compilers started this usage, and the first
+constants are derived from their documentation.  Languages added
+by gcc/gdb start at 0x32 to avoid conflict with languages Sun may
+add in the future.  A desc field with a value 0 indicates that no
+language has been specified via this mechanism.
+
+@table @asis
+@item @code{N_SO_AS} (0x1)
+Assembly language
+@item @code{N_SO_C}  (0x2)
+K&R traditional C
+@item @code{N_SO_ANSI_C} (0x3)
+ANSI C
+@item @code{N_SO_CC}  (0x4)
+C++
+@item @code{N_SO_FORTRAN} (0x5)
+Fortran
+@item @code{N_SO_PASCAL} (0x6)
+Pascal
+@item @code{N_SO_FORTRAN90} (0x7)
+Fortran90
+@item @code{N_SO_OBJC} (0x32)
+Objective-C
+@item @code{N_SO_OBJCPLUS} (0x33)
+Objective-C++
+@end table
 
 Some compilers (for example, GCC2 and SunOS4 @file{/bin/cc}) also
 include the directory in which the source was compiled, in a second

Re: RFA/doc-patch stabs reader: Recognize language hint in SO stab

[Eli Zaretskii]

> Date: Mon, 20 Sep 2004 12:28:12 -0700
> From: Jason Molenda <jason-swarelist@molenda.com>
> Cc: gdb-patches@sources.redhat.com, jimb@redhat.com, kettenis@jive.nl,
>   dpatel@apple.com
> 
> So I'd like to get the documentation checked in to gdb, at least.
> Can you approve this?  The patch goes through makeinfo and texi2html
> without any warnings; the generated HTML looks fine.

Approved.  Please commit this.

Thanks.

Re: COMMITTED/doc-patch stabs reader: Recognize language hint in SO stab

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Tue, Sep 21, 2004 at 06:41:05AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 20 Sep 2004 12:28:12 -0700
> > From: Jason Molenda <jason-swarelist@molenda.com>
> > Cc: gdb-patches@sources.redhat.com, jimb@redhat.com, kettenis@jive.nl,
> >   dpatel@apple.com
> > 
> > So I'd like to get the documentation checked in to gdb, at least.
> > Can you approve this?  The patch goes through makeinfo and texi2html
> > without any warnings; the generated HTML looks fine.
> 
> Approved.  Please commit this.

Thanks, done.

J

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1716 bytes --]

2004-09-21  Jason Molenda  (jmolenda@apple.com)

        * gdb.texinfo (Paths and Names of the Source Files): Document the
        meaning of values in the 'desc' field of a SO stab.

Index: stabs.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/stabs.texinfo,v
retrieving revision 1.15
diff -u -p -r1.15 stabs.texinfo
--- stabs.texinfo	14 Jun 2004 22:26:34 -0000	1.15
+++ stabs.texinfo	21 Sep 2004 20:59:49 -0000
@@ -422,9 +422,33 @@ file.  This information is contained in 
 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
+Some compilers use the desc field to indicate the language of the
+source file.  Sun's compilers started this usage, and the first
+constants are derived from their documentation.  Languages added
+by gcc/gdb start at 0x32 to avoid conflict with languages Sun may
+add in the future.  A desc field with a value 0 indicates that no
+language has been specified via this mechanism.
+
+@table @asis
+@item @code{N_SO_AS} (0x1)
+Assembly language
+@item @code{N_SO_C}  (0x2)
+K&R traditional C
+@item @code{N_SO_ANSI_C} (0x3)
+ANSI C
+@item @code{N_SO_CC}  (0x4)
+C++
+@item @code{N_SO_FORTRAN} (0x5)
+Fortran
+@item @code{N_SO_PASCAL} (0x6)
+Pascal
+@item @code{N_SO_FORTRAN90} (0x7)
+Fortran90
+@item @code{N_SO_OBJC} (0x32)
+Objective-C
+@item @code{N_SO_OBJCPLUS} (0x33)
+Objective-C++
+@end table
 
 Some compilers (for example, GCC2 and SunOS4 @file{/bin/cc}) also
 include the directory in which the source was compiled, in a second