Date: Wed, 10 Dec 1997 17:17:52 -0800 (PST)
Message-Id: <199712110117.RAA12532@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, Calvin French <frenchc AT cadvision DOT com>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: RHIDE Debugging Idea...
Cc: djgpp AT delorie DOT com
Precedence: bulk

At 11:13  12/10/1997 +0200, Eli Zaretskii wrote:
>
>On 9 Dec 1997, Calvin French wrote:
>
>> if( key[ KEY_SPACE ] )
>> {
>>    int a = 0;
>> };
>> 
>> And that's all. Then what I do, is set a breakpoint on the line, int a = 0. 
>> Then, I can run my program until a peculiar behavior occurs, at which point
>> I can just press space, and then debug effectively.
>
>It is not entirely clear to me how does this work for you, perhaps
>because I don't know enough about Allegro.  As far as I understand,
>when you press SPACE, the program is stopped at the above line.  What
>I don't understand is how does this let you ``debug effectively''.
>There's nothing in that code that ensures you can look at any place
>that is not directly related to that line.  The trouble that you want
>to debug might happen elsewhere, and there's no simple means of
>getting to the trouble spot, or even knowing where it is.  (Yes, I
>know about frame-related commands in the debugger, but I still don't
>see how that will help you know where the problem occured.)
I would assume it's a game-type of program, and the necessary state is
stored either in globals or in locals of a top-level function. When he stops
the program, he can look at all the variables and find out what's going on.
But I think he wanted some other way to have a breakpoint than the
debugger's facility, mainly for the convenience of not having to re-set it
when he deletes all breakpoints.
>Also, if you compile with optimizations, the optimizer has every right
>to optimize that snippet out of existence.
Right. Which is why you should never use optimizations on code you plan to
debug.
>
>> So what I really want to know is if there is an interrupt or something
>> else I can pull to cause RHIDE to behave as if it just hit a breakpoint.
>
>Isn't signals what you are after?  For example, you could put a signal
>handler for SIGINT into your code, and then whenever you hit Ctrl-BREAK, 
>you should land in your handler.  I even think the debugger should do
>that already (i.e., if you press Ctrl-BREAK, the debugger gets
>control), doesn't it?
That's a good idea, too. Wish I'd thought of it :) Yes, it does work.

Nate Eldredge
eldredge AT ap DOT net