Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!comp.vuw.ac.nz!jonathan
From: jonathan@comp.vuw.ac.nz (Jonathan)
Newsgroups: gnu.gdb.bug
Subject: Incompatibility between gdb 2.7 and gcc-1.30
Message-ID: <8812180140.AA29027@comp.vuw.ac.nz>
Date: 18 Dec 88 01:40:40 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 36

Symptom::
    Gdb 2.7 exits when trying to read symbols from a Pyramid gcc-1.30
    stageN, N > 2.  It encounters a symbol definition it doesn't understand.

Repeat-By::
    Dunno, unless you have a copy of the Pyramid machine description.

Diagnosis::
    Gcc 1.30 appears to occasionally produce output debugging
    information that gdb 2.7 doesn't grok. 
    This happens for pointer parameters passed in registers instead of
    on the stack.

    I found this with my own gcc/gdb machine descriptions for Pyramid
    Technology processors some time ago. Perhaps it's been fixed
    already for SPARC? 
    If not, the code in gcc/dbxout.c producing the contentious output is:

	  current_sym_nchars = 2 + strlen (IDENTIFIER_POINTER (DECL_NAME (parms)));

	  fprintf (asmfile, ".stabs \"%s:P",
		   IDENTIFIER_POINTER (DECL_NAME (parms)));

	  dbxout_type (DECL_ARG_TYPE (parms), 0);
	  dbxout_finish_symbol ();

    Gdb 2.7 has no idea how do deal with such a symbol (ie, an N_RSYM
    with code 'P').


Fix-By::
    I'm not sure whether gcc is correct in doing this, and if so, what
    gdb should do with it.  I merely #ifdef'ed the gcc source to output a
    'p' instead of a 'P', which isn't entirely satisfactory.

    Which should be/has been fixed, gdb or gcc?  Or both??