This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
cfront and read_dbx_symtab (dbxread.c)
- From: David Taylor <dtaylor at emc dot com>
- To: gdb at sources dot redhat dot com
- Cc: ezannoni at redhat dot com
- Date: Fri, 18 Jul 2003 14:31:42 -0400
- Subject: cfront and read_dbx_symtab (dbxread.c)
In function read_dbx_symtab (file dbxread.c), in the N_SO case you'll
find this comment:
/* 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. */
I believe that the 'other compilers' being referred to are cfront.
Are there any besides cfront?
[In the stabs.texinfo file discussion of the N_SO stabs, you'll find the comment:
Code from the cfront C++ compiler can have additional N_SO symbols for
nonexistent source files after the N_SO for the real source file;
these are believed to contain no useful information.
]
GAS will sometimes legitimately emit two adjacent N_SO stabs.
For example, suppose you invoke GAS like:
$(GAS) <some options> -gstabs defines.s code.s -o outputfile.o
where defines.s contains no actual instructions -- just macro
definitions and .set's.
GDB currently deals poorly with this -- everything in outputfile.o is
attributed to the source file mentioned in the first N_SO --
defines.s, nothing is attributed to code.s.
I feel that the proper fix is to not ignore the subsequent N_SO stabs
-- i.e. do an end_psymtab / start_psymtab..
There are two potential problems with that solution:
. while EMC has a copyright assignment on file for GDB, it only covers
selected files -- and dbxread.c isn't one of them. While I am
trying to convince them to change it to include all of GDB's file
(and GCC and ...), that hasn't happened yet.
So, such a solution would have to either be done by someone else or
would have to wait
. while I belive that cfront was the 'compiler' responsible for the
aforementioned comment, there could potentially be others.
[If people feel confident that there are no longer any compilers we
care about that emit such N_SO's and that the change will be small
enough to not be copyright-able, then I will gladly implement it.]
In the meantime, I'd like to get in a lesser fix -- move the line:
prev_so_symnum = symnum;
to right after the lines:
/* End the current partial symtab and start a new one */
namestring = set_namestring (objfile, nlist);
/* Null name means end of .o file. Don't start a new one. */
if (*namestring == '\000')
continue;
That way,
N_SO defines.s
N_SO 0
N_SO code.s
<<other stabs>>
will work (next: teach GAS to emit N_SO 0's...).
I believe that this has no downside and is small enough that it
doesn't need a copyright assignment.
Comments?
David
--
David Taylor
dtaylor@emc.com (work), taylor@candd.org (home)