Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix problems with finishing a dummy function call on simulators.
Date: Wed, 17 Jun 2015 13:26:00 -0000	[thread overview]
Message-ID: <55817569.7060704@codesourcery.com> (raw)
In-Reply-To: <55816AD5.6020605@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

On 06/17/2015 09:40 AM, Pedro Alves wrote:
> On 06/09/2015 07:22 PM, Luis Machado wrote:
>> One strange side effect of this change on my local machine (x86-64) is
>> that gdb.threads/attach-many-short-lived-threads.exp gives me PASS
>> instead of FAIL when always-inserted mode is ON. I didn't investigate
>> this further though.
>
> You mean you _always_ get a FAIL before your patch?  This test sometimes
> FAILs for an unknown reason, but it's racy -- it should be passing most of
> the time.
>

I went back to this and yes, it is indeed racy. It just so happens that 
it failed both times i checked the results of an unpatched testsuite 
run. :-)

>> Is this patch what you had in mind?
>
> Yep.  Close, but also remove the bp_call_dummy check in
> bp_loc_is_permanent, and merge in its comment, like ...
>

Fixed now.

>> diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
>> index eb3df02..768ce59 100644
>> --- a/gdb/breakpoint.c
>> +++ b/gdb/breakpoint.c
>> @@ -7440,15 +7440,16 @@ make_breakpoint_permanent (struct breakpoint *b)
>>     struct bp_location *bl;
>>
>>     /* By definition, permanent breakpoints are already present in the
>> -     code.  Mark all locations as inserted.  For now,
>> -     make_breakpoint_permanent is called in just one place, so it's
>> -     hard to say if it's reasonable to have permanent breakpoint with
>> -     multiple locations or not, but it's easy to implement.  */
>> +     code.  For now, make_breakpoint_permanent is called in just one place, so
>> +     it's hard to say if it's reasonable to have permanent breakpoint with
>> +     multiple locations or not, but it's easy to implement.
>> +
>> +     Permanent breakpoints are not marked as inserted so we allow other
>> +     non-permanent locations at the same address to be inserted on top
>> +     of it.  This is required due to some targets, simulators mostly, not
>> +     dealing properly with hardwired breakpoints in the code.  */
>
> ... this:
>
>      /* While by definition, permanent breakpoints are already present in the
>         code, we don't mark the location as inserted.  Normally one would expect
>         that GDB could rely on that breakpoint instruction to stop the program, thus
>         removing the need to insert its own breakpoint, except that executing the
>         breakpoint instruction can kill the target instead of reporting a SIGTRAP.
>         E.g., on SPARC, when interrupts are disabled, executing the instruction
>         resets the CPU, so QEMU 2.0.0 for SPARC correspondingly dies
>         with "Trap 0x02 while interrupts disabled, Error state".  Letting the
>         breakpoint be inserted normally results in QEMU knowing about the GDB
>         breakpoint, and thus trap before the breakpoint instruction is executed.
>         (If GDB later needs to continue execution past the permanent breakpoint,
>         it manually increments the PC, thus avoiding executing the breakpoint
>         instruction.)
>
>>     for (bl = b->loc; bl; bl = bl->next)
>> -    {
>> -      bl->permanent = 1;
>> -      bl->inserted = 1;
>> -    }
>> +    bl->permanent = 1;
>>   }
>>

I've updated this now.

>
> Actually, make_breakpoint_permanent is dead and should be deleted.  The
> last remaining caller is finally gone - it was one of the old Unix ports
> we removed.  So the comment should be moved to add_location_to_breakpoint
> instead.

Ah, that explains why i couldn't find callers of that function, but the 
build didn't fail due to it being unused.

The attached updated patch also removes this dead function. I can commit 
it as a separate patch if you're not removing it yourself.

Thanks!

[-- Attachment #2: bp_permanent_v2.diff --]
[-- Type: text/x-patch, Size: 4863 bytes --]

2015-06-17  Luis Machado  <lgustavo@codesourcery.com>

	* breakpoint.c (make_breakpoint_permanent): Remove unused
	function.
	(add_location_to_breakpoint): Don't mark permanent locations as
	inserted.
	Update and expand comment about permanent locations.
	(bp_loc_is_permanent): Don't return 0 for bp_call_dummy.
	Move comment to add_location_to_breakpoint.
	(update_global_location_list): Don't error out if a permanent
	breakpoint is not marked inserted.
	Don't error out if a non-permanent breakpoint location is inserted on
	top of a permanent breakpoint.

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 657c58e..d731f1f 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -7431,26 +7431,6 @@ set_raw_breakpoint (struct gdbarch *gdbarch,
   return b;
 }
 
-
-/* Note that the breakpoint object B describes a permanent breakpoint
-   instruction, hard-wired into the inferior's code.  */
-void
-make_breakpoint_permanent (struct breakpoint *b)
-{
-  struct bp_location *bl;
-
-  /* By definition, permanent breakpoints are already present in the
-     code.  Mark all locations as inserted.  For now,
-     make_breakpoint_permanent is called in just one place, so it's
-     hard to say if it's reasonable to have permanent breakpoint with
-     multiple locations or not, but it's easy to implement.  */
-  for (bl = b->loc; bl; bl = bl->next)
-    {
-      bl->permanent = 1;
-      bl->inserted = 1;
-    }
-}
-
 /* Call this routine when stepping and nexting to enable a breakpoint
    if we do a longjmp() or 'throw' in TP.  FRAME is the frame which
    initiated the operation.  */
@@ -8918,11 +8898,21 @@ add_location_to_breakpoint (struct breakpoint *b,
   set_breakpoint_location_function (loc,
 				    sal->explicit_pc || sal->explicit_line);
 
+  /* While by definition, permanent breakpoints are already present in the
+     code, we don't mark the location as inserted.  Normally one would expect
+     that GDB could rely on that breakpoint instruction to stop the program,
+     thus removing the need to insert its own breakpoint, except that executing
+     the breakpoint instruction can kill the target instead of reporting a
+     SIGTRAP.  E.g., on SPARC, when interrupts are disabled, executing the
+     instruction resets the CPU, so QEMU 2.0.0 for SPARC correspondingly dies
+     with "Trap 0x02 while interrupts disabled, Error state".  Letting the
+     breakpoint be inserted normally results in QEMU knowing about the GDB
+     breakpoint, and thus trap before the breakpoint instruction is executed.
+     (If GDB later needs to continue execution past the permanent breakpoint,
+     it manually increments the PC, thus avoiding executing the breakpoint
+     instruction.)  */
   if (bp_loc_is_permanent (loc))
-    {
-      loc->inserted = 1;
-      loc->permanent = 1;
-    }
+    loc->permanent = 1;
 
   return loc;
 }
@@ -8974,20 +8964,6 @@ bp_loc_is_permanent (struct bp_location *loc)
 
   gdb_assert (loc != NULL);
 
-  /* bp_call_dummy breakpoint locations are usually memory locations
-     where GDB just wrote a breakpoint instruction, making it look
-     as if there is a permanent breakpoint at that location.  Considering
-     it permanent makes GDB rely on that breakpoint instruction to stop
-     the program, thus removing the need to insert its own breakpoint
-     there.  This is normally expected to work, except that some versions
-     of QEMU (Eg: QEMU 2.0.0 for SPARC) just report a fatal problem (Trap
-     0x02 while interrupts disabled, Error state) instead of reporting
-     a SIGTRAP.  QEMU should probably be fixed, but in the interest of
-     compatibility with versions that behave this way, we always consider
-     bp_call_dummy breakpoint locations as non-permanent.  */
-  if (loc->owner->type == bp_call_dummy)
-    return 0;
-
   cleanup = save_current_space_and_thread ();
   switch_to_program_space_and_thread (loc->pspace);
 
@@ -12430,12 +12406,6 @@ update_global_location_list (enum ugll_insert_mode insert_mode)
 	  continue;
 	}
 
-      /* Permanent breakpoint should always be inserted.  */
-      if (loc->permanent && ! loc->inserted)
-	internal_error (__FILE__, __LINE__,
-			_("allegedly permanent breakpoint is not "
-			"actually inserted"));
-
       if (b->type == bp_hardware_watchpoint)
 	loc_first_p = &wp_loc_first;
       else if (b->type == bp_read_watchpoint)
@@ -12471,12 +12441,6 @@ update_global_location_list (enum ugll_insert_mode insert_mode)
 
       /* Clear the condition modification flag.  */
       loc->condition_changed = condition_unchanged;
-
-      if (loc->inserted && !loc->permanent
-	  && (*loc_first_p)->permanent)
-	internal_error (__FILE__, __LINE__,
-			_("another breakpoint was inserted on top of "
-			"a permanent breakpoint"));
     }
 
   if (insert_mode == UGLL_INSERT || breakpoints_should_be_inserted_now ())

  reply	other threads:[~2015-06-17 13:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-09 15:01 Luis Machado
2015-06-09 17:51 ` Pedro Alves
2015-06-09 18:10   ` Luis Machado
2015-06-09 18:13     ` Pedro Alves
2015-06-09 18:22       ` Luis Machado
2015-06-09 18:34       ` Luis Machado
2015-06-16 17:39   ` Luis Machado
2015-06-17 12:41     ` Pedro Alves
2015-06-17 13:26       ` Luis Machado [this message]
2015-06-17 13:43         ` Pedro Alves
2015-06-17 20:16           ` Luis Machado
2015-07-06 15:06             ` Pedro Alves
2015-07-06 15:33               ` Luis Machado
2015-07-06 16:15                 ` Pedro Alves
2015-07-06 16:18                   ` Luis Machado
2015-07-06 18:34                   ` Luis Machado
2015-07-06 19:07                     ` Pedro Alves
2015-07-06 19:11                       ` Luis Machado

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=55817569.7060704@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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