Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Cc: tromey@redhat.com, alves.ped@gmail.com, brobecker@adacore.com
Subject: [7.4 regression] Stand-alone Cell debugging broken (Re: RFC: don't set the pspace on ordinary breakpoints)
Date: Mon, 02 Jan 2012 18:18:00 -0000	[thread overview]
Message-ID: <201201021818.q02IIAXd004892@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <201111181831.pAIIVJan019250@d06av02.portsmouth.uk.ibm.com> from "Ulrich Weigand" at Nov 18, 2011 07:31:19 PM

I wrote:
> Tom Tromey wrote:
> > >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> > 
> > Ulrich> Sorry for the delay; I wanted to test your patch on Cell to make
> > Ulrich> sure it doesn't regress in the scenario bp_startup_disabled was
> > Ulrich> introduced to fix.
> > 
> > It is no problem.
> > 
> > Ulrich> Unfortunately, I've been blocked by a number of SPU regressions
> > Ulrich> that make results on Cell currently bad anyway, see e.g.
> > Ulrich> http://sourceware.org/ml/gdb-patches/2011-11/msg00437.html
> > Ulrich> http://sourceware.org/ml/gdb-patches/2011-11/msg00439.html
> > 
> > Ulrich> I'm still planning on doing the run once SPU is stable again.
> > 
> > Ok.  I will wait for that then.
> 
> OK, I've now completed a run with your patch in the situation where
> bp_startup_disabled was necessary (stand-alone SPU executables on
> a Cell/B.E. system).   Everything still works fine.

While this patch by itself didn't break stand-alone SPU debugging,
the whole "ambiguous linespec" series in total apparently did.

What happens is that if I set a breakpoint on "main", and then start
execution, the first time breakpoints are re-set, addr_string_to_sals
(as called from breakpoint_re_set_default) correctly recognizes that
even though "main" cannot be found at this moment, this is OK since
the address space is currently going through startup.

However, while this means that no error is thrown at this point,
addr_string_to_sals still returns an empty location list, and the
existing list of locations for the "main" breakpoint now gets thrown
away in update_breakpoint_locations.

This in turn means that the *next* time breakpoints are re-set, the
"main" breakpoint now no longer has any locations associated to it,
and therefore it is no longer recognized as being related to an
address space going through startup.

Thus, an error is thrown and the breakpoint is marked disabled, and
therefore once startup is completed and "main" now *could* be found
again, it is no longer even attempted to insert the breakpoint again.

This is a serious regression that bascially means debugging stand-
alone SPU programs with a Cell/B.E. debugger is impossible.  Thus
it would be really good to get this fixed before 7.4 is released ...

The following patch fixes the problem for me.  It hooks into an
existing mechanism to fix a similar problem for breakpoints in
shared libraries that are being unloaded:  update_breakpoint_locations
does:

  /* If there's no new locations, and all existing locations are
     pending, don't do anything.  This optimizes the common case where
     all locations are in the same shared library, that was unloaded.
     We'd like to retain the location, so that when the library is
     loaded again, we don't loose the enabled/disabled status of the
     individual locations.  */
  if (all_locations_are_pending (existing_locations) && sals.nelts == 0)
    return;

which has the effect to keep locations from such libraries present
even though the library is unloaded.  The patch below now extends
this to the executing_startup case by having all_locations_are_pending
consider locations in address spaces currently going through startup
as "pending" as well.

With this change, the breakpoint location is kept active until startup
is complete, and then replaced with the correct location.


Does this look reasonable?  Joel, would this be OK for 7.4 as well?

Thanks,
Ulrich


ChangeLog:

	* breakpoint.c (all_locations_are_pending): Consider locations
	in program spaces executing during startup pending as well.

Index: gdb/breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.633.2.2
diff -u -p -r1.633.2.2 breakpoint.c
--- gdb/breakpoint.c	23 Dec 2011 17:55:20 -0000	1.633.2.2
+++ gdb/breakpoint.c	2 Jan 2012 15:16:20 -0000
@@ -11500,7 +11500,8 @@ static int
 all_locations_are_pending (struct bp_location *loc)
 {
   for (; loc; loc = loc->next)
-    if (!loc->shlib_disabled)
+    if (!loc->shlib_disabled
+	&& !loc->pspace->executing_startup)
       return 0;
   return 1;
 }


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2012-01-02 18:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-27 15:32 RFC: don't set the pspace on ordinary breakpoints Tom Tromey
2011-10-31  1:03 ` Jan Kratochvil
2011-10-31 12:07 ` Yao Qi
2011-11-02 18:55 ` Pedro Alves
2011-11-02 19:47   ` Tom Tromey
2011-11-02 20:21     ` Pedro Alves
2011-11-03 14:01       ` Tom Tromey
2011-11-03 16:02         ` Pedro Alves
2011-11-03 19:33           ` Ulrich Weigand
2011-11-08 19:32           ` Tom Tromey
2011-11-08 20:23             ` Tom Tromey
2011-11-09 18:24               ` Tom Tromey
2011-11-09 18:30               ` Pedro Alves
2011-11-09 18:41                 ` Tom Tromey
2011-11-10 16:53                   ` Tom Tromey
2011-11-10 17:49                     ` Pedro Alves
2011-11-10 17:57                     ` Ulrich Weigand
2011-11-10 19:27                       ` Tom Tromey
2011-11-10 20:23                         ` Tom Tromey
2011-11-11 12:56                           ` Ulrich Weigand
2011-11-11 14:47                             ` Tom Tromey
2011-11-14 21:12                               ` Tom Tromey
2011-11-16 18:37                               ` Ulrich Weigand
2011-11-16 21:24                                 ` Tom Tromey
2011-11-18 18:31                                   ` Ulrich Weigand
2012-01-02 18:18                                     ` Ulrich Weigand [this message]
2012-01-03  3:15                                       ` [7.4 regression] Stand-alone Cell debugging broken (Re: RFC: don't set the pspace on ordinary breakpoints) Joel Brobecker
2012-01-03 20:29                                       ` Tom Tromey
2012-01-04 12:36                                         ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201201021818.q02IIAXd004892@d06av02.portsmouth.uk.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=alves.ped@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox