From: Jason Molenda <jmolenda@apple.com>
To: gdb-patches@sources.redhat.com
Cc: Jim Blandy <jimb@redhat.com>, Mark Kettenis <kettenis@jive.nl>,
Eli Zaretskii <eliz@elta.co.il>, Devang Patel <dpatel@apple.com>
Subject: RFA/patch stabs reader: Recognize language hint in SO stab
Date: Thu, 05 Aug 2004 20:08:00 -0000 [thread overview]
Message-ID: <4F2AF76A-E71B-11D8-B4BD-000A9569836A@apple.com> (raw)
[-- 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
next reply other threads:[~2004-08-05 20:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-05 20:08 Jason Molenda [this message]
2004-08-05 20:17 ` Jason Molenda
2004-08-05 20:55 ` Andrew Cagney
2004-08-24 20:45 ` Andrew Cagney
2004-08-25 1:05 ` Jason Molenda
2004-08-05 21:10 ` Michael Chastain
2004-08-06 8:54 ` Eli Zaretskii
2004-09-20 19:28 ` RFA/doc-patch " Jason Molenda
2004-09-21 3:43 ` Eli Zaretskii
2004-09-21 21:08 ` COMMITTED/doc-patch " Jason Molenda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F2AF76A-E71B-11D8-B4BD-000A9569836A@apple.com \
--to=jmolenda@apple.com \
--cc=dpatel@apple.com \
--cc=eliz@elta.co.il \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
--cc=kettenis@jive.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox