From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: brobecker@adacore.com (Joel Brobecker)
Cc: bauerman@br.ibm.com (Thiago Jung Bauermann),
gdb-patches@sourceware.org,
luisgpm@linux.vnet.ibm.com (Luis Machado),
tyrlik@us.ibm.com (Matt Tyrlik)
Subject: Re: [PATCH 1/4] Support the new BookE ptrace interface
Date: Thu, 11 Feb 2010 17:06:00 -0000 [thread overview]
Message-ID: <201002111706.o1BH6Yx4011034@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20100105045130.GA24777@adacore.com> from "Joel Brobecker" at Jan 05, 2010 08:51:30 AM
Joel Brobecker wrote:
> > 2009-12-31 Sergio Durigan Junior <sergiodj@linux.vnet.ibm.com>
> > Thiago Jung Bauermann <bauerman@br.ibm.com>
> >
> > * ppc-linux-nat.c (PTRACE_GET_DEBUGREG): Update comment.
> > (PPC_PTRACE_GETWDBGINFO, PPC_PTRACE_SETHWDEBUG, PPC_PTRACE_DELHWDEBUG,
> > ppc_debug_info, PPC_DEBUG_FEATURE_INSN_BP_RANGE,
> > PPC_DEBUG_FEATURE_INSN_BP_MASK, PPC_DEBUG_FEATURE_DATA_BP_RANGE,
> > PPC_DEBUG_FEATURE_DATA_BP_MASK, ppc_hw_breakpoint,
> > PPC_BREAKPOINT_TRIGGER_EXECUTE, PPC_BREAKPOINT_TRIGGER READ,
> > PPC_BREAKPOINT_TRIGGER_WRITE, PPC_BREAKPOINT_TRIGGER_RW,
> > PPC_BREAKPOINT_MODE_EXACT PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE,
> > PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE, PPC_BREAKPOINT_MODE_MASK,
> > PPC_BREAKPOINT_CONDITION_NONE, PPC_BREAKPOINT_CONDITION_AND,
> > PPC_BREAKPOINT_CONDITION_EXACT, PPC_BREAKPOINT_CONDITION_OR,
> > PPC_BREAKPOINT_CONDITION_AND_OR, PPC_BREAKPOINT_CONDITION_BE_ALL,
> > PPC_BREAKPOINT_CONDITION_BE_SHIFT, PPC_BREAKPOINT_CONDITION_BE):
> > Define, in case <ptrace.h> doesn't provide it.
> > (have_ptrace_new_debug_booke): New global.
> > (ppc_linux_check_watch_resources): Renamed to ...
> > (ppc_linux_can_use_hw_breakpoint): ... this. Handle BookE processors.
> > (booke_debug_info): New variable.
> > (max_slots_number): Ditto.
> > (hw_break_tuple): New struct.
> > (thread_points): Ditto.
> > (ppc_threads): New variable.
> > (PPC_DEBUG_CURRENT_VERSION): New define.
> > (ppc_linux_region_ok_for_hw_watchpoint): Handle BookE processors.
> > (booke_cmp_hw_point): New function.
> > (booke_find_thread_points_by_tid): Ditto.
> > (booke_insert_point): Ditto.
> > (booke_remove_point): Ditto.
> > (ppc_linux_insert_hw_breakpoint): Ditto.
> > (ppc_linux_remove_hw_breakpoint): Ditto.
> > (ppc_linux_insert_watchpoint): Handle BookE processors.
> > (ppc_linux_remove_watchpoint): Ditto.
> > (ppc_linux_new_thread): Ditto.
> > (ppc_linux_stopped_data_address): Ditto.
> > (ppc_linux_watchpoint_addr_within_range): Ditto.
> > (ppc_linux_read_description): Query the target to know if it
> > supports the new kernel BookE interface.
> > (_initialize_ppc_linux_nat): Initialize to_insert_hw_breakpoint and
> > to_remove_hw_breakpoint fields of the target operations struct.
>
> Still looks good to me :). Just a couple of nits, but otherwise approved.
> It would still be nice if Ulrich had a chance to take a quick look ;-).
Looks good to me as well. The only nit I've found is this:
@@ -1595,6 +2012,20 @@ ppc_linux_read_description (struct target_ops *ops)
perror_with_name (_("Unable to fetch AltiVec registers"));
}
+ /* Check for kernel support for new BOOKE debugging registers. */
+ if (ptrace (PPC_PTRACE_GETHWDBGINFO, tid, 0, &booke_debug_info) >= 0)
+ {
+ have_ptrace_new_debug_booke = 1;
+ max_slots_number = booke_debug_info.num_instruction_bps
+ + booke_debug_info.num_data_bps + booke_debug_info.num_condition_regs;
+ }
+ else
+ {
+ /* Old school interface and no new BOOKE registers support. */
+ have_ptrace_new_debug_booke = 0;
+ memset (&booke_debug_info, 0, sizeof (struct ppc_debug_info));
+ }
+
/* Power ISA 2.05 (implemented by Power 6 and newer processors) increases
the FPSCR from 32 bits to 64 bits. Even though Power 7 supports this
ISA version, it doesn't have PPC_FEATURE_ARCH_2_05 set, only
Setting global variables like have_ptrace_new_debug_booke as an implicit
side effect of ppc_linux_read_description isn't really nice; it makes
assumptions about the sequence in which these routines are called that
may not be guaranteed after potential future changes ...
Why not use a routine to retrieve the info that is called whereever
necessary (the routine can internally cache the data and the fact
that it useless to try as kernel support is missing)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2010-02-11 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-24 0:31 Thiago Jung Bauermann
2009-12-29 6:12 ` Joel Brobecker
2009-12-30 19:51 ` Thiago Jung Bauermann
2010-01-04 17:33 ` Thiago Jung Bauermann
2010-01-05 4:51 ` Joel Brobecker
2010-01-15 17:41 ` Luis Machado
2010-01-16 3:09 ` Luis Machado
2010-01-18 4:16 ` Joel Brobecker
2010-02-11 17:06 ` Ulrich Weigand [this message]
2010-02-22 20:27 ` Thiago Jung Bauermann
2010-02-23 19:07 ` Ulrich Weigand
2010-02-23 23:42 ` Joel Brobecker
2010-02-25 18:16 ` Ulrich Weigand
2010-04-22 22:53 ` Thiago Jung Bauermann
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=201002111706.o1BH6Yx4011034@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=bauerman@br.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=luisgpm@linux.vnet.ibm.com \
--cc=tyrlik@us.ibm.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