[rfc] Infrastructure to disable breakpoints during inferior startup

[rfc] Infrastructure to disable breakpoints during inferior startup

[Ulrich Weigand]

Hello,

in some cases, it can happen that the main executable of a process is
visible at different addresses once the inferior is running, as compared
to the addresses in the original objfile.  This is a problem for the Cell
combined debugger when running stand-alone SPU executables; but it should
also be a problem e.g. when running PIE executable on Linux.

In particular, there causes a problem with breakpoints.  GDB assumes that
whenever a process is running that all breakpoints (not in shared libraries)
can be inserted at their original addresses.  If a breakpoint was originally
set before the inferior was started, this address was computed using the
original objfile addresses -- but the breakpoint cannot be inserted there.

At some point during inferior startup, the relocation of the main
executable file is completed and reflected by GDB's solib handler,
causing the objfile to be relocated and breakpoint addresses to be
recomputed.  At this point, breakpoints can be installed without problem.

However, in the meantime we simply cannot insert breakpoints into the
inferior; every attempt to do so will fail, causing inferior startup
overall to fail.

The following patch attempts to address this by temporarily disabling all
user-installed breakpoints during the inferior startup phase, using a
mechanism similar to disable_watchpoints_before_interactive_call_start.

A new pair of functions:
  disable_breakpoints_before_startup
  enable_breakpoints_after_startup
is provided for this purpose.  The intent is that those functions are
called from a solib handler to disable breakpoints in the solib's
create_inferior hook, and re-enable them (e.g. in the current_sos hook)
once the inferior is ready and the final address of the main objfile
is known.

The disable function will bring all breakpoints into a new
bp_startup_disabled state, that is pretty much handled the same
as bp_call_disables is today.  In addition, a flag is set that
causes all newly user-created breakpoints in the period between
the disable and enable calls to start out in that same state.
(This is necessary because in some circumstances, e.g. when using
the remote target where you start out attached to the inferior at
the entry point, user interaction is possible in between those two
points in time.)

However, internal breakpoints are not affected (because e.g. solib
breakpoints must be installed in order for the solib handler to
regain control).  It's up to those GDB subsystems to handler such
internal breakpoints as necessary.

Tested on powerpc64-linux with no regression (note that the patch
is a no-op as is, because nobody calls the new functions).  Also
tested together with the Cell combined debugger patch, where the
functions *are* called and fix SPU stand-alone executable debugging.

At this point, the patch does not attempt to support PIE executables.
However, the infrastructure provided here should enable further
patches to provide that support on top.

Any comments on this approach -or other suggestions- are welcome.
If there are no objections, I'm planning to commit the patch
within a week or so.

Bye,
Ulrich


ChangeLog:

	* breakpoint.h (enum enable_state): Add bp_startup_disabled.
	(disable_breakpoints_before_startup): Add prototype.
	(enable_breakpoints_after_startup): Likewise.

	* breakpoint.c (executing_startup): New static variable.
	(describe_other_breakpoints): Handle bp_startup_disabled.
	(check_duplicates_for): Likewise.
	(disable_breakpoints_before_startup): New function.
	(enable_breakpoints_after_startup): New function.
	(create_breakpoint): Mark new breakpoints as bp_startup_disabled
	if executing_startup flag is true.
	(break_command_really): Likewise.
	(breakpoint_re_set_one): Skip bp_startup_disabled breakpoints.


Index: src/gdb/breakpoint.c
===================================================================
--- src.orig/gdb/breakpoint.c
+++ src/gdb/breakpoint.c
@@ -319,6 +319,9 @@ static int executing_breakpoint_commands
 /* Are overlay event breakpoints enabled? */
 static int overlay_events_enabled;
 
+/* Are we executing startup code?  */
+static int executing_startup;
+
 /* Walk the following statement or block through all breakpoints.
    ALL_BREAKPOINTS_SAFE does so even if the statment deletes the current
    breakpoint.  */
