* Patch ping
@ 2004-05-27 13:07 Paul Brook
2004-05-27 21:20 ` Jason Molenda
2004-05-28 23:37 ` Jim Blandy
0 siblings, 2 replies; 26+ messages in thread
From: Paul Brook @ 2004-05-27 13:07 UTC (permalink / raw)
To: gdb-patches
I submitted the following patch a couple of weeks a go and it seems to have
slipped past without review...
http://sources.redhat.com/ml/gdb-patches/2004-05/msg00351.html
Paul
^ permalink raw reply [flat|nested] 26+ messages in thread
* patch ping
@ 2016-09-14 19:27 Tom Tromey
2016-09-27 17:38 ` Tom Tromey
0 siblings, 1 reply; 26+ messages in thread
From: Tom Tromey @ 2016-09-14 19:27 UTC (permalink / raw)
To: gdb-patches; +Cc: tmielczarek
I was talking with a fellow Mozillian today and found out that this
patch was never reviewed:
https://sourceware.org/ml/gdb-patches/2015-05/msg00132.html
Ping.
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread
* Patch ping
@ 2008-07-10 19:34 Tom Tromey
0 siblings, 0 replies; 26+ messages in thread
From: Tom Tromey @ 2008-07-10 19:34 UTC (permalink / raw)
To: gdb-patches
Hi, time for a patch ping.
This is the second ping for the rewrite of the 'macro' patch. This
patch implements the missing-but-documented 'macro' subcommands:
http://sourceware.org/ml/gdb-patches/2008-06/msg00086.html
This is the first ping for the patch to fix up 'help' completion.
I may be pinging this slightly early... next Monday will be 2 weeks.
http://sourceware.org/ml/gdb-patches/2008-06/msg00589.html
Also, if someone could try out this dependency-tracking patch on a
non-GNU-make, I would be happy to port it to the trunk, write a
ChangeLog entry, and propose it for real:
http://sourceware.org/ml/gdb/2008-06/msg00312.html
thanks,
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread
* Patch ping
@ 2004-04-30 16:27 Ulrich Weigand
2004-04-30 17:33 ` Andrew Cagney
2004-04-30 22:26 ` Jim Blandy
0 siblings, 2 replies; 26+ messages in thread
From: Ulrich Weigand @ 2004-04-30 16:27 UTC (permalink / raw)
To: gdb-patches
[PATCH] Fix RT signal frames on s390
http://sources.redhat.com/ml/gdb-patches/2004-04/msg00572.html
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 16:27 Ulrich Weigand
@ 2004-04-30 17:33 ` Andrew Cagney
2004-04-30 18:13 ` Ulrich Weigand
2004-04-30 22:26 ` Jim Blandy
1 sibling, 1 reply; 26+ messages in thread
From: Andrew Cagney @ 2004-04-30 17:33 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
> [PATCH] Fix RT signal frames on s390
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00572.html
What's the status of this ...
> [B.t.w. we have now gotten the approval for a full 'future'
> copyright assignment for gdb; the letter was already sent
> to the FSF copyright clerk. This should simplify future
> patches, I hope ... ]
?
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 17:33 ` Andrew Cagney
@ 2004-04-30 18:13 ` Ulrich Weigand
2004-04-30 22:19 ` Jim Blandy
2004-05-02 20:49 ` Andrew Cagney
0 siblings, 2 replies; 26+ messages in thread
From: Ulrich Weigand @ 2004-04-30 18:13 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ulrich Weigand, gdb-patches
Andrew Cagney wrote:
> What's the status of this ...
> > [B.t.w. we have now gotten the approval for a full 'future'
> > copyright assignment for gdb; the letter was already sent
> > to the FSF copyright clerk. This should simplify future
> > patches, I hope ... ]
This is my latest news:
>----- Forwarded by Christoph Arenz/Germany/IBM on 29.04.2004 15:37 -----
>From: "Ted Teah via RT" <copyright-clerk@fsf.org>
>To: Christoph Arenz/Germany/IBM@IBMDE
>Subject: [gnu.org #188900] Re: Software Letter
>
>Christoph,
>
>Yes I have received the software letters. Thank you. I will be
>updating copyright.list shortly.
>
>All the best,
>Ted Teah
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 18:13 ` Ulrich Weigand
@ 2004-04-30 22:19 ` Jim Blandy
2004-04-30 22:51 ` Ulrich Weigand
2004-05-02 20:49 ` Andrew Cagney
1 sibling, 1 reply; 26+ messages in thread
From: Jim Blandy @ 2004-04-30 22:19 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Andrew Cagney, gdb-patches
Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:
> Andrew Cagney wrote:
>
> > What's the status of this ...
> > > [B.t.w. we have now gotten the approval for a full 'future'
> > > copyright assignment for gdb; the letter was already sent
> > > to the FSF copyright clerk. This should simplify future
> > > patches, I hope ... ]
>
> This is my latest news:
>
> >----- Forwarded by Christoph Arenz/Germany/IBM on 29.04.2004 15:37 -----
> >From: "Ted Teah via RT" <copyright-clerk@fsf.org>
> >To: Christoph Arenz/Germany/IBM@IBMDE
> >Subject: [gnu.org #188900] Re: Software Letter
> >
> >Christoph,
> >
> >Yes I have received the software letters. Thank you. I will be
> >updating copyright.list shortly.
> >
> >All the best,
> >Ted Teah
>
> Bye,
> Ulrich
What should I be looking for in copyright.list? The most recent
GDB & IBM-related entry I see is this:
GDB BINUTILS GLIBC GDB IBM 2004-03-29
Transfers work created by the following employees: Dwayne McConnell, Manoj Iyer, Uttam Pawar, Maynard Johnson, Craig Chaney, Pat Haugen, Keith Besaw, Steve Munroe, Ben Elliston.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 22:19 ` Jim Blandy
@ 2004-04-30 22:51 ` Ulrich Weigand
0 siblings, 0 replies; 26+ messages in thread
From: Ulrich Weigand @ 2004-04-30 22:51 UTC (permalink / raw)
To: Jim Blandy; +Cc: Ulrich Weigand, Andrew Cagney, gdb-patches
Jim Blandy wrote:
> What should I be looking for in copyright.list? The most recent
> GDB & IBM-related entry I see is this:
>
> GDB BINUTILS GLIBC GDB IBM 2004-03-29
> Transfers work created by the following employees: Dwayne McConnell, Manoj Iyer, Uttam Pawar, Maynard Johnson, Craig Chaney, Pat Haugen, Keith Besaw, Steve Munroe, Ben Elliston.
>
That's the previous one; there should be another one covering
all gdb, binutils, and glibc contributions by myself and
Martin Schwidefsky.
Maybe it's still in the pipeline ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 18:13 ` Ulrich Weigand
2004-04-30 22:19 ` Jim Blandy
@ 2004-05-02 20:49 ` Andrew Cagney
2004-05-01 19:48 ` Ulrich Weigand
1 sibling, 1 reply; 26+ messages in thread
From: Andrew Cagney @ 2004-05-02 20:49 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
Ulrich,
I'm waiting on an answer to a legal question. Once that's been
resolved, and we've seen the copyright list confirm that this has been
processed than your account can go through.
Sorry for the delay,
Andrew
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-05-02 20:49 ` Andrew Cagney
@ 2004-05-01 19:48 ` Ulrich Weigand
0 siblings, 0 replies; 26+ messages in thread
From: Ulrich Weigand @ 2004-05-01 19:48 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ulrich Weigand, gdb-patches
Andrew,
> I'm waiting on an answer to a legal question. Once that's been
> resolved, and we've seen the copyright list confirm that this has been
> processed than your account can go through.
Great, thanks!
> Sorry for the delay,
No problem ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2004-04-30 16:27 Ulrich Weigand
2004-04-30 17:33 ` Andrew Cagney
@ 2004-04-30 22:26 ` Jim Blandy
2004-05-01 15:41 ` Ulrich Weigand
1 sibling, 1 reply; 26+ messages in thread
From: Jim Blandy @ 2004-04-30 22:26 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gdb-patches
Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:
> [PATCH] Fix RT signal frames on s390
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00572.html
The patch looks fine. Sorry to keep you waiting.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Patch ping
@ 2002-05-13 11:06 Don Howard
2002-05-16 15:54 ` Jim Blandy
0 siblings, 1 reply; 26+ messages in thread
From: Don Howard @ 2002-05-13 11:06 UTC (permalink / raw)
To: Jim Blandy, Michael Snyder; +Cc: gdb-patches
I still need reveiw/approval for the breakpoint portion of this.
--
dhoward@redhat.com
gdb engineering
---------- Forwarded message ----------
Date: Sun, 28 Apr 2002 12:06:11 -0400
From: Fernando Nasser <fnasser@redhat.com>
To: Don Howard <dhoward@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Michael Snyder <msnyder@cygnus.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] deleting breakpoints inside of 'commands'
The CLI part is approved. This is somewhat mixed with breakpoints code
(in the breakpoint.c file) so Michael Snyder would have to approve it as
well.
Regards,
Fernando
Don Howard wrote:
>
> I'm revisiting this again, as I've not received feedback the last two
> times that I've reposted it.
>
> This patch addresses a crash that can occur when a breakpoint's command
> list deletes it's own breakpoint. In this solution, breakpoint command
> lists are walked (recursively, so as to examine compound statements and
> user defined commands). If a 'clear' or 'delete' command is found
> anywhere in the definition of the command list, then the command list is
> duplicated and that duplicate is executed. Once execution of the command
> list is complete, the duplicate is freed.
>
> This patch does not address any situation where a user defined command
> deletes itself. (is that even possible? I don't see a way to remove a
> user-defined command, only a way to redefine one.)
>
> This version of contains 2 corrections to
> bpstat_actions_delete_breakpoints()
>
> 1) The call to lookup_cmd() allows unknown commands.
>
> 2) The body of the command is examined regardless of the result of
> lookup_cmd().
>
> Testing on i686 RH 7.2 shows no regressions:
>
> === gdb Summary ===
>
> # of expected passes 8272
> # of unexpected failures 31
> # of unexpected successes 11
> # of expected failures 170
> # of untested testcases 7
> /home/dhoward/work/sources/build/gdb/testsuite/../../gdb/gdb version
> 2002-04-27-cvs -nx
>
> After:
> === gdb Summary ===
>
> # of expected passes 8272
> # of unexpected failures 31
> # of unexpected successes 11
> # of expected failures 170
> # of untested testcases 7
> /home/dhoward/work/sources/rebuild/gdb/testsuite/../../gdb/gdb version
> 2002-04-27-cvs -nx
>
> Comments?
>
> Ok to commit?
>
> 2002-04-27 Don Howard <dhoward@redhat.com>
>
> * breakpoint.c (bpstat_do_actions): Avoid deleting a 'commands'
> list while executing that list. Thanks to Pierre Muller
> <muller@ics.u-strasbg.fr> for suggesting this implementation.
> (cleanup_dup_command_lines): New function.
> (bpstat_actions_delete_breakpoints): Ditto.
> * cli/cli-script.c (dup_command_lines): New function.
> * defs.h: Added declaration of new function.
>
> Index: gdb/breakpoint.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/breakpoint.c,v
> retrieving revision 1.74
> diff -p -u -w -r1.74 breakpoint.c
> --- gdb/breakpoint.c 24 Apr 2002 16:28:15 -0000 1.74
> +++ gdb/breakpoint.c 27 Apr 2002 19:18:57 -0000
> @@ -47,6 +47,7 @@
> #include "ui-out.h"
>
> #include "gdb-events.h"
> +#include "cli/cli-decode.h"
>
> /* Prototypes for local functions. */
>
> @@ -1851,6 +1852,100 @@ cleanup_executing_breakpoints (PTR ignor
> executing_breakpoint_commands = 0;
> }
>
> +static void
> +cleanup_dup_command_lines (PTR cmds)
> +{
> + free_command_lines (cmds);
> +}
> +
> +
> +/* Walk a list of struct command_lines and try to determine if any
> + command deletes breakpoints */
> +
> +static int
> +bpstat_actions_delete_breakpoints (struct command_line * cmd)
> +{
> + for (; cmd; cmd = cmd->next)
> + {
> + struct cmd_list_element *ce;
> + char *line = cmd->line;
> + int i;
> + int ret;
> +
> + ce = lookup_cmd (&line, cmdlist, "", 1, 1);
> +
> + if (ce != NULL)
> + {
> + /* Check the command */
> + if (ce->class == class_user && !ce->hook_in)
> + {
> + ce->hook_in = 1;
> + ret = bpstat_actions_delete_breakpoints (ce->user_commands);
> + ce->hook_in = 0;
> +
> + if (ret)
> + return 1;
> + }
> + else if (strcmp (ce->name, "delete") == 0
> + || strcmp (ce->name, "clear") == 0)
> + {
> + return 1;
> + }
> +
> +
> + /* Check the pre-hook */
> + if (ce->hook_pre)
> + {
> + if (ce->hook_pre->class == class_user && !ce->hook_in)
> + {
> + ce->hook_in = 1;
> + ret = bpstat_actions_delete_breakpoints (ce->hook_pre->user_commands);
> + ce->hook_in = 0;
> +
> + if (ret)
> + return 1;
> + }
> + else if (strcmp (ce->hook_pre->name, "delete") == 0
> + || strcmp (ce->hook_pre->name, "clear") == 0)
> + {
> + return 1;
> + }
> + }
> +
> +
> + /* Check the post-hook */
> + if (ce->hook_post)
> + {
> + if (ce->hook_post->class == class_user && !ce->hook_in)
> + {
> + ce->hook_in = 1;
> + ret = bpstat_actions_delete_breakpoints (ce->hook_post->user_commands);
> + ce->hook_in = 0;
> +
> + if (ret)
> + return 1;
> + }
> + else if (strcmp (ce->hook_post->name, "delete") == 0
> + || strcmp (ce->hook_post->name, "clear") == 0)
> + {
> + return 1;
> + }
> + }
> + }
> +
> + /* If this is a multi-part command (while, if, etc), check the
> + body. */
> + for (i=0; i<cmd->body_count; i++)
> + if (bpstat_actions_delete_breakpoints (cmd->body_list[i]))
> + return 1;
> +
> + }
> +
> + return 0;
> +
> +}
> +
> +
> /* Execute all the commands associated with all the breakpoints at this
> location. Any of these commands could cause the process to proceed
> beyond this point, etc. We look out for such changes by checking
> @@ -1861,7 +1956,6 @@ bpstat_do_actions (bpstat *bsp)
> {
> bpstat bs;
> struct cleanup *old_chain;
> - struct command_line *cmd;
>
> /* Avoid endless recursion if a `source' command is contained
> in bs->commands. */
> @@ -1886,16 +1980,37 @@ top:
> breakpoint_proceeded = 0;
> for (; bs != NULL; bs = bs->next)
> {
> - cmd = bs->commands;
> - while (cmd != NULL)
> + struct command_line *cmd;
> + struct cleanup *new_old_chain;
> +
> + cmd = 0;
> + new_old_chain = 0;
> +
> + /* If the command list for this breakpoint includes a statement
> + that deletes breakpoints, we assume that the target may be
> + this breakpoint, so we make a copy of the command list to
> + avoid walking a list that has been deleted. */
> +
> + for (cmd = bs->commands; cmd; cmd = cmd->next)
> + {
> + if (!new_old_chain && bpstat_actions_delete_breakpoints (cmd))
> {
> + cmd = dup_command_lines (cmd);
> + new_old_chain = make_cleanup (cleanup_dup_command_lines, cmd);
> + }
> +
> execute_control_command (cmd);
>
> if (breakpoint_proceeded)
> break;
> - else
> - cmd = cmd->next;
> }
> +
> + if (new_old_chain)
> + {
> + free_command_lines (&cmd);
> + discard_cleanups (new_old_chain);
> + }
> +
> if (breakpoint_proceeded)
> /* The inferior is proceeded by the command; bomb out now.
> The bpstat chain has been blown away by wait_for_inferior.
> @@ -1905,6 +2020,7 @@ top:
> else
> bs->commands = NULL;
> }
> +
>
> executing_breakpoint_commands = 0;
> discard_cleanups (old_chain);
> Index: gdb/defs.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/defs.h,v
> retrieving revision 1.88
> diff -p -u -w -r1.88 defs.h
> --- gdb/defs.h 18 Apr 2002 18:08:59 -0000 1.88
> +++ gdb/defs.h 27 Apr 2002 19:18:57 -0000
> @@ -641,6 +641,7 @@ struct command_line
> extern struct command_line *read_command_lines (char *, int);
>
> extern void free_command_lines (struct command_line **);
> +extern struct command_line * dup_command_lines (struct command_line *);
>
> /* To continue the execution commands when running gdb asynchronously.
> A continuation structure contains a pointer to a function to be called
> Index: gdb/cli/cli-script.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/cli/cli-script.c,v
> retrieving revision 1.12
> diff -p -u -w -r1.12 cli-script.c
> --- gdb/cli/cli-script.c 12 Apr 2002 22:31:23 -0000 1.12
> +++ gdb/cli/cli-script.c 27 Apr 2002 19:18:58 -0000
> @@ -974,6 +974,59 @@ read_command_lines (char *prompt_arg, in
> return (head);
> }
>
> +/* Duplicate a chain of struct command_line's */
> +
> +struct command_line *
> +dup_command_lines (struct command_line *l)
> +{
> + struct command_line *dup = NULL;
> + register struct command_line *next = NULL;
> +
> +
> + for (; l ; l = l->next)
> + {
> + if (next == NULL)
> + {
> + dup = next = (struct command_line *)
> + xmalloc (sizeof (struct command_line));
> + }
> + else
> + {
> + next->next = (struct command_line *)
> + xmalloc (sizeof (struct command_line));
> +
> + next = next->next;
> + }
> +
> +
> + if (next == NULL)
> + return NULL;
> +
> +
> + next->next = NULL;
> + next->line = xstrdup (l->line);
> + next->control_type = l->control_type;
> + next->body_count = l->body_count;
> +
> +
> + if (l->body_count > 0)
> + {
> + int i;
> + struct command_line **blist = l->body_list;
> +
> + next->body_list =
> + (struct command_line **) xmalloc (sizeof (struct command_line *)
> + * l->body_count);
> +
> + for (i = 0; i < l->body_count; i++, blist++)
> + next->body_list[i] = dup_command_lines (*blist);
> + }
> + }
> +
> + return dup;
> +}
> +
> +
> /* Free a chain of struct command_line's. */
>
> void
>
> --
> dhoward@redhat.com
> gdb engineering
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Patch ping
2002-05-13 11:06 Don Howard
@ 2002-05-16 15:54 ` Jim Blandy
0 siblings, 0 replies; 26+ messages in thread
From: Jim Blandy @ 2002-05-16 15:54 UTC (permalink / raw)
To: Don Howard; +Cc: Michael Snyder, gdb-patches
I'm sorry it's taken a long time to get to this patch.
Scanning for commands that could delete breakpoints doesn't seem very
robust. If I add a new command that happens to delete breakpoints,
this won't catch that, right?
Why not add a reference count field to struct command_line? It would
be set to 1 when allocated. You'd increment it when you begin
executing a command list, and decrement it when you were done, or
aborted execution due to an error. You'd also decrement it when the
breakpoint gets deleted.
I think it might be less code overall.
Don Howard <dhoward@redhat.com> writes:
> I still need reveiw/approval for the breakpoint portion of this.
>
>
>
> --
> dhoward@redhat.com
> gdb engineering
>
>
> ---------- Forwarded message ----------
> Date: Sun, 28 Apr 2002 12:06:11 -0400
> From: Fernando Nasser <fnasser@redhat.com>
> To: Don Howard <dhoward@redhat.com>
> Cc: Andrew Cagney <ac131313@cygnus.com>, Michael Snyder <msnyder@cygnus.com>,
> gdb-patches@sources.redhat.com
> Subject: Re: [RFA] deleting breakpoints inside of 'commands'
>
> The CLI part is approved. This is somewhat mixed with breakpoints code
> (in the breakpoint.c file) so Michael Snyder would have to approve it as
> well.
>
> Regards,
> Fernando
>
> Don Howard wrote:
> >
> > I'm revisiting this again, as I've not received feedback the last two
> > times that I've reposted it.
> >
> > This patch addresses a crash that can occur when a breakpoint's command
> > list deletes it's own breakpoint. In this solution, breakpoint command
> > lists are walked (recursively, so as to examine compound statements and
> > user defined commands). If a 'clear' or 'delete' command is found
> > anywhere in the definition of the command list, then the command list is
> > duplicated and that duplicate is executed. Once execution of the command
> > list is complete, the duplicate is freed.
> >
> > This patch does not address any situation where a user defined command
> > deletes itself. (is that even possible? I don't see a way to remove a
> > user-defined command, only a way to redefine one.)
> >
> > This version of contains 2 corrections to
> > bpstat_actions_delete_breakpoints()
> >
> > 1) The call to lookup_cmd() allows unknown commands.
> >
> > 2) The body of the command is examined regardless of the result of
> > lookup_cmd().
> >
> > Testing on i686 RH 7.2 shows no regressions:
> >
> > === gdb Summary ===
> >
> > # of expected passes 8272
> > # of unexpected failures 31
> > # of unexpected successes 11
> > # of expected failures 170
> > # of untested testcases 7
> > /home/dhoward/work/sources/build/gdb/testsuite/../../gdb/gdb version
> > 2002-04-27-cvs -nx
> >
> > After:
> > === gdb Summary ===
> >
> > # of expected passes 8272
> > # of unexpected failures 31
> > # of unexpected successes 11
> > # of expected failures 170
> > # of untested testcases 7
> > /home/dhoward/work/sources/rebuild/gdb/testsuite/../../gdb/gdb version
> > 2002-04-27-cvs -nx
> >
> > Comments?
> >
> > Ok to commit?
> >
> > 2002-04-27 Don Howard <dhoward@redhat.com>
> >
> > * breakpoint.c (bpstat_do_actions): Avoid deleting a 'commands'
> > list while executing that list. Thanks to Pierre Muller
> > <muller@ics.u-strasbg.fr> for suggesting this implementation.
> > (cleanup_dup_command_lines): New function.
> > (bpstat_actions_delete_breakpoints): Ditto.
> > * cli/cli-script.c (dup_command_lines): New function.
> > * defs.h: Added declaration of new function.
> >
> > Index: gdb/breakpoint.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/breakpoint.c,v
> > retrieving revision 1.74
> > diff -p -u -w -r1.74 breakpoint.c
> > --- gdb/breakpoint.c 24 Apr 2002 16:28:15 -0000 1.74
> > +++ gdb/breakpoint.c 27 Apr 2002 19:18:57 -0000
> > @@ -47,6 +47,7 @@
> > #include "ui-out.h"
> >
> > #include "gdb-events.h"
> > +#include "cli/cli-decode.h"
> >
> > /* Prototypes for local functions. */
> >
> > @@ -1851,6 +1852,100 @@ cleanup_executing_breakpoints (PTR ignor
> > executing_breakpoint_commands = 0;
> > }
> >
> > +static void
> > +cleanup_dup_command_lines (PTR cmds)
> > +{
> > + free_command_lines (cmds);
> > +}
> > +
> > +
> > +/* Walk a list of struct command_lines and try to determine if any
> > + command deletes breakpoints */
> > +
> > +static int
> > +bpstat_actions_delete_breakpoints (struct command_line * cmd)
> > +{
> > + for (; cmd; cmd = cmd->next)
> > + {
> > + struct cmd_list_element *ce;
> > + char *line = cmd->line;
> > + int i;
> > + int ret;
> > +
> > + ce = lookup_cmd (&line, cmdlist, "", 1, 1);
> > +
> > + if (ce != NULL)
> > + {
> > + /* Check the command */
> > + if (ce->class == class_user && !ce->hook_in)
> > + {
> > + ce->hook_in = 1;
> > + ret = bpstat_actions_delete_breakpoints (ce->user_commands);
> > + ce->hook_in = 0;
> > +
> > + if (ret)
> > + return 1;
> > + }
> > + else if (strcmp (ce->name, "delete") == 0
> > + || strcmp (ce->name, "clear") == 0)
> > + {
> > + return 1;
> > + }
> > +
> > +
> > + /* Check the pre-hook */
> > + if (ce->hook_pre)
> > + {
> > + if (ce->hook_pre->class == class_user && !ce->hook_in)
> > + {
> > + ce->hook_in = 1;
> > + ret = bpstat_actions_delete_breakpoints (ce->hook_pre->user_commands);
> > + ce->hook_in = 0;
> > +
> > + if (ret)
> > + return 1;
> > + }
> > + else if (strcmp (ce->hook_pre->name, "delete") == 0
> > + || strcmp (ce->hook_pre->name, "clear") == 0)
> > + {
> > + return 1;
> > + }
> > + }
> > +
> > +
> > + /* Check the post-hook */
> > + if (ce->hook_post)
> > + {
> > + if (ce->hook_post->class == class_user && !ce->hook_in)
> > + {
> > + ce->hook_in = 1;
> > + ret = bpstat_actions_delete_breakpoints (ce->hook_post->user_commands);
> > + ce->hook_in = 0;
> > +
> > + if (ret)
> > + return 1;
> > + }
> > + else if (strcmp (ce->hook_post->name, "delete") == 0
> > + || strcmp (ce->hook_post->name, "clear") == 0)
> > + {
> > + return 1;
> > + }
> > + }
> > + }
> > +
> > + /* If this is a multi-part command (while, if, etc), check the
> > + body. */
> > + for (i=0; i<cmd->body_count; i++)
> > + if (bpstat_actions_delete_breakpoints (cmd->body_list[i]))
> > + return 1;
> > +
> > + }
> > +
> > + return 0;
> > +
> > +}
> > +
> > +
> > /* Execute all the commands associated with all the breakpoints at this
> > location. Any of these commands could cause the process to proceed
> > beyond this point, etc. We look out for such changes by checking
> > @@ -1861,7 +1956,6 @@ bpstat_do_actions (bpstat *bsp)
> > {
> > bpstat bs;
> > struct cleanup *old_chain;
> > - struct command_line *cmd;
> >
> > /* Avoid endless recursion if a `source' command is contained
> > in bs->commands. */
> > @@ -1886,16 +1980,37 @@ top:
> > breakpoint_proceeded = 0;
> > for (; bs != NULL; bs = bs->next)
> > {
> > - cmd = bs->commands;
> > - while (cmd != NULL)
> > + struct command_line *cmd;
> > + struct cleanup *new_old_chain;
> > +
> > + cmd = 0;
> > + new_old_chain = 0;
> > +
> > + /* If the command list for this breakpoint includes a statement
> > + that deletes breakpoints, we assume that the target may be
> > + this breakpoint, so we make a copy of the command list to
> > + avoid walking a list that has been deleted. */
> > +
> > + for (cmd = bs->commands; cmd; cmd = cmd->next)
> > + {
> > + if (!new_old_chain && bpstat_actions_delete_breakpoints (cmd))
> > {
> > + cmd = dup_command_lines (cmd);
> > + new_old_chain = make_cleanup (cleanup_dup_command_lines, cmd);
> > + }
> > +
> > execute_control_command (cmd);
> >
> > if (breakpoint_proceeded)
> > break;
> > - else
> > - cmd = cmd->next;
> > }
> > +
> > + if (new_old_chain)
> > + {
> > + free_command_lines (&cmd);
> > + discard_cleanups (new_old_chain);
> > + }
> > +
> > if (breakpoint_proceeded)
> > /* The inferior is proceeded by the command; bomb out now.
> > The bpstat chain has been blown away by wait_for_inferior.
> > @@ -1905,6 +2020,7 @@ top:
> > else
> > bs->commands = NULL;
> > }
> > +
> >
> > executing_breakpoint_commands = 0;
> > discard_cleanups (old_chain);
> > Index: gdb/defs.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/defs.h,v
> > retrieving revision 1.88
> > diff -p -u -w -r1.88 defs.h
> > --- gdb/defs.h 18 Apr 2002 18:08:59 -0000 1.88
> > +++ gdb/defs.h 27 Apr 2002 19:18:57 -0000
> > @@ -641,6 +641,7 @@ struct command_line
> > extern struct command_line *read_command_lines (char *, int);
> >
> > extern void free_command_lines (struct command_line **);
> > +extern struct command_line * dup_command_lines (struct command_line *);
> >
> > /* To continue the execution commands when running gdb asynchronously.
> > A continuation structure contains a pointer to a function to be called
> > Index: gdb/cli/cli-script.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/cli/cli-script.c,v
> > retrieving revision 1.12
> > diff -p -u -w -r1.12 cli-script.c
> > --- gdb/cli/cli-script.c 12 Apr 2002 22:31:23 -0000 1.12
> > +++ gdb/cli/cli-script.c 27 Apr 2002 19:18:58 -0000
> > @@ -974,6 +974,59 @@ read_command_lines (char *prompt_arg, in
> > return (head);
> > }
> >
> > +/* Duplicate a chain of struct command_line's */
> > +
> > +struct command_line *
> > +dup_command_lines (struct command_line *l)
> > +{
> > + struct command_line *dup = NULL;
> > + register struct command_line *next = NULL;
> > +
> > +
> > + for (; l ; l = l->next)
> > + {
> > + if (next == NULL)
> > + {
> > + dup = next = (struct command_line *)
> > + xmalloc (sizeof (struct command_line));
> > + }
> > + else
> > + {
> > + next->next = (struct command_line *)
> > + xmalloc (sizeof (struct command_line));
> > +
> > + next = next->next;
> > + }
> > +
> > +
> > + if (next == NULL)
> > + return NULL;
> > +
> > +
> > + next->next = NULL;
> > + next->line = xstrdup (l->line);
> > + next->control_type = l->control_type;
> > + next->body_count = l->body_count;
> > +
> > +
> > + if (l->body_count > 0)
> > + {
> > + int i;
> > + struct command_line **blist = l->body_list;
> > +
> > + next->body_list =
> > + (struct command_line **) xmalloc (sizeof (struct command_line *)
> > + * l->body_count);
> > +
> > + for (i = 0; i < l->body_count; i++, blist++)
> > + next->body_list[i] = dup_command_lines (*blist);
> > + }
> > + }
> > +
> > + return dup;
> > +}
> > +
> > +
> > /* Free a chain of struct command_line's. */
> >
> > void
> >
> > --
> > dhoward@redhat.com
> > gdb engineering
>
> --
> Fernando Nasser
> Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
^ permalink raw reply [flat|nested] 26+ messages in thread
* Patch ping
@ 2002-01-24 17:25 Tom Tromey
0 siblings, 0 replies; 26+ messages in thread
From: Tom Tromey @ 2002-01-24 17:25 UTC (permalink / raw)
To: gdb-patches
I haven't seen any response to this patch:
http://sources.redhat.com/ml/gdb-patches/2002-01/msg00080.html
I submitted this Jan 5.
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread* Patch ping
@ 2001-12-07 7:50 Tom Tromey
2001-12-07 8:14 ` Elena Zannoni
2001-12-07 10:46 ` Eli Zaretskii
0 siblings, 2 replies; 26+ messages in thread
From: Tom Tromey @ 2001-12-07 7:50 UTC (permalink / raw)
To: Elena Zannoni; +Cc: gdb-patches
This patch has been unreviewed for a month:
http://sources.redhat.com/ml/gdb-patches/2001-11/msg00108.html
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Patch ping
2001-12-07 7:50 Tom Tromey
@ 2001-12-07 8:14 ` Elena Zannoni
2001-12-07 10:00 ` Keith Seitz
2001-12-08 19:57 ` Tom Tromey
2001-12-07 10:46 ` Eli Zaretskii
1 sibling, 2 replies; 26+ messages in thread
From: Elena Zannoni @ 2001-12-07 8:14 UTC (permalink / raw)
To: tromey; +Cc: Elena Zannoni, gdb-patches, insight
Tom Tromey writes:
> This patch has been unreviewed for a month:
>
> http://sources.redhat.com/ml/gdb-patches/2001-11/msg00108.html
>
> Tom
Yes, I didn't forget. I was waiting for some comments on the insight
changes. I am cc-ing that list.
It is fine for the gdb proper part.
Elena
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2001-12-07 8:14 ` Elena Zannoni
@ 2001-12-07 10:00 ` Keith Seitz
2001-12-08 19:57 ` Tom Tromey
1 sibling, 0 replies; 26+ messages in thread
From: Keith Seitz @ 2001-12-07 10:00 UTC (permalink / raw)
To: Elena Zannoni; +Cc: tromey, gdb-patches, Insight Maling List
My bad...
On Fri, 7 Dec 2001, Elena Zannoni wrote:
> Tom Tromey writes:
> > This patch has been unreviewed for a month:
> >
> > http://sources.redhat.com/ml/gdb-patches/2001-11/msg00108.html
> >
> > Tom
>
> Yes, I didn't forget. I was waiting for some comments on the insight
> changes. I am cc-ing that list.
I really don't know what to say. The only thing I know about this
function is from its comment:
/* The lookup_symtab() in symtab.c doesn't work correctly */
/* It will not work will full pathnames and if multiple */
/* source files have the same basename, it will return */
/* the first one instead of the correct one. */
/* symtab->fullname will be NULL if the file is not available. */
I've created a simple testcase which looks like this:
$ ls *
foo* foo.c
a:
foo.c
b:
foo.c
c:
foo.c
So we have four filenames called foo.c. Now if I change full_lookup_symtab
to skip what it does and ONLY call lookup_symtab, I cannot load any source
file from Insight. It just doesn't find any.
After applying this patch, everything seems to work again.
So, yes, please do check it in. We'll worry about any fallout later.
(Sorry for draggin' my *** so long on this.)
Keith
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2001-12-07 8:14 ` Elena Zannoni
2001-12-07 10:00 ` Keith Seitz
@ 2001-12-08 19:57 ` Tom Tromey
1 sibling, 0 replies; 26+ messages in thread
From: Tom Tromey @ 2001-12-08 19:57 UTC (permalink / raw)
To: Elena Zannoni; +Cc: gdb-patches, insight
>>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes:
Elena> It is fine for the gdb proper part.
Thanks.
I'm checking it in now.
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Patch ping
2001-12-07 7:50 Tom Tromey
2001-12-07 8:14 ` Elena Zannoni
@ 2001-12-07 10:46 ` Eli Zaretskii
2001-12-07 11:02 ` Tom Tromey
1 sibling, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2001-12-07 10:46 UTC (permalink / raw)
To: tromey; +Cc: ezannoni, gdb-patches
Hmm... I probably am missing something obvious, but fragments like
this one:
+ if (IS_ABSOLUTE_PATH (name))
+ real_path = gdb_realpath (name);
+
confuse me. Aren't they supposed to convert non-absolute file name,
that is, say "if (!IS_ABSOLUTE_PATH (name))"?
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: Patch ping
2001-12-07 10:46 ` Eli Zaretskii
@ 2001-12-07 11:02 ` Tom Tromey
0 siblings, 0 replies; 26+ messages in thread
From: Tom Tromey @ 2001-12-07 11:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ezannoni, gdb-patches
>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
Eli> Hmm... I probably am missing something obvious, but fragments
Eli> like this one:
Eli> + if (IS_ABSOLUTE_PATH (name))
Eli> + real_path = gdb_realpath (name);
Eli> +
Eli> confuse me. Aren't they supposed to convert non-absolute file
Eli> name, that is, say "if (!IS_ABSOLUTE_PATH (name))"?
No, these calls canonicalize absolute paths. I believe realpath()
isn't guaranteed to do anything sensible with a relative path. I will
add comments to this effect.
Tom
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-09-27 17:46 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-27 13:07 Patch ping Paul Brook
2004-05-27 21:20 ` Jason Molenda
2004-05-28 23:37 ` Jim Blandy
-- strict thread matches above, loose matches on Subject: below --
2016-09-14 19:27 patch ping Tom Tromey
2016-09-27 17:38 ` Tom Tromey
2016-09-27 17:50 ` Eli Zaretskii
2008-07-10 19:34 Patch ping Tom Tromey
2004-04-30 16:27 Ulrich Weigand
2004-04-30 17:33 ` Andrew Cagney
2004-04-30 18:13 ` Ulrich Weigand
2004-04-30 22:19 ` Jim Blandy
2004-04-30 22:51 ` Ulrich Weigand
2004-05-02 20:49 ` Andrew Cagney
2004-05-01 19:48 ` Ulrich Weigand
2004-04-30 22:26 ` Jim Blandy
2004-05-01 15:41 ` Ulrich Weigand
2004-05-02 20:49 ` Jim Blandy
2002-05-13 11:06 Don Howard
2002-05-16 15:54 ` Jim Blandy
2002-01-24 17:25 Tom Tromey
2001-12-07 7:50 Tom Tromey
2001-12-07 8:14 ` Elena Zannoni
2001-12-07 10:00 ` Keith Seitz
2001-12-08 19:57 ` Tom Tromey
2001-12-07 10:46 ` Eli Zaretskii
2001-12-07 11:02 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox