This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]