@@ -4140,7 +4143,8 @@ describe_other_breakpoints (struct gdbar
 	      printf_filtered (" (thread %d)", b->thread);
 	    printf_filtered ("%s%s ",
 			     ((b->enable_state == bp_disabled
-			       || b->enable_state == bp_call_disabled) 
+			       || b->enable_state == bp_call_disabled
+			       || b->enable_state == bp_startup_disabled)
 			      ? " (disabled)"
 			      : b->enable_state == bp_permanent 
 			      ? " (permanent)"
@@ -4211,6 +4215,7 @@ check_duplicates_for (CORE_ADDR address,
   ALL_BP_LOCATIONS (b)
     if (b->owner->enable_state != bp_disabled
 	&& b->owner->enable_state != bp_call_disabled
+	&& b->owner->enable_state != bp_startup_disabled
 	&& b->enabled
 	&& !b->shlib_disabled
 	&& b->address == address	/* address / overlay match */
@@ -4247,6 +4252,7 @@ check_duplicates_for (CORE_ADDR address,
 	    if (b->owner->enable_state != bp_permanent
 		&& b->owner->enable_state != bp_disabled
 		&& b->owner->enable_state != bp_call_disabled
+		&& b->owner->enable_state != bp_startup_disabled
 		&& b->enabled && !b->shlib_disabled		
 		&& b->address == address	/* address / overlay match */
 		&& (!overlay_debugging || b->section == section)
@@ -5095,6 +5101,52 @@ enable_watchpoints_after_interactive_cal
   }
 }
 
+void
+disable_breakpoints_before_startup (void)
+{
+  struct breakpoint *b;
+  int found = 0;
+
+  ALL_BREAKPOINTS (b)
+    {
+      if ((b->type == bp_breakpoint
+	   || b->type == bp_hardware_breakpoint)
+	  && breakpoint_enabled (b))
+	{
+	  b->enable_state = bp_startup_disabled;
+	  found = 1;
+	}
+    }
+
+  if (found)
+    update_global_location_list (0);
+
+  executing_startup = 1;
+}
+
+void
+enable_breakpoints_after_startup (void)
+{
+  struct breakpoint *b;
+  int found = 0;
+
+  executing_startup = 0;
+
+  ALL_BREAKPOINTS (b)
+    {
+      if ((b->type == bp_breakpoint
+	   || b->type == bp_hardware_breakpoint)
+	  && b->enable_state == bp_startup_disabled)
+	{
+	  b->enable_state = bp_enabled;
+	  found = 1;
+	}
+    }
+
+  if (found)
+    breakpoint_re_set ();
+}
+
 
 /* Set a breakpoint that will evaporate an end of command
    at address specified by SAL.
@@ -5438,6 +5490,11 @@ create_breakpoint (struct gdbarch *gdbar
 	  b->enable_state = enabled ? bp_enabled : bp_disabled;
 	  b->disposition = disposition;
 
+	  if (enabled && executing_startup
+	      && (b->type == bp_breakpoint
+		  || b->type == bp_hardware_breakpoint))
+	    b->enable_state = bp_startup_disabled;
+
 	  loc = b->loc;
 	}
       else
@@ -5993,6 +6050,11 @@ break_command_really (struct gdbarch *gd
       b->ops = ops;
       b->enable_state = enabled ? bp_enabled : bp_disabled;
 
+      if (enabled && executing_startup
+	  && (b->type == bp_breakpoint
+	      || b->type == bp_hardware_breakpoint))
+	b->enable_state = bp_startup_disabled;
+
       mention (b);
     }
   
@@ -7792,6 +7854,10 @@ breakpoint_re_set_one (void *bint)
     case bp_breakpoint:
     case bp_hardware_breakpoint:
     case bp_tracepoint:
+      /* Do not attempt to re-set breakpoints disabled during startup.  */
+      if (b->enable_state == bp_startup_disabled)
+	return 0;
+
       if (b->addr_string == NULL)
 	{
 	  /* Anything without a string can't be re-set. */
Index: src/gdb/breakpoint.h
===================================================================
--- src.orig/gdb/breakpoint.h
+++ src/gdb/breakpoint.h
@@ -135,6 +135,12 @@ enum enable_state
 			   automatically enabled and reset when the call 
 			   "lands" (either completes, or stops at another 
 			   eventpoint). */
+    bp_startup_disabled,/* The eventpoint has been disabled during inferior
+			   startup.  This is necessary on some targets where
+			   the main executable will get relocated during
+			   startup, making breakpoint addresses invalid.
+			   The eventpoint will be automatically enabled and
+			   reset once inferior startup is complete.  */
     bp_permanent	/* There is a breakpoint instruction hard-wired into
 			   the target's code.  Don't try to write another
 			   breakpoint instruction on top of it, or restore
@@ -810,6 +816,19 @@ extern void disable_watchpoints_before_i
 
 extern void enable_watchpoints_after_interactive_call_stop (void);
 
+/* These functions disable and re-enable all breakpoints during
+   inferior startup.  They are intended to be called from solib
+   code where necessary.  This is needed on platforms where the
+   main executable is relocated at some point during startup
+   processing, making breakpoint addresses invalid.
+
+   If additional breakpoints are created after the routine
+   disable_breakpoints_before_startup but before the routine
+   enable_breakpoints_after_startup was called, they will also
+   be marked as disabled.  */
+extern void disable_breakpoints_before_startup (void);
+extern void enable_breakpoints_after_startup (void);
+
 /* For script interpreters that need to define breakpoint commands
    after they've already read the commands into a struct command_line.  */
 extern enum command_control_type commands_from_control_command
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Tom Tromey]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> The following patch attempts to address this by temporarily
Ulrich> disabling all user-installed breakpoints during the inferior
Ulrich> startup phase, using a mechanism similar to
Ulrich> disable_watchpoints_before_interactive_call_start.

FWIW, I took a look at the PIE patch from the Fedora SRPM.  It has
almost identical functions disable_breakpoints_before_startup and
re_enable_breakpoints_at_startup.

There are some differences, but I don't know whether they are relevant
or not.

The Fedora disable_breakpoints_before_startup has a check like this:

+	  if (((b->type == bp_breakpoint) ||
+	       (b->type == bp_hardware_breakpoint)) &&
+	      b->enable_state == bp_enabled &&
+	      !b->loc->duplicate)

This differs from yours because it checks `loc->duplicate'.


The Fedora re_enable_breakpoints_at_startup does this:

+	    /* Do not reenable the breakpoint if the shared library
+	       is still not mapped in.  */
+	    if (target_read_memory (b->loc->address, buf, 1) == 0)
+	      {
+		/*printf ("enabling breakpoint at 0x%s\n", paddr_nz(b->loc->address));*/
+		b->enable_state = bp_enabled;
+	      }

I have no idea about this either.  Perhaps it is something specific to
PIE on Linux.

Maybe Jan can follow up when he gets back.

Ulrich> +/* Are we executing startup code?  */
Ulrich> +static int executing_startup;

This seems like it should be a field in struct inferior.

I seem to say that a lot :-).  I don't actually know .. should we be
doing this sort of thing now, or are we waiting for Pedro's
multi-inferior patches to land first?

Ulrich> +    bp_startup_disabled,/* The eventpoint has been disabled during inferior

I think a new bp_ constant probably needs an entry in the array in
print_one_breakpoint_location.  Otherwise if something funny happens,
and we try to print one, gdb will get an internal error.

Tom

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Ulrich Weigand]

Tom Tromey wrote:

> FWIW, I took a look at the PIE patch from the Fedora SRPM.  It has
> almost identical functions disable_breakpoints_before_startup and
> re_enable_breakpoints_at_startup.

Yes, it's the same concept, but those functions in the PIE patch have
some code that seems PIE specific (e.g. the entry point checks) that
should be moved to the caller (presumably solib-svr4.c in the PIE case)
to make the same infrastructure usable for both scenarios.
 
> There are some differences, but I don't know whether they are relevant
> or not.
> 
> The Fedora disable_breakpoints_before_startup has a check like this:
> 
> +	  if (((b->type == bp_breakpoint) ||
> +	       (b->type == bp_hardware_breakpoint)) &&
> +	      b->enable_state == bp_enabled &&
> +	      !b->loc->duplicate)
> 
> This differs from yours because it checks `loc->duplicate'.

I don't see why a breakpoint shouldn't be disabled just because its
first location has a duplicate ...  If the breakpoint has another
location, or if the duplicate gets removed later on, GDB would attempt
to insert this breakpoint and fail ...

See also the comments in disable_breakpoints_in_shlibs that explain
why the shlib_disabled flag is explicitly set also for duplicates.

> The Fedora re_enable_breakpoints_at_startup does this:
> 
> +	    /* Do not reenable the breakpoint if the shared library
> +	       is still not mapped in.  */
> +	    if (target_read_memory (b->loc->address, buf, 1) == 0)
> +	      {
> +		/*printf ("enabling breakpoint at 0x%s\n", paddr_nz(b->loc->address));*/
> +		b->enable_state = bp_enabled;
> +	      }
> 
> I have no idea about this either.  Perhaps it is something specific to
> PIE on Linux.

This seems odd to me; breakpoint disabled at startup cannot really be
within a shared library.  (Even if they were, a unmapped shared library
ought to be handled via the shlib_disabled mechanism ...)

> Ulrich> +/* Are we executing startup code?  */
> Ulrich> +static int executing_startup;
> 
> This seems like it should be a field in struct inferior.

Agreed.

> I seem to say that a lot :-).  I don't actually know .. should we be
> doing this sort of thing now, or are we waiting for Pedro's
> multi-inferior patches to land first?

I don't know; what's the timeline for Pedro's patches?

(In any case, moving this variable over to a struct inferior field
can be trivially done after Pedro's patches are merged; I'm not sure
we have to wait because of that ...)

> Ulrich> +    bp_startup_disabled,/* The eventpoint has been disabled during inferior
> 
> I think a new bp_ constant probably needs an entry in the array in
> print_one_breakpoint_location.  Otherwise if something funny happens,
> and we try to print one, gdb will get an internal error.

Unless I'm missing someting, the array in print_one_breakpoint_location
is about enum bptype member; I've added a enum enable_state member here ...

Bye,
Ulrich

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

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Tom Tromey]

Ulrich> Yes, it's the same concept, but those functions in the PIE patch have
Ulrich> some code that seems PIE specific (e.g. the entry point checks) that
Ulrich> should be moved to the caller (presumably solib-svr4.c in the PIE case)
Ulrich> to make the same infrastructure usable for both scenarios.

Yeah, I agree.

Ulrich> (In any case, moving this variable over to a struct inferior field
Ulrich> can be trivially done after Pedro's patches are merged; I'm not sure
Ulrich> we have to wait because of that ...)

I'm inclined to agree as a general rule that we shouldn't put too much
work into helping out uncommitted patches.  In this case, though, we do
already have struct inferior, and I wonder if the seemingly steady
stream of needed fixes is making Pedro's to-do list impossible.
I suppose if he doesn't speak up then I won't object any more :-)

Ulrich> Unless I'm missing someting, the array in
Ulrich> print_one_breakpoint_location is about enum bptype member; I've
Ulrich> added a enum enable_state member here ...

Yes, my mistake.  I frequently get confused since both sets of constants
start with `bp_'.

Tom

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Ulrich Weigand]

Tom Tromey wrote:

> Ulrich> (In any case, moving this variable over to a struct inferior field
> Ulrich> can be trivially done after Pedro's patches are merged; I'm not sure
> Ulrich> we have to wait because of that ...)
> 
> I'm inclined to agree as a general rule that we shouldn't put too much
> work into helping out uncommitted patches.  In this case, though, we do
> already have struct inferior, and I wonder if the seemingly steady
> stream of needed fixes is making Pedro's to-do list impossible.
> I suppose if he doesn't speak up then I won't object any more :-)

Thinking about it a bit more, it seems that in the context of Pedro's
patches, this flag really needs to be a symbol-space property, not an
inferior property: it basically says that objfiles in this symbol
space have not yet been relocated to their final addresses and therefore
cannot be used to determine breakpoint addresses.

In the situation where multiple inferiors potentially share a symbol
space, this property applies to all of them.  Also, with Pedro's
patches breakpoints will be per-symbol-space, not per-inferior, so
we'll have to disable/re-enable all breakpoints in a given symbol
space (we cannot really disable all breakpoints of a given inferior,
as this information is not actually known).

So it seems that after all adding the flag to struct inferior now
might be a step in the wrong direction; it should instead be added to
struct symbol_space once Pedro's patches are in.

Pedro, any comments?

Bye,
Ulrich

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

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Pedro Alves]

On Thursday 23 July 2009 17:31:02, Ulrich Weigand wrote:

> Thinking about it a bit more, it seems that in the context of Pedro's
> patches, this flag really needs to be a symbol-space property, not an
> inferior property: it basically says that objfiles in this symbol
> space have not yet been relocated to their final addresses and therefore
> cannot be used to determine breakpoint addresses.
> 
> In the situation where multiple inferiors potentially share a symbol
> space, this property applies to all of them.  Also, with Pedro's
> patches breakpoints will be per-symbol-space, not per-inferior, so
> we'll have to disable/re-enable all breakpoints in a given symbol
> space (we cannot really disable all breakpoints of a given inferior,
> as this information is not actually known).
> 
> So it seems that after all adding the flag to struct inferior now
> might be a step in the wrong direction; it should instead be added to
> struct symbol_space once Pedro's patches are in.
> 
> Pedro, any comments?

Yes, I agree with you.  (although in the only target supporting
shared symbol space, DICOS, we don't run or start programs, we only
attach to already running ones, and if we did [it would be possible to
add such feature], the code is always already all relocated when we
connect --- due to the global shared libraries feature of DICOS.)

While Tom's right, there has been a stream of changes recently that
constantly require that I adjust the multi-exec patch set, I'll handle
this one easily when your patch is in; I don't think it will
be much trouble.

BTW, I haven't had much of a chance to touch the multi-exec
patches since I posted them last.  I was mostly waiting to see if
people had comments on the general design, and on the user
interface before proceeding further with it.  If there's anything
I should do to make that (testing, review, comments) easier on
others, please let me know.

-- 
Pedro Alves

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> BTW, I haven't had much of a chance to touch the multi-exec
Pedro> patches since I posted them last.  I was mostly waiting to see if
Pedro> people had comments on the general design, and on the user
Pedro> interface before proceeding further with it.  If there's anything
Pedro> I should do to make that (testing, review, comments) easier on
Pedro> others, please let me know.

I've been meaning to try this for a while.

Today I finally got around to applying it.  The patch didn't apply
cleanly (nothing serious), and also had a couple problems compiling once
I did apply it.

I've appended my cleanup patch.  One of the rs6000-tdep.c hunks is just
a temporary workaround for unrelated build breakage.

I put all this on a local git branch.  I can push it to the archer
repository if you, or anybody, wants to see it there.

I still haven't actually tried it, but I hope to do so soon.

Tom

diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
index 51e8bbd..9cf5057 100644
--- a/gdb/mips-tdep.c
+++ b/gdb/mips-tdep.c
@@ -2490,7 +2490,7 @@ mips_software_single_step (struct frame_info *frame)
   CORE_ADDR pc, next_pc;
 
   pc = get_frame_pc (frame);
-  if (deal_with_atomic_sequence (gdbarch, pc))
+  if (deal_with_atomic_sequence (gdbarch, aspace, pc))
     return 1;
 
   next_pc = mips_next_pc (frame, pc);
diff --git a/gdb/monitor.c b/gdb/monitor.c
index 4cdfaae..4f258a9 100644
--- a/gdb/monitor.c
+++ b/gdb/monitor.c
@@ -705,6 +705,7 @@ monitor_open (char *args, struct monitor_ops *mon_ops, int from_tty)
 {
   char *name;
   char **p;
+  struct inferior *inf;
 
   if (mon_ops->magic != MONITOR_OPS_MAGIC)
     error (_("Magic number of monitor_ops struct wrong."));
diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
index bc787f3..1d37eda 100644
--- a/gdb/rs6000-tdep.c
+++ b/gdb/rs6000-tdep.c
@@ -1075,7 +1075,7 @@ int
 ppc_deal_with_atomic_sequence (struct frame_info *frame)
 {
   struct gdbarch *gdbarch = get_frame_arch (frame);
-  struct gdbarch *aspace = get_frame_address_space (frame);
+  struct address_space *aspace = get_frame_address_space (frame);
   enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
   CORE_ADDR pc = get_frame_pc (frame);
   CORE_ADDR breaks[2] = {-1, -1};
@@ -2950,8 +2950,8 @@ static struct variant variants[] =
    bfd_mach_rs6k, &tdesc_rs6000},
   {"403", "IBM PowerPC 403", bfd_arch_powerpc,
    bfd_mach_ppc_403, &tdesc_powerpc_403},
-  {"405", "IBM PowerPC 405", bfd_arch_powerpc,
-   bfd_mach_ppc_405, &tdesc_powerpc_405},
+/*   {"405", "IBM PowerPC 405", bfd_arch_powerpc, */
+/*    bfd_mach_ppc_405, &tdesc_powerpc_405}, */
   {"601", "Motorola PowerPC 601", bfd_arch_powerpc,
    bfd_mach_ppc_601, &tdesc_powerpc_601},
   {"602", "Motorola PowerPC 602", bfd_arch_powerpc,
diff --git a/gdb/spu-tdep.c b/gdb/spu-tdep.c
index 4725757..0733824 100644
--- a/gdb/spu-tdep.c
+++ b/gdb/spu-tdep.c
@@ -1338,7 +1338,7 @@ spu_software_single_step (struct frame_info *frame)
 
       target = target & (SPU_LS_SIZE - 1);
       if (target != next_pc)
-	insert_single_step_breakpoint (gdbarch, target);
+	insert_single_step_breakpoint (gdbarch, aspace, target);
     }
 
   return 1;

Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup)

[Tom Tromey]

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

Tom> I still haven't actually tried it, but I hope to do so soon.

I tried it a little.

I can't remember ... should this all work ok on x86 Linux?  I thought
yes, hence this report, but if not, feel free to just let me know and
ignore all this.

Most of what I've written here seems familiar.  I assume I read it all
in earlier notes of yours :-)


The first thing I noticed is that the new features are off by default.
I had to:

    set schedule-multiple on
    set detach-on-fork off

to get it to work.  Having it disabled by default is ok as long as it is
a "technology preview", but if we think it is very solid then I think we
should enable it by default.

Having to set 2 options is obscure.  I suppose I didn't really need to
set both, except my first attempt was to run "make", which tripped over
the vfork problem.


I put a gcc I built into my $PATH.  Then I did:

    $ cd gdbserver
    $ ../gdb make

Then I tried various things.

"run clean" worked ok!  That was cool!

Then I exited gdb and restarted it and tried a plain "run".  This gave
me:

    (gdb) set schedule-multiple on
    (gdb) set detach-on-fork off
    (gdb) run
    Starting program: /usr/bin/make 
    (no debugging symbols found)
    (no debugging symbols found)
    (no debugging symbols found)
    [New process 3931]
    process 3931 is executing new program: /bin/true
    (no debugging symbols found)
    (no debugging symbols found)
    (no debugging symbols found)

    Program exited normally.

... which is a little odd, since no build was done.
And, what's with process 3931 executing /bin/true?
Am I not debugging the 'make' process?

A minor nit: I think "is executing a new program" would read better.

Then I did "run clean":

    (gdb) run clean
    Starting program: /bin/true clean
    (no debugging symbols found)
    (no debugging symbols found)
    gcc -c -Wall -g3    -I. -I../../../archer/gdb/gdbserver -I../../../archer/gdb/gdbserver/../common -I../../../archer/gdb/gdbserver/../regformats -I../../../archer/gdb/gdbserver/../../include ../../../archer/gdb/gdbserver/regcache.c

Here, for some reason, the compile started.  And, gdb forgot that I was
looking at "make" and ran /bin/true.

At this point, gdb hangs and cannot be interrupted.  I kill -9'd it.


If I do the above but remember "file /usr/bin/make", gdb starts make
again ok and the compile starts.  But, gdb hangs again as above.

This hang occurs often enough that I couldn't get to other tests, like
trying to set a breakpoint that would only trigger in cc1.


Those "(no debugging symbols found)" messages made me want Doug's patch
more ;)


Note that it is entirely possible that the patch applied strangely and I
introduced some bug that way.  Or, maybe there is some other pilot
error.

Tom

Re: Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup)

[Pedro Alves]

On Friday 24 July 2009 23:45:02, Tom Tromey wrote:
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> 
> Tom> I still haven't actually tried it, but I hope to do so soon.
> 
> I tried it a little.

Thank you!

> 
> I can't remember ... should this all work ok on x86 Linux?  I thought
> yes, hence this report, but if not, feel free to just let me know and
> ignore all this.

It should.  Although I've been testing most on x86_64.

> Most of what I've written here seems familiar.  I assume I read it all
> in earlier notes of yours :-)
> 
> 
> The first thing I noticed is that the new features are off by default.

Right.

> I had to:
> 
>     set schedule-multiple on
>     set detach-on-fork off
> 
> to get it to work.  Having it disabled by default is ok as long as it is
> a "technology preview", but if we think it is very solid then I think we
> should enable it by default.
> 
> Having to set 2 options is obscure.  I suppose I didn't really need to
> set both, except my first attempt was to run "make", which tripped over
> the vfork problem.
> 
> 
> I put a gcc I built into my $PATH.  Then I did:
> 
>     $ cd gdbserver
>     $ ../gdb make
> 
> Then I tried various things.
> 
> "run clean" worked ok!  That was cool!
> 
> Then I exited gdb and restarted it and tried a plain "run".  This gave
> me:
> 
>     (gdb) set schedule-multiple on
>     (gdb) set detach-on-fork off
>     (gdb) run
>     Starting program: /usr/bin/make 
>     (no debugging symbols found)
>     (no debugging symbols found)
>     (no debugging symbols found)
>     [New process 3931]
>     process 3931 is executing new program: /bin/true
>     (no debugging symbols found)
>     (no debugging symbols found)
>     (no debugging symbols found)
> 
>     Program exited normally.
> 
> ... which is a little odd, since no build was done.
> And, what's with process 3931 executing /bin/true?
> Am I not debugging the 'make' process?

Ah, but you're debugging in all-stop mode.  What this means
is that a program exit is a reason to stop everything and report
to the user.  This was /bin/true exiting.  Check "info inferiors",
and you should still see other inferiors there, waiting for you
to tell them to continue execution.

> A minor nit: I think "is executing a new program" would read better.

See?  That was the *only* string I changed, and it's picky.  :-)
I should have left that out of the patch.  :-)

> 
> Then I did "run clean":
> 
>     (gdb) run clean
>     Starting program: /bin/true clean
>     (no debugging symbols found)
>     (no debugging symbols found)
>     gcc -c -Wall -g3    -I. -I../../../archer/gdb/gdbserver -I../../../archer/gdb/gdbserver/../common -I../../../archer/gdb/gdbserver/../regformats -I../../../archer/gdb/gdbserver/../../include ../../../archer/gdb/gdbserver/regcache.c
> 
> Here, for some reason, the compile started.  And, gdb forgot that I was
> looking at "make" and ran /bin/true.

This is a consequence of the above.  You're in all-stop mode,
focusing the /bin/true program, and you've told it to run.  You also
have "shedule-multiple on", so what happened is that you're
told 'true' to run, and, all other inferiors that were stopped
also ran.

(also take a look at the set follow-exec-mode setting --- doesn't apply
in this case, but you seem to be expecting something like that.
Disclaimer, I don't claim these new setting and command names to
be perfect.)


> At this point, gdb hangs and cannot be interrupted.  I kill -9'd it.

Hmm, possibly the vfork parent on foreground issue, but I can't tell
immediately why it happened, since the children should have ran too, if
I didn't miss any command you issued.

> If I do the above but remember "file /usr/bin/make", gdb starts make
> again ok and the compile starts.  But, gdb hangs again as above.
> 
> This hang occurs often enough that I couldn't get to other tests, like
> trying to set a breakpoint that would only trigger in cc1.
> 
> 
> Those "(no debugging symbols found)" messages made me want Doug's patch
> more ;)

( :-) Actually, we don't need to whole of Doug's patch for this.  Just the
bit that suppresses these symbol loading messages for "auto-loaded" objfiles. )

> Note that it is entirely possible that the patch applied strangely and I
> introduced some bug that way.  Or, maybe there is some other pilot
> error.

You need to try it with non-stop mode on.  It should work like you
seem to want it to.   See the "bootstrapping" gdb example here:

 http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html

all-stop + synchronous debugging is limited by design, and what we can
do with it.  Note that this behaviour of stopping when a program exits
isn't new at all.  This is how multi-forks always behaved.

( Long term, I'd very much like to fuse all-stop into non-stop.  That is,
implement all-stop mode on top of non-stop+async, and so have make the
UI (especially the number of setting required to activate), much reduced.
We're still a bit far from that... )

-- 
Pedro Alves

Re: Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup)

[Pedro Alves]

On Saturday 25 July 2009 16:12:49, Pedro Alves wrote:
> >     (gdb) set schedule-multiple on
> >     (gdb) set detach-on-fork off
> >     (gdb) run
> >     Starting program: /usr/bin/make 
> >     (no debugging symbols found)
> >     (no debugging symbols found)
> >     (no debugging symbols found)
> >     [New process 3931]
> >     process 3931 is executing new program: /bin/true
> >     (no debugging symbols found)
> >     (no debugging symbols found)
> >     (no debugging symbols found)
> > 
> >     Program exited normally.
> > 
> > ... which is a little odd, since no build was done.
> > And, what's with process 3931 executing /bin/true?

I noticed I didn't exactly respond to this one.

> > Am I not debugging the 'make' process?

Yes you are, but, 'make' vforked (notice the [New process...] message,
and then execed /bin/true.  You only see the "Attaching after fork..."
message with "info verbose on" (linux-nat.c:linux_child_follow_fork).
If you do "info inferiors" or "info sspaces", you should see you're
debugging both /usr/bin/make and /bin/true simultaneously at this point.

> Ah, but you're debugging in all-stop mode.  What this means
> is that a program exit is a reason to stop everything and report
> to the user.  This was /bin/true exiting.  Check "info inferiors",
> and you should still see other inferiors there, waiting for you
> to tell them to continue execution.

-- 
Pedro Alves

Re: Multi-exec patches

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Tom> ... which is a little odd, since no build was done.
Tom> And, what's with process 3931 executing /bin/true?
Tom> Am I not debugging the 'make' process?

Pedro> Ah, but you're debugging in all-stop mode.  What this means
Pedro> is that a program exit is a reason to stop everything and report
Pedro> to the user.  This was /bin/true exiting.  Check "info inferiors",
Pedro> and you should still see other inferiors there, waiting for you
Pedro> to tell them to continue execution.

I didn't see anything else in "info inferiors", but I am not sure I am
doing it at the right time.

I made gdb crash while trying it again today:

(gdb) set non-stop on
(gdb) set detach-on-fork off 
(gdb) run 
Starting program: /usr/bin/make 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Can not resume the parent process over vfork in the foreground while 
holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
Recursive internal problem.
Aborted


I also got this strange result:

(gdb) set detach-on-fork off
(gdb) set schedule-multiple on
(gdb) set non-stop on
(gdb) run
Starting program: /usr/bin/make 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New process 21131]
Couldn't get registers: No such process.
(gdb) info inf
  Id   Target ID         SSpace Main Program      
* 2    process 21131     2                        
  1    process 21128     1      /usr/bin/make     


Also, "ps" showed me several /usr/bin/make processes still hanging
around from the other day's debugging attempts.

Tom> A minor nit: I think "is executing a new program" would read better.

Pedro> See?  That was the *only* string I changed, and it's picky.  :-)
Pedro> I should have left that out of the patch.  :-)

Hahaha.  I'm sorry about that.  I do try to avoid bikeshedding of this
sort, but now I've discovered that I only *think* I try ;)

Pedro> You need to try it with non-stop mode on.  It should work like you
Pedro> seem to want it to.   See the "bootstrapping" gdb example here:
Pedro>  http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html

Ok, this worked much better.  I was able to interrupt a cc1 process
during make!

I did see this, I don't know if it is intended:

(gdb) kill
Kill the program being debugged? (y or n) y
You can't do that without a process to debug.


After interrupting cc1, I used "quit".  gdb exited, but then the make
resumed in the background.


gdb seems somewhat sluggish when I run 'make' in it.  Perhaps it is just
because my system is under load.

I see now that inferior output is going to be a problem in this mode, at
least when using gdb in a terminal.

I ran into another crash somehow:

../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.

I don't know whether I can reproduce this one.  I tried setting a
pending breakpoint in c_common_init_options and then running make.

Pedro> ( Long term, I'd very much like to fuse all-stop into non-stop.  That is,
Pedro> implement all-stop mode on top of non-stop+async, and so have make the
Pedro> UI (especially the number of setting required to activate), much reduced.
Pedro> We're still a bit far from that... )

Sounds good.

Tom

Re: Multi-exec patches

[Tom Tromey]

Tom> Can not resume the parent process over vfork in the foreground while 
Tom> holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
Tom> Recursive internal problem.
Tom> Aborted

I've appended the stack trace for this.

Tom> ../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.

I couldn't reproduce this one.

I watched gdb run make a little more closely and I think the
sluggishness just comes from re-reading gcc's debuginfo each time make
starts a new gcc process.

I thought we may want some heuristic to keep debuginfo around a little
while before discarding it, for situations like this; but maybe speeding
up debuginfo reading would solve the problem more cleanly.

Tom

#0  0x0020f422 in __kernel_vsyscall ()
#1  0x005987c1 in raise () from /lib/libc.so.6
#2  0x0059a092 in abort () from /lib/libc.so.6
#3  0x080af8cb in internal_vproblem (problem=0x8cede58, 
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    fmt=0x8642430 "%s: Assertion `%s' failed.", ap=0xbfffed6c "\343'd\bK$d\b")
    at ../../archer/gdb/utils.c:897
#4  0x080afa9a in internal_verror (
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    fmt=0x8642430 "%s: Assertion `%s' failed.", ap=0xbfffed6c "\343'd\bK$d\b")
    at ../../archer/gdb/utils.c:995
#5  0x080afad2 in internal_error (
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    string=0x8642430 "%s: Assertion `%s' failed.")
    at ../../archer/gdb/utils.c:1004
#6  0x080ba9e6 in current_inferior () at ../../archer/gdb/inferior.c:44
#7  0x080bbc27 in terminal_ours_1 (output_only=0)
    at ../../archer/gdb/inflow.c:369
#8  0x080bbc02 in terminal_ours () at ../../archer/gdb/inflow.c:347
#9  0x0819ecf8 in linux_nat_terminal_ours ()
    at ../../archer/gdb/linux-nat.c:4563
#10 0x080af830 in internal_vproblem (problem=0x8cede58, 
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    fmt=0x8642430 "%s: Assertion `%s' failed.", ap=0xbfffeebc "\343'd\bK$d\b")
    at ../../archer/gdb/utils.c:912
#11 0x080afa9a in internal_verror (
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    fmt=0x8642430 "%s: Assertion `%s' failed.", ap=0xbfffeebc "\343'd\bK$d\b")
    at ../../archer/gdb/utils.c:995
#12 0x080afad2 in internal_error (
    file=0x864244f "../../archer/gdb/inferior.c", line=44, 
    string=0x8642430 "%s: Assertion `%s' failed.")
    at ../../archer/gdb/utils.c:1004
#13 0x080ba9e6 in current_inferior () at ../../archer/gdb/inferior.c:44
#14 0x08244038 in switch_to_thread (ptid={pid = 22083, lwp = 22083, tid = 0})
    at ../../archer/gdb/thread.c:875
#15 0x08238934 in handle_inferior_event (ecs=0xbffff11c)
    at ../../archer/gdb/infrun.c:2885
#16 0x08237912 in wait_for_inferior (treat_exec_as_sigtrap=0)
    at ../../archer/gdb/infrun.c:2261
#17 0x0823704f in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0)
    at ../../archer/gdb/infrun.c:1866
#18 0x08230f41 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0)
    at ../../archer/gdb/infcmd.c:577
#19 0x08230f71 in run_command (args=0x0, from_tty=1)
    at ../../archer/gdb/infcmd.c:587
#20 0x081bb80b in do_cfunc (c=0x8f0bcf0, args=0x0, from_tty=1)
    at ../../archer/gdb/cli/cli-decode.c:67
#21 0x081bde6a in cmd_func (cmd=0x8f0bcf0, args=0x0, from_tty=1)
    at ../../archer/gdb/cli/cli-decode.c:1738
#22 0x080ad20c in execute_command (p=0x8e9d9a3 "", from_tty=1)
    at ../../archer/gdb/top.c:442
#23 0x0824c37c in command_handler (command=0x8e9d9a0 "")
    at ../../archer/gdb/event-top.c:511
#24 0x0824c9ae in command_line_handler (
    rl=0x8f8f0a8 "\230\25\371\b\250\25\371\b")
    at ../../archer/gdb/event-top.c:735
#25 0x0832cf5e in rl_callback_read_char ()
    at ../../archer/readline/callback.c:205
#26 0x0824bb13 in rl_callback_read_char_wrapper (client_data=0x0)
    at ../../archer/gdb/event-top.c:178
#27 0x0824c249 in stdin_event_handler (error=0, client_data=0x0)
    at ../../archer/gdb/event-top.c:433
#28 0x0824afdc in handle_file_event (data={ptr = 0x0, integer = 0})
    at ../../archer/gdb/event-loop.c:812
#29 0x0824a820 in process_event () at ../../archer/gdb/event-loop.c:394
#30 0x0824a8e4 in gdb_do_one_event (data=0x0)
    at ../../archer/gdb/event-loop.c:459
#31 0x082458d0 in catch_errors (func=0x824a82e <gdb_do_one_event>, 
    func_args=0x0, errstring=0x866a906 "", mask=6)
    at ../../archer/gdb/exceptions.c:510
#32 0x081ce259 in tui_command_loop (data=0x0)
    at ../../archer/gdb/tui/tui-interp.c:153
#33 0x08245e48 in current_interp_command_loop ()
    at ../../archer/gdb/interps.c:291
#34 0x080a5a8b in captured_command_loop (data=0x0)
    at ../../archer/gdb/main.c:226
#35 0x082458d0 in catch_errors (func=0x80a5a80 <captured_command_loop>, 
    func_args=0x0, errstring=0x863ca18 "", mask=6)
    at ../../archer/gdb/exceptions.c:510
#36 0x080a6985 in captured_main (data=0xbffff6c0)
    at ../../archer/gdb/main.c:902
#37 0x082458d0 in catch_errors (func=0x80a5ac1 <captured_main>, 
    func_args=0xbffff6c0, errstring=0x863ca18 "", mask=6)
    at ../../archer/gdb/exceptions.c:510
#38 0x080a69bb in gdb_main (args=0xbffff6c0) at ../../archer/gdb/main.c:911
#39 0x080a5813 in main (argc=2, argv=0xbffff784) at ../../archer/gdb/gdb.c:33

Re: Multi-exec patches

[Pedro Alves]

On Monday 27 July 2009 18:12:45, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Tom> ... which is a little odd, since no build was done.
> Tom> And, what's with process 3931 executing /bin/true?
> Tom> Am I not debugging the 'make' process?
> 
> Pedro> Ah, but you're debugging in all-stop mode.  What this means
> Pedro> is that a program exit is a reason to stop everything and report
> Pedro> to the user.  This was /bin/true exiting.  Check "info inferiors",
> Pedro> and you should still see other inferiors there, waiting for you
> Pedro> to tell them to continue execution.
> 
> I didn't see anything else in "info inferiors", but I am not sure I am
> doing it at the right time.

Here's a full session of what I see, minus the "no debugging symbols
found" messages, where is shows all-stop's behaviour regarding
program exits:

>./gdb /usr/bin/make
GNU gdb (GDB) 6.8.50.20090725-cvs
<snip license etc.>
(gdb) set detach-on-fork off
(gdb) set schedule-multiple on
(gdb) run
Starting program: /usr/bin/make
[Thread debugging using libthread_db enabled]
[New process 2043]
[Thread debugging using libthread_db enabled]
process 2043 is executing new program: /bin/bash
process 2043 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[1]: Entering directory `/home/pedro/gdb/sspaces/build/gdb'
[New process 2044]
[Thread debugging using libthread_db enabled]
process 2044 is executing new program: /bin/bash
[New process 2045]
[New process 2046]
process 2046 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[2]: Entering directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'
make  all-am
[New process 2047]
[Thread debugging using libthread_db enabled]
process 2047 is executing new program: /bin/bash
process 2047 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[3]: Entering directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'

Program exited normally.
(gdb) info inferiors
  Id   Target ID         SSpace Main Program
  5    process 2046      5      /usr/bin/make
  4    process 2045      4      /bin/bash
  3    process 2044      3      /bin/bash
  2    process 2043      2      /usr/bin/make
  1    process 2040      1      /usr/bin/make

No selected inferior/thread.  See `help thread' or `help inferior'.
(gdb) info sspaces
  Id   Main Program
