Patch ping

Patch ping

[Ulrich Weigand]

[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

Re: Patch ping

[Andrew Cagney]

> [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

Re: Patch ping

[Ulrich Weigand]

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

Re: Patch ping

[Jim Blandy]

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.

Re: Patch ping

[Jim Blandy]

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.

Re: Patch ping

[Ulrich Weigand]

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

Re: Patch ping

[Ulrich Weigand]

Jim Blandy wrote:
> 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.

Well, I don't have CVS access ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: Patch ping

[Ulrich Weigand]

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

Re: Patch ping

[Andrew Cagney]

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

Re: Patch ping

[Jim Blandy]

Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:

> Jim Blandy wrote:
> > 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.
> 
> Well, I don't have CVS access ...

Oh, to commit it yourself?  Wow, the end of the software letter era...
:) (Good riddance...)  I don't see that future assignment on file yet;
once that's done, we can ask the sources.redhat.com admins, and we'll
get the access set up quickly.

Re: patch ping

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: gdb-patches@sourceware.org,  tmielczarek@mozilla.com
> Date: Tue, 27 Sep 2016 10:44:25 -0600
> 
> >>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
> 
> Tom> I was talking with a fellow Mozillian today and found out that this
> Tom> patch was never reviewed:
> 
> Tom> https://sourceware.org/ml/gdb-patches/2015-05/msg00132.html
> 
> Tom> Ping.
> 
> Ping.

The documentation part is OK, but please don't use "path" to mean a
file name, GNU coding standards frown on that.

Re: patch ping

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> I was talking with a fellow Mozillian today and found out that this
Tom> patch was never reviewed:

Tom> https://sourceware.org/ml/gdb-patches/2015-05/msg00132.html

Tom> Ping.

Ping.

Tom

patch ping

[Tom Tromey]

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

Patch ping

[Tom Tromey]

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

Re: Patch ping

[Jim Blandy]

Paul Brook <paul@codesourcery.com> writes:

> 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

Sorry for the delay.  This looks fine; please go ahead and commit it.
Thanks!

Re: Patch ping

[Jason Molenda]

FWIW I've been looking at this part of dwarf3draft8 recently and this 
patch is correct.  There are a handful of new CFI instructions in 
dwarf3, but Mark Kettenis added these in January,

http://sources.redhat.com/ml/gdb-patches/2004-01/msg00483.html

But Mark didn't make the modification to recognize the version==3 
header.

BTW Paul, once your patch is approved could you get the little typeo in 
Mark's ChangeLog entry ("DW_CFA_def_cfa_exporession") while you're 
committing?

NB: My approval of this patch gets you nothing, but I thought I'd throw 
it out there as an informed 3rd party. ;)

J

On May 27, 2004, at 6:07 AM, Paul Brook wrote:

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

Patch ping

[Paul Brook]

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

Re: Patch ping

[Jim Blandy]

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

Patch ping

[Don Howard]

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

Patch ping

[Tom Tromey]

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

Re: Patch ping

[Tom Tromey]

>>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes:

Elena> It is fine for the gdb proper part. 

Thanks.
I'm checking it in now.

Tom

Re: Patch ping

[Tom Tromey]

>>>>> "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

Re: Patch ping

[Eli Zaretskii]

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))"?

Re: Patch ping

[Keith Seitz]

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

Re: Patch ping

[Elena Zannoni]

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

Patch ping

[Tom Tromey]

This patch has been unreviewed for a month:

    http://sources.redhat.com/ml/gdb-patches/2001-11/msg00108.html

Tom