* cfront and read_dbx_symtab (dbxread.c)
@ 2003-07-18 18:31 David Taylor
0 siblings, 0 replies; only message in thread
From: David Taylor @ 2003-07-18 18:31 UTC (permalink / raw)
To: gdb; +Cc: ezannoni
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)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2003-07-18 18:31 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-18 18:31 cfront and read_dbx_symtab (dbxread.c) David Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).