* 6    /usr/bin/make
  5    /usr/bin/make
        Bound inferiors: ID 5 (process 2046)
  4    /bin/bash
        Bound inferiors: ID 4 (process 2045)
  3    /bin/bash
        Bound inferiors: ID 3 (process 2044)
  2    /usr/bin/make
        Bound inferiors: ID 2 (process 2043)
  1    /usr/bin/make
        Bound inferiors: ID 1 (process 2040)
(gdb)   
(gdb) q
A debugging session is active.

        Inferior 5 [process 2046] will be killed.
        Inferior 4 [process 2045] will be killed.
        Inferior 3 [process 2044] will be killed.
        Inferior 2 [process 2043] will be killed.
        Inferior 1 [process 2040] will be killed.

Do you still want to close the debugger? (y or n) y


We could have a way to make GDB not drop to the CLI
when a program exits, and continue debugging the other
inferiors until they hit a breakpoint or any other event.
That's probably what people would want most of the times
in all-stop mode.  I've been thinking that we'd do that by
defaulting to not drop to the cli on program exits (unless
it's the last inferior of course) and implementing
a "catch exit" to catch exits; or, to have a new user knob for
this ("set stop-on-exit" or something), or make it so
that the behaviour is dependant on schedule-multiple (not so
sure on this one).  I didn't propose any of this, because
frankly, I'm not sure the best UI for it, and, most
importantly, this is the behaviour of what we have had with
multi-forks.  E.g., with gdb 6.8:

>gdb ./testsuite/gdb.base/multi-forks
...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/multi-forks
2643 ready
2643 done
Program exited normally.
[Switching to process 2650]
(gdb) info forks
* 4 process 2650 at 0x7f0082722c4b, <fork>
  3 process 2649 at 0x7f0082722c4b, <fork>
  2 process 2648 at 0x7f0082722c4b, <fork>
  1 process 2647 at 0x7f0082722c4b, <fork>
(gdb)

As I said before, I'm not aiming at changing the current
default behaviours of all-stop with this patch set, I'm
mostly aiming at adding the backend infrustructure first.

> I made gdb crash while trying it again today:
> 
> (gdb) set non-stop on
> (gdb) set detach-on-fork off 
> (gdb) run 
> Starting program: /usr/bin/make 
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> Can not resume the parent process over vfork in the foreground while 
> holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
> Recursive internal problem.
> Aborted

Can you get me a backtrace, to see what happened here?

> I also got this strange result:
> 
> (gdb) set detach-on-fork off
> (gdb) set schedule-multiple on
> (gdb) set non-stop on
> (gdb) run
> Starting program: /usr/bin/make 
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [New process 21131]
> Couldn't get registers: No such process.

This usually means that GDB tried to read registers from
an LWP that wasn't stopped.  I'll try to catch this one.
Are those commands above the whole set of commands?  I
assume that you issued "set target-async on" and "set pagination off"
somewhere too?

> (gdb) info inf
>   Id   Target ID         SSpace Main Program      
> * 2    process 21131     2                        
>   1    process 21128     1      /usr/bin/make     

It looks like the error above happened while handling an exec event,
--- we can see there's a new fork process due to the [New process...]
message, and we can assume that it's execing --- and as GDB didn't get
a chance of loading the new process's executable, the symbol space
does not have a main program loaded.

> Pedro> You need to try it with non-stop mode on.  It should work like you
> Pedro> seem to want it to.   See the "bootstrapping" gdb example here:
> Pedro>  http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html
> 
> Ok, this worked much better.  I was able to interrupt a cc1 process
> during make!

Cool!

> 
> I did see this, I don't know if it is intended:
> 
> (gdb) kill
> Kill the program being debugged? (y or n) y
> You can't do that without a process to debug.

This means that target was no longer pushed on the stack...

> After interrupting cc1, I used "quit".  gdb exited, but then the make
> resumed in the background.

We've talked a bit on IRC, and concluded that you missed applying
patch 2/2 of the mini series, which accounts for at least this one and
the one one above, if not more.

> I ran into another crash somehow:
> 
> ../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.
> 
> I don't know whether I can reproduce this one.  I tried setting a
> pending breakpoint in c_common_init_options and then running make.

If you have a chance to retry, could you please let me know if you
can reproduce this one with patch 2/2 of the mini-series applied ?

Thanks!

-- 
Pedro Alves

Re: Multi-exec patches

[Tom Tromey]

Tom> Can not resume the parent process over vfork in the foreground while 
Tom> holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
Tom> Recursive internal problem.
Tom> Aborted

Pedro> Can you get me a backtrace, to see what happened here?

For the record, I sent this in a separate note, the other day.

Tom> I also got this strange result:
Tom> (gdb) set detach-on-fork off
Tom> (gdb) set schedule-multiple on
Tom> (gdb) set non-stop on
Tom> (gdb) run
[...]
Pedro> This usually means that GDB tried to read registers from
Pedro> an LWP that wasn't stopped.  I'll try to catch this one.
Pedro> Are those commands above the whole set of commands?  I
Pedro> assume that you issued "set target-async on" and "set pagination off"
Pedro> somewhere too?

Nope!  So that is probably the problem.

Tom> Ok, this worked much better.  I was able to interrupt a cc1 process
Tom> during make!

Pedro> Cool!

I also tried setting a pending breakpoint on a function in cc1, then
running "make".  Nothing ever stopped at the breakpoint.  Is this
expected?

Tom> ../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.

Pedro> If you have a chance to retry, could you please let me know if you
Pedro> can reproduce this one with patch 2/2 of the mini-series applied ?

I tried this and couldn't reproduce it.

Tom

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Ulrich Weigand]

Pedro Alves wrote:
> On Thursday 23 July 2009 17:31:02, Ulrich Weigand wrote:
> 
> > Thinking about it a bit more, it seems that in the context of Pedro's
> > patches, this flag really needs to be a symbol-space property, not an
> > inferior property: it basically says that objfiles in this symbol
> > space have not yet been relocated to their final addresses and therefore
> > cannot be used to determine breakpoint addresses.
> > 
> > In the situation where multiple inferiors potentially share a symbol
> > space, this property applies to all of them.  Also, with Pedro's
> > patches breakpoints will be per-symbol-space, not per-inferior, so
> > we'll have to disable/re-enable all breakpoints in a given symbol
> > space (we cannot really disable all breakpoints of a given inferior,
> > as this information is not actually known).
> > 
> > So it seems that after all adding the flag to struct inferior now
> > might be a step in the wrong direction; it should instead be added to
> > struct symbol_space once Pedro's patches are in.
> > 
> > Pedro, any comments?
> 
> Yes, I agree with you.  (although in the only target supporting
> shared symbol space, DICOS, we don't run or start programs, we only
> attach to already running ones, and if we did [it would be possible to
> add such feature], the code is always already all relocated when we
> connect --- due to the global shared libraries feature of DICOS.)
> 
> While Tom's right, there has been a stream of changes recently that
> constantly require that I adjust the multi-exec patch set, I'll handle
> this one easily when your patch is in; I don't think it will
> be much trouble.

