[Prev][Next][Index]

Re: debugging problem




On Wed, 3 Aug 1994, Pete Beckman wrote,

>I can help you with part of your question:
>
>> when using dbx(or xdbx) for sage, I got
>> the following message:
>> 
>> Reading symbolic information...
>> warning: old style symbol information found in "lc.C"
>> dbx: internal error: unexpected value 38 at line 2620 in file ../common/object.c
>> 
>> As a result, I can't use the debuger.
>
>We have had that problem before.  I *think* it was on our Sun Sparcs.
>The problem seems to be that Sun's dbx cannot read the C++ symbol and
>source information.  Using gdb solved the problem.  The internal error
>is from dbx, not our code.  You can either compile and debug on a
>different architecture, or use gdb.
>
>-Pete
>

gdb works! It really helps. Thanks.

On Wed, 03 Aug 1994, Andrew Mauer wrote,

>> The other question is that , is there an easy way to refer to the original
>> statement id? As you know, the id() changes after restructuring.
>                                                    ^^^^^^^^^^^^^
>
>The ID changes after saving the output to a dep file
>(SgFile::saveDepFile()). Unless it is impossible to delay the saving
>until the last thing your program does, I would just do that.
>
>If this is not the problem you were referring to, please explain
>again, maybe with an example so we can see what is going on. The
>statement IDs should not change at any other point.
>
>/Andrew/
>

I checked again. It's my fault. I used unparsestdout() one time before
the printing of statement id, another time after the id. This mixed things
up. Sorry for that.

I really appreciate your promopt responses. They do help a lot.

-yang