From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFA/commit] ia64: incorrect breakpoint save/restore with L-type instruction at slot 1
Date: Fri, 25 Sep 2009 20:48:00 -0000 [thread overview]
Message-ID: <20090925204835.GF5077@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]
Hello,
We have a small testcase at AdaCore that just puts a breakpoint
on a line of code, runs to it, and then continues past it. I am
pasting the code at the end of this email. The initial purpose
of that testcase was to stress GDB with a very large number of
Ada tasks, but this is not relevant to the issue at hand, so I reduced
the number of tasks to 2.
To reproduce the problem, compile the program pasted at the end of
this message, and build it with the following trivial gnatmake:
% gnatmake -g ct
Then, insert a breakpoint at line 51, run to this breakpoint, and
then try to continue from that breakpoint:
(gdb) b 51
Breakpoint 1 at 0x4000000000004bd1: file ct.adb, line 51.
(gdb) run
[...]
Breakpoint 1, ct () at ct.adb:51
51 delay 1.0; -- BREAK
(gdb) cont
Continuing.
Program received signal SIGILL, Illegal instruction.
ct () at ct.adb:51
51 delay 1.0; -- BREAK
The program should just run until it completes.
The problem comes from the fact that the instruction where we
insert the breakpoint is in a slot 1 and is an L type instruction.
However, we save the wrong portion of the instruction bundle before
we realize this fact, and then insert the breakpoint in slot 2:
First we store the piece of bundle assuming slot 1, then reread
the bundle this time with breakpoints inserted, realize that we
have an L-type instruction at slot 1 and thus decide to put the
breakpoint on slot 2. At this point, the wrong portion of the bundle
has been saved in the shadow contents buffer, and breakpoint removal
is broken.
2009-09-25 Joel Brobecker <brobecker@adacore.com>
* ia64-tdep.c (ia64_memory_insert_breakpoint): Check the slotnum
and the type of instruction before deciding which slot to save
in the breakpoint shadown contents.
Tested on ia64-linux. Jan, does this look right to you too? I would
normally apply immediately, but since we're close to release, a second
pair of eyes is always nice.
Thanks,
--
Joel
with Ada.Text_IO;
procedure Ct is
Number_Of_Tasks_To_Create : constant := 2;
task type T (Index : Natural; Last : Boolean) is
entry Finish;
end T;
task body T is
begin
-- Signal the creation of the task.
if Last then
Ada.Text_IO.Put_Line
("Starting task number:" & Natural'Image (Index) & " (last)");
else
Ada.Text_IO.Put_Line
("Starting task number:" & Natural'Image (Index));
end if;
-- Wait until told to finish the task. Then print a message
-- showing that the task is completing.
accept Finish do
if Last then
Ada.Text_IO.Put_Line
("End of task number:" & Natural'Image (Index) & " (last)");
else
Ada.Text_IO.Put_Line
("End of task number:" & Natural'Image (Index));
end if;
end Finish;
end T;
type TA is access T;
All_Tasks : array (Positive range 1 .. Number_Of_Tasks_To_Create) of TA;
begin
for Loop_Index in All_Tasks'Range loop
All_Tasks (Loop_Index) :=
new T (Loop_Index, Loop_Index = All_Tasks'Last);
end loop;
-- Add a delay to make sure all "Starting task ..." messages are
-- printed before Finish'ing thee tasks.
delay 1.0;
delay 1.0; -- BREAK
for Loop_Index in All_Tasks'Range loop
All_Tasks (Loop_Index).Finish;
end loop;
end Ct;
[-- Attachment #2: ia64-bp.diff --]
[-- Type: text/x-diff, Size: 1382 bytes --]
commit 1491fbdd98bd0bd63717f03f64c24bdda3917029
Author: Joel Brobecker <brobecker@adacore.com>
Date: Fri Sep 25 14:51:45 2009 -0400
Check instrunction slot num and type before deciding which slot to save.
diff --git a/gdb/ia64-tdep.c b/gdb/ia64-tdep.c
index 674204a..bbde5f6 100644
--- a/gdb/ia64-tdep.c
+++ b/gdb/ia64-tdep.c
@@ -635,6 +635,12 @@ ia64_memory_insert_breakpoint (struct gdbarch *gdbarch,
return val;
}
+ /* Check for L type instruction in slot 1, if present then bump up the slot
+ number to the slot 2. */
+ template = extract_bit_field (bundle, 0, 5);
+ if (slotnum == 1 && template_encoding_table[template][slotnum] == L)
+ slotnum = 2;
+
/* Slot number 2 may skip at most 2 bytes at the beginning. */
bp_tgt->shadow_len = BUNDLE_LEN - 2;
@@ -657,12 +663,6 @@ ia64_memory_insert_breakpoint (struct gdbarch *gdbarch,
return val;
}
- /* Check for L type instruction in slot 1, if present then bump up the slot
- number to the slot 2. */
- template = extract_bit_field (bundle, 0, 5);
- if (slotnum == 1 && template_encoding_table[template][slotnum] == L)
- slotnum = 2;
-
/* Breakpoints already present in the code will get deteacted and not get
reinserted by bp_loc_is_permanent. Multiple breakpoints at the same
location cannot induce the internal error as they are optimized into
next reply other threads:[~2009-09-25 20:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-25 20:48 Joel Brobecker [this message]
2009-09-26 21:57 ` Jan Kratochvil
2009-09-29 0:16 ` Joel Brobecker
2009-09-29 1:31 ` Joel Brobecker
2009-09-29 18:55 ` Jan Kratochvil
2009-09-29 19:14 ` Joel Brobecker
2009-09-29 19:29 ` Jan Kratochvil
2009-09-29 0:00 ` Joel Brobecker
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=20090925204835.GF5077@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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