Thanks, Pedro!  I've checked the patch in now; if you have any issues
in adapting the multi-exec patch, please let me know; I'd be happy
to help ...

Bye,
Ulrich

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

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Thiago Jung Bauermann]

Em Sexta-feira 31 Julho 2009 11:35:29 Ulrich Weigand escreveu:
> Thanks, Pedro!  I've checked the patch in now; if you have any issues
> in adapting the multi-exec patch, please let me know; I'd be happy
> to help ...

The explanation in the first message in this thread is the kind of thing that 
fits perfectly in the GDB Internals manual. If you don't have the time or 
inclination to add the text there, I can do it.

But in the long run IMHO we want to start a tradition of creating patches to 
gdbint.texinfo for this kind of "plumbing" work. :^)
-- 
[]'s
Thiago Jung Bauermann

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Eli Zaretskii]

> From: Thiago Jung Bauermann <thiago.bauermann@gmail.com>
> Date: Mon, 3 Aug 2009 00:08:58 -0300
> Cc: "Ulrich Weigand" <uweigand@de.ibm.com>,  Pedro Alves <pedro@codesourcery.com>,  tromey@redhat.com,  Jan Kratochvil <jkratoch@redhat.com>
> 
> But in the long run IMHO we want to start a tradition of creating patches to 
> gdbint.texinfo for this kind of "plumbing" work. :^)

Yes, definitely.

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Ulrich Weigand]

Eli Zaretskii wrote:
> > From: Thiago Jung Bauermann <thiago.bauermann@gmail.com>
> > Date: Mon, 3 Aug 2009 00:08:58 -0300
> > Cc: "Ulrich Weigand" <uweigand@de.ibm.com>,  Pedro Alves <pedro@codesourcery.com>,  tromey@redhat.com,  Jan Kratochvil <jkratoch@redhat.com>
> > 
> > But in the long run IMHO we want to start a tradition of creating patches to 
> > gdbint.texinfo for this kind of "plumbing" work. :^)
> 
> Yes, definitely.

I'll be happy to add documentation to gdbint.texinfo, but I'm not quite
sure where to start.  This patch was about handling breakpoints when the
main objfile is relocated during startup.  Where does this fit in the
current structure of the manual?  A natural place might be a section on
how relocation is handled in general, typically in the context of shared
libraries ... but these topics are not currently covered at all.

Any suggestions where to start here?

Thanks,
Ulrich

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

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Eli Zaretskii]

> Date: Wed, 5 Aug 2009 20:14:13 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: thiago.bauermann@gmail.com (Thiago Jung Bauermann),
>         gdb-patches@sourceware.org, pedro@codesourcery.com, tromey@redhat.com,
>         jkratoch@redhat.com
> 
> I'll be happy to add documentation to gdbint.texinfo, but I'm not quite
> sure where to start.  This patch was about handling breakpoints when the
> main objfile is relocated during startup.  Where does this fit in the
> current structure of the manual?  A natural place might be a section on
> how relocation is handled in general, typically in the context of shared
> libraries ... but these topics are not currently covered at all.
> 
> Any suggestions where to start here?

You could add a new chapter about relocations and have it include a
single section about the issue you were talking about.  gdbint.texinfo
looks like a car crash anyway (and what's worse, there's a lot of
outdated information there), so I wouldn't at this time be worried
about form too much, just about the content.

TIA

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Tom Tromey]

Ulrich> I'll be happy to add documentation to gdbint.texinfo, but I'm
Ulrich> not quite sure where to start.

It seems to me that in many cases the documentation would be more
helpful if it were near the things it documented.

For example, consider all the text in gdbint.texinfo concerning
cleanups.  It is quite useful to read when one is new to GDB; I've
pointed several people at it.  However, I think that if it were comments
near the declarations of cleanup functions in a header file, I probably
would not have to point people to it -- they would read it naturally as
a consequence of looking up calls to make_cleanup.

Also, it is simpler to remember to require changes to comments near the
code than to gdbint.texinfo.


I think there is still a need for an internals document, because there
are things worth documenting that don't have a natural location in a
source file.  I'm thinking of things like coding conventions, HIG
guidelines for new commands, etc -- things that affect future decisions
but that are not inherent in the code.

Tom

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Eli Zaretskii]

> Cc: eliz@gnu.org, thiago.bauermann@gmail.com (Thiago Jung Bauermann),
>         gdb-patches@sourceware.org, pedro@codesourcery.com,
>         jkratoch@redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Thu, 06 Aug 2009 09:58:54 -0600
> 
> I think there is still a need for an internals document, because there
> are things worth documenting that don't have a natural location in a
> source file.  I'm thinking of things like coding conventions, HIG
> guidelines for new commands, etc -- things that affect future decisions
> but that are not inherent in the code.

That's one reason for the internals manual.  The other -- which IMO is
a more important one (but I'm in minority here) -- is that Texinfo
allows you to organize the documentation for easy reading in ways code
comments never will.  You cannot have index entries in comments, and
you cannot have cross-references which are easy to be followed, two
features without which reading about a complicated topic described in
several places is a PITA.

So ideally, we should have both code comments and corresponding manual
docs, IMO.

Re: [rfc] Infrastructure to disable breakpoints during inferior startup

[Michael Snyder]

Eli Zaretskii wrote:
>> Cc: eliz@gnu.org, thiago.bauermann@gmail.com (Thiago Jung Bauermann),
>>         gdb-patches@sourceware.org, pedro@codesourcery.com,
>>         jkratoch@redhat.com
>> From: Tom Tromey <tromey@redhat.com>
>> Date: Thu, 06 Aug 2009 09:58:54 -0600
>>
>> I think there is still a need for an internals document, because there
>> are things worth documenting that don't have a natural location in a
>> source file.  I'm thinking of things like coding conventions, HIG
>> guidelines for new commands, etc -- things that affect future decisions
>> but that are not inherent in the code.
> 
> That's one reason for the internals manual.  The other -- which IMO is
> a more important one (but I'm in minority here) -- is that Texinfo
> allows you to organize the documentation for easy reading in ways code
> comments never will.  You cannot have index entries in comments, and
> you cannot have cross-references which are easy to be followed, two
> features without which reading about a complicated topic described in
> several places is a PITA.
> 
> So ideally, we should have both code comments and corresponding manual
> docs, IMO.

I'm with Eli, FWIW.  We need both.
We'll never document everything in the internals manual,
but the more the better.