Re: [RFC Patch 2/9] x86 architecture implementation of HardwareBreakpoint interfaces

[Alan Stern]

On Tue, 7 Oct 2008, K.Prasad wrote:

> This patch introduces two new files named hw_breakpoint.[ch] inside x86 specific
> directories. They contain functions which help validate and serve requests for 
> using Hardware Breakpoint registers on x86 processors.

> --- /dev/null
> +++ linux-bkpt-lkml-27-rc9/arch/x86/kernel/hw_breakpoint.c
> @@ -0,0 +1,684 @@

...
> +int pre_handler_allowed(unsigned type)
> +{
> +	if (type == HW_BREAKPOINT_EXECUTE)
> +		return 1;
> +	else
> +		return -EINVAL;
> +}

The routine's name should match the name in the header file.  "allowed" 
isn't right: You're _allowed_ to have pre_handlers -- they just won't 
get invoked.  "supported" would be better.

Also, the comment in the header file should explain the meaning of the
return value -- you should return 0 if a pre_handler is not supported, 
not -EINVAL.  Better yet, define the function (both here and in the 
header file) as returning bool rather than int.

> +
> +int post_handler_allowed(unsigned type)
> +{
> +	/* We can have a post handler for all types of breakpoints */
> +	return 1;
> +}

Same comments as above.

Also, in this initial version I would prefer to avoid the complications
of single-stepping.  It can always be added later.  So for now, the x86
implementation should not support post_handlers for execution
breakpoints.

...
> +/*
> + * Validate the arch-specific HW Breakpoint register settings
> + */
> +static int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
> +			unsigned long address, unsigned len, unsigned int type,
> +			unsigned int *align)

Why did you move this routine into the arch-specific code?

...
> +/*
> + * Handle debug exception notifications.
> + */
> +
> +static void switch_to_none_hw_breakpoint(void);
> +struct hw_breakpoint *last_hit_bp;
> +struct thread_hw_breakpoint *last_hit_thbi;

Shouldn't these variables be static?  Although if they're needed only for
single-stepping, they can be removed entirely for now...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/