Article View: gnu.gdb.bug
Article #639Incompatibility between gdb 2.7 and gcc-1.30
From: Jonathan
Date: Sun, 18 Dec 1988 01:40
Date: Sun, 18 Dec 1988 01:40
36 lines
1704 bytes
1704 bytes
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??
Technical Details
Message-ID:
<8812180140.AA29027@comp.vuw.ac.nz>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!comp.vuw.ac.nz!jonathanShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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