public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Jason Wessel <jason.wessel@windriver.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/6] x86: Allow the user not to build hw_breakpoints
Date: Wed, 4 May 2011 01:54:36 +0200	[thread overview]
Message-ID: <20110503235434.GI2678@nowhere> (raw)
In-Reply-To: <4DC0925E.20507@zytor.com>

On Tue, May 03, 2011 at 04:40:14PM -0700, H. Peter Anvin wrote:
> On 05/03/2011 04:12 PM, Frederic Weisbecker wrote:
> >>
> >> It really is very bad... without breakpoints, you lose almost all
> >> debugging support.
> > 
> > Right, so it should be fine for embedded environment to disable breakpoints.
> > It depends on CONFIG_EXPERT now.
> 
> Uh... even embedded environments need to be able to debug.

For development yeah, but is it needed for production evironments?

May be sometimes. But even though, the main functionalities of
ptrace are still available since instruction breakpoints are
implemented through int3 and not debugreg in ptrace. Only data
breakpoints would be unusable, but I believe they are a minor use compared
to instruction breakpoints. I rarely make use of them for debugging
personally.

That's really deemed for specific cases where people know what
they are doing.

  reply	other threads:[~2011-05-03 23:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27 16:59 [PATCH 0/6] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-04-27 16:59 ` [PATCH 1/6] hw_breakpoints: Split hardware breakpoints config Frederic Weisbecker
2011-04-27 16:59 ` [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config Frederic Weisbecker
2011-04-27 16:59 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-04-27 17:38   ` H. Peter Anvin
2011-04-27 18:26     ` Frederic Weisbecker
2011-04-27 19:10       ` Michael Bohan
     [not found]       ` <008d59a3-bd23-4cb3-8a73-1640137e3ac4@email.android.com>
2011-04-27 19:50         ` Frederic Weisbecker
2011-05-03 15:35           ` H. Peter Anvin
2011-05-03 23:12             ` Frederic Weisbecker
2011-05-03 23:40               ` H. Peter Anvin
2011-05-03 23:54                 ` Frederic Weisbecker [this message]
2011-05-03 23:56                   ` H. Peter Anvin
2011-05-04  0:13                     ` Frederic Weisbecker
2011-04-27 17:00 ` [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events Frederic Weisbecker
2011-04-27 17:00 ` [PATCH 5/6] hw_breakpoints: Only force perf events if breakpoints are selected Frederic Weisbecker
2011-04-27 17:00 ` [PATCH 6/6] hw_breakpoints: Drop remaining misplaced dependency on perf Frederic Weisbecker
2011-04-27 17:02 ` [PATCH 0/6] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-05-03 11:40 ` Will Deacon
  -- strict thread matches above, loose matches on Subject: below --
2011-05-24 21:52 [PATCH v2] " Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-07-14 15:03 [GIT PULL] hw_breakpoints updates Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-07-14 21:26   ` H. Peter Anvin
2011-07-14 21:51     ` Frederic Weisbecker
2011-07-21  7:26     ` Ingo Molnar
2011-07-21 12:36       ` Peter Zijlstra
2011-07-21 13:03       ` Frederic Weisbecker

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=20110503235434.GI2678@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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