This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] deleting breakpoints inside of 'commands'
- To: <gdb at sources dot redhat dot com>
- Subject: Re: [RFA] deleting breakpoints inside of 'commands'
- From: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- Date: Thu, 13 Sep 2001 09:52:17 +0200
- Cc: Don Howard <dhoward at redhat dot com>
- References: <Pine.LNX.4.33.0109111057120.1364-100000@theotherone>
At 10:37 12/09/01 , vous avez écrit:
>At 00:37 12/09/01 , vous avez écrit:
>
>
>>The following patch addresses a core-dump that occurs when a 'commands'
>>script deletes the current breakpoint:
>>
>>(gdb) commands
>> >clear
>> >step
>> >end
>>(gdb) break foo
>>(gdb) continue
>> .
>> .
>> .
>>warning: Invalid control type in command structure.
>>Segmentation fault (core dumped)
>>
>>What happens is the breakpoint (and the associated 'commands' script) is
>>deleted when first statement of the script is executed. GDB runs into a
>>core dump when it attempts to execute the remaining (deleted)
>>statements.
>>
>>The patch below detects if the current breakpoint has been deleted and
>>terminates execution of the associated 'commands' script and issues a
>>warning.
>
> Wouldn't it seem more logical to
>isolate the commands temporarily,
>by resetting the commands field to NULL ?
>
> headcmd = bs->commands;
>+ bs->commands = NULL;
>+ cmd = headcmd;
> while (cmd != NULL)
>
> This would allow to execute the whole
>command sequences to its end.
> At end of the commands,
>the commands field should be restored if
>the breakpoint has not been distroyed,
>otherwise headcmd should be disposed.
>
> This seems a much more reasonable action scheme
>to me.
>
> Otherwise the command parser should at least warn
>if any commands are given past a
>'clear' or 'delete breakpoint-number',
>but this will anyhow not be possible if
>the 'delete' argument is an expression that is not a simple constant.
Just a remark to say that I realized that my suggestion
also has troubles:
If you imagine that
b func1
command 1
p arg1
command 1
p arg2
end
end
This command should normally print arg1 the first time func1 is hit,
and arg2 afterwards.
But my suggestion above doesn't handle this !
Of course it should be easy to add a check to test if
the bs->commands still is NULL before restoring
the old value, but this will not be enough,
because it would probably fail in case of
b func1
command 1
p arg1
command 1
end
end
where the command is reset after the first hit.
A possible solution is to create a dummy bs->commands
and to check if it has been change.
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99