Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Luis Gustavo <luis_gustavo@mentor.com>
Cc: gdb-patches@sourceware.org, prasad@linux.vnet.ibm.com,
	       benh@kernel.crashing.org
Subject: Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.
Date: Mon, 06 Aug 2012 18:40:00 -0000	[thread overview]
Message-ID: <20120806170405.GA9225@host2.jankratochvil.net> (raw)
In-Reply-To: <501FD5D6.30005@mentor.com>

On Mon, 06 Aug 2012 16:33:58 +0200, Luis Gustavo wrote:
> With the somewhat recent booke kernel interface, more hw
> watchpoints/breakpoints are available to GDB.

Which hardware can be BookE tested on?  Red Hat has available for example
PPC970FX, POWER5, POWER7 etc. but those AFAIK are not BookE.  Or does it
depend just on kernel?


> The logic of replicating the existing process' debug state to the
> new thread is still there though, but the new booke interface in the
> kernel already replicates that state. More precisely, the kernel
> gives the new thread the debug state of its parent thread.

I have been testing it recently for fork() (processes, no threads) and my
results were:

kernel-3.3.4-5.fc17.ppc64 clears debug info in both parent (!) and child
kernel-2.6.18-308.el5.ppc64 copies debug info to child and keeps it in parent


> It's still unclear if the kernel is supposed to do this and i'm
> chasing answers with the ppc linux kernel folks (https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-August/100083.html).
> Nonetheless, the kernel is out and it has such behavior.

Yes, I agree GDB should cope with all these kinds of behavior.


> --- gdb_head.orig/gdb/ppc-linux-nat.c	2012-08-06 11:02:12.538532628 -0300
> +++ gdb_head/gdb/ppc-linux-nat.c	2012-08-06 11:04:38.486536320 -0300
> @@ -2179,7 +2179,21 @@ ppc_linux_new_thread (struct lwp_info *l
>        /* Copy that thread's breakpoints and watchpoints to the new thread.  */
>        for (i = 0; i < max_slots_number; i++)
>  	if (hw_breaks[i].hw_break)
> -	  booke_insert_point (hw_breaks[i].hw_break, tid);
> +	  {
> +	    /* The ppc Linux kernel causes a thread to inherit its parent
> +	       thread's debug state, and that includes any hardware
> +	       watchpoints or breakpoints that the parent thread may have set.
> +
> +	       For this reason, the debug state of the new thread is cleared
> +	       before trying to replicate any hardware watchpoints or
> +	       breakpoints contained in other threads.  */
> +
> +	    /* The ppc debug resource accounting is done through "slots".
> +	       Ask the kernel the deallocate this specific *point's slot.  */
> +	    ptrace (PPC_PTRACE_DELHWDEBUG, tid, 0, hw_breaks[i].slot);
> +
> +	    booke_insert_point (hw_breaks[i].hw_break, tid);

I agree with the patch.

I was considering to call PPC_PTRACE_DELHWDEBUG unconditionally but that would
be probably an unneeded overhead.

Did you test that kernel really does not reorder the [i] slots during
inheritance into the new thread?


> +	  }
>      }
>    else
>      ptrace (PTRACE_SET_DEBUGREG, tid, 0, saved_dabr_value);


> This would be nice to include before 7.5, as it's an annoying problem.

Does this fix affect existing testcases on BookE?
Otherwise a new testcase would be appropriate.


Thanks,
Jan


  reply	other threads:[~2012-08-06 18:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-06 14:33 Luis Gustavo
2012-08-06 18:40 ` Jan Kratochvil [this message]
2012-08-06 19:02   ` Luis Gustavo
2012-08-06 20:28     ` Jan Kratochvil
2012-08-07 14:55       ` Luis Gustavo
2012-08-07 15:00         ` Jan Kratochvil
2012-08-07 15:02           ` Luis Gustavo
2012-12-27 19:50 ` Luis Machado
2013-01-22 12:12   ` Pedro Alves
2013-04-17 20:33 Luis Machado
2013-04-18  0:19 ` Sergio Durigan Junior
2013-04-18  0:51   ` Luis Machado
2013-04-22 21:09 ` Luis Machado
2013-04-22 21:09   ` Pedro Alves
2013-04-23  0:05     ` Pedro Alves
2013-04-23  1:15       ` Pedro Alves
2013-04-23 20:25         ` Luis Machado
2013-04-23 23:18         ` Luis Machado
2013-04-24  3:19           ` Pedro Alves
2013-04-24  6:28             ` Luis Machado
2013-04-24 19:04               ` Pedro Alves
2013-04-25 14:13                 ` Luis Machado
2013-05-07  7:44                   ` Luis Machado
2013-04-24  4:36           ` Pedro Alves

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=20120806170405.GA9225@host2.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=gdb-patches@sourceware.org \
    --cc=luis_gustavo@mentor.com \
    --cc=prasad@linux.vnet.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