home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!sdd.hp.com!mips!swrinde!elroy.jpl.nasa.gov!nntp-server.caltech.edu!eql.caltech.edu!rankin
- From: rankin@eql.caltech.edu (Pat Rankin)
- Newsgroups: vmsnet.misc
- Subject: Re: Bug in GAS inhibits DEBUGger functioning.
- Message-ID: <12AUG199220053212@eql.caltech.edu>
- Date: 13 Aug 92 03:05:00 GMT
- References: <1992Aug11.112127.4423@dmc.com>
- Sender: news@cco.caltech.edu
- Followup-To: vmsnet.misc
- Organization: California Institute of Technology
- Lines: 42
- News-Software: VAX/VMS VNEWS 1.41
- Nntp-Posting-Host: eql.caltech.edu
-
- In article <1992Aug11.112127.4423@dmc.com>, munroe@dmc.com (Dick Munroe) writes...
- > I keep seeing the following messages from GAS:
- >
- > gcc-as warning(debugger output):Forward reference error, dbx type 54
- > gcc-as warning(debugger output):Forward reference error, dbx type 59
- > gcc-as warning(debugger output):Unable to resolve 1 circular references.
- >
- > Which make the debugger unusable for that module. (When the image is run,
- > it complains of badly nested DST records, which would figure).
- >
- > Is this a known bug in GAS? I'm using the GCC 1.40C and G++ 2.2.2 kits.
- > Are there later versions? Is there a fix? I haven't been able to reduce
- > it to a simple case yet, but if someone wants to tackle the debugging
- > I'll see if I can't get something simple to cause the condition.
-
- The problem is caused by gcc2 (or gas's failure to honor the code
- generated by gcc2); gcc 1.40 does not exhibit those symptoms, at least for
- the situation I recently encountered it and the test case I've produced.
- --
- struct oops {
- union {
- long q_rdt[2];
- struct { unsigned long l_rdt0; long l_rdt4; } r_rdt_fields;
- } r_rdt_overlay;
- union {
- long q_cdt[2];
- struct { unsigned long l_cdt0; long l_cdt4; } r_cdt_fields;
- } r_cdt_overlay;
- };
-
- int foo(void) { return 0; }
- --
- That gives a complaint about forward reference for dbx type 18. (Those
- numbers will vary depending on the data structures in your program and
- the order gcc encounters them.) This test is derived from <xabdatdef.h>;
- as a temporary work-around you might try suppressing or altering it if
- you happen to be using `#include <rms.h>' but don't need $xabdat. Of
- course other code could cause gcc to generate similar offending .stabs
- directives, particularly if you're dealing with the structures and unions
- generated by UNSDL for assorted VMS data structures.
-
- Pat Rankin, rankin@eql.caltech.edu
-