Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] ia64: Fix breakpoints memory shadow
Date: Thu, 30 Oct 2008 01:51:00 -0000	[thread overview]
Message-ID: <20081029210242.GA3635@adacore.com> (raw)
In-Reply-To: <20081028172816.GA1284@host0.dyn.jankratochvil.net>

Hi Jan,

> 2008-10-28  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	Fix automatic restoration of breakpoints memory for ia64.
> 	* ia64-tdep.c (ia64_memory_insert_breakpoint): New comment part for
> 	SHADOW_CONTENTS content.  Remova variable instr.  New variable cleanup.
> 	Force automatic breakpoints restoration.  PLACED_SIZE and SHADOW_LEN
> 	are now set larger, to BUNDLE_LEN - 2.
> 	(ia64_memory_remove_breakpoint): Rename variables bundle to bundle_mem
> 	and instr to instr_saved.  New variables bundle_saved and
> 	instr_breakpoint.  Comment new reasons why we need to disable automatic
> 	restoration of breakpoints.  Assert PLACED_SIZE and SHADOW_LEN.  New
> 	check of the original memory content.
> 	(ia64_breakpoint_from_pc): Array breakpoint extended to BUNDLE_LEN.
> 	Sanity check the PCPTR parameter SLOTNUM value.  New #if check on
> 	BREAKPOINT_MAX vs. BUNDLE_LEN.  Increase LENPTR to BUNDLE_LEN - 2.

I understand the overall idea, but I don't understand the logic behind
saving BUNDLE_LEN - 2 bytes (14 bytes, then) of the bundle at bundle
address + slotnum. It looks like this introduces extra complexity.

Instead, would it be possible to save the entire bundle, when
inserting the breakpoint? When comes time to remove it, we would
only need to read the whole bundle, extract the original insn from
our saved bundle, and then push it back into the target bundle.

> +# We need to start the inferior to place the breakpoints in the memory at all.
> +if { [gdb_start_cmd] < 0 } {
> +    untested start
> +    return -1
> +}
> +gdb_test "" "main \\(\\) at .*" "start"

Why not use runto_main here?


-- 
Joel


  reply	other threads:[~2008-10-29 21:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 17:52 Jan Kratochvil
2008-10-30  1:51 ` Joel Brobecker [this message]
2008-10-31  0:03   ` Jan Kratochvil
2008-11-01 18:54     ` Joel Brobecker
2008-11-11 20:20       ` Jan Kratochvil
2008-11-13 14:27         ` Joel Brobecker
2008-11-21  1:11           ` Jan Kratochvil
2008-11-22 18:35             ` Joel Brobecker
2008-11-22 19:08             ` Eli Zaretskii
2008-11-24  2:25               ` Joel Brobecker
2008-11-24  7:09                 ` Jan Kratochvil
2008-11-25 17:49                   ` Joel Brobecker
2008-11-27  0:41                     ` Jan Kratochvil

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=20081029210242.GA3635@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@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