public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* 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).