lkml.org 
[lkml]   [2009]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch 01/12] Prepare the code for Hardware Breakpoint interfaces
On Wed, May 27, 2009 at 03:01:15AM +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2009 at 07:30:33PM +0530, K.Prasad wrote:
> > This patch introduces header files containing constants, structure definitions
> > and declaration of functions used by the hardware breakpoint interface code.
> >
> > Original-patch-by: Alan Stern <stern@rowland.harvard.edu>
> > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> > Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
> > ---
> > Index: linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > ===================================================================
> > --- linux-2.6-tip.hbkpt.orig/arch/x86/include/asm/processor.h
> > +++ linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > @@ -29,6 +29,7 @@ struct mm_struct;
> > #include <linux/threads.h>
> > #include <linux/init.h>
> >
> > +#define HBP_NUM 4
> > /*
> > * Default implementation of macro that returns current
> > * instruction pointer ("program counter").
> > @@ -433,12 +434,11 @@ struct thread_struct {
> > #endif
> > unsigned long gs;
> > /* Hardware debugging registers: */
> > - unsigned long debugreg0;
> > - unsigned long debugreg1;
> > - unsigned long debugreg2;
> > - unsigned long debugreg3;
> > + unsigned long debugreg[HBP_NUM];
>
>
>
> Note that each patches must leave a buildable kernel, even
> if these patches are contained in a set logic.
>
> I haven't tried yet, but I suspect this patch, if applied
> without the rest, will cause a build error.
>
> There are still some sites that use the removed fields above.
>
> A solution would be to temporarily fix these sites in this patch
> by using the new debugreg array interface. Even if you remove
> some of them in further patches in this series, for example
> by using the new load_debug_registers() helper, it will follow
> the logic step by step and leave a buildable kernel at each
> middle step.
>
> That implies to modify also some of the other patches of this
> series, but all of these changes should be trivial.
>
> Thanks,
>
> Frederic.
>

The debugreg<n> removal patches were correct, even as recent as
http://lkml.org/lkml/2009/5/11/160 and I guess I messed-up meanwhile.
Thanks for pointing it out - I've now moved them to Patch 8/12 along
with the ptrace changes.

The rest of the patches allow the kernel tree to be compiled though.
Would you prefer a new iteration with these changes, or can I send
individual patches with the changes discussed above?

Thanks,
K.Prasad



\
 
 \ /
  Last update: 2009-05-27 10:53    [W:0.081 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site