interesting line in process.c

I'm intrigued by this line, line 276 in arch/ppc/kernel/process.c in
linuxppc_2_4_devel:

#if defined(CONFIG_4xx) && defined(DCRN_PLB0_BEAR) && defined(DCRN_PLB0_BEAR)

When could we have DCRN_PLB0_BEAR defined but DCRN_PLB0_BEAR not? :)
Could it ever be defined if CONFIG_4xx was not defined?

Which brings up another question that I have been meaning to ask: what
is the rationale for adding the dbcr0/1 fields to the ptrace struct
for 4xx?

Since struct ptrace is part of the kernel/user ABI, I prefer not to
change it unless it is absolutely necessary.  Could the dbcr0/1 fields
go in the thread_struct instead?  Where and how are they used?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sat, Oct 13, 2001 at 09:56:32PM +1000, Paul Mackerras wrote:

I'm intrigued by this line, line 276 in arch/ppc/kernel/process.c in
linuxppc_2_4_devel:

#if defined(CONFIG_4xx) && defined(DCRN_PLB0_BEAR) && defined(DCRN_PLB0_BEAR)

When could we have DCRN_PLB0_BEAR defined but DCRN_PLB0_BEAR not? :)
Could it ever be defined if CONFIG_4xx was not defined?

Which brings up another question that I have been meaning to ask: what
is the rationale for adding the dbcr0/1 fields to the ptrace struct
for 4xx?

Since struct ptrace is part of the kernel/user ABI, I prefer not to
change it unless it is absolutely necessary.  Could the dbcr0/1 fields
go in the thread_struct instead?  Where and how are they used?

Well, I don't know anything about the 4xx, so this might not be
reasonable - but could they be used in setting hardware breakpoints?

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Paul Mackerras wrote:

I'm intrigued by this line, line 276 in arch/ppc/kernel/process.c in
linuxppc_2_4_devel:

I try to move this to other fault handlers where there is some 4xx
specific stuff already defined, but it keeps moving around and finding
its way back here.

Which brings up another question that I have been meaning to ask: what
is the rationale for adding the dbcr0/1 fields to the ptrace struct
for 4xx?

I dunno.  They have also been moving around during the 4xx port.
I just put them where the folks that send the patches have them.
I'll take a look at this since gdb is currently broken on 4xx.
They have to be context switched, and maybe someone though gdb should
have access to them.....


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

From Dan Malek:

Paul Mackerras wrote:

quoted

Which brings up another question that I have been meaning to ask: what
is the rationale for adding the dbcr0/1 fields to the ptrace struct
for 4xx?

I dunno.  They have also been moving around during the 4xx port.
I just put them where the folks that send the patches have them.
I'll take a look at this since gdb is currently broken on 4xx.
They have to be context switched, and maybe someone though gdb should
have access to them.....

I bumped into this when I was looking at adding 74xx IABR/DABR support
for hardware breakpoints under gdb.
(see http://lists.linuxppc.org/linuxppc-dev/200108/msg00249.html)

But to really support the 405 (or booke) all 11 (or 12 for booke)
debug breakpoint registers should to be accessible to gdb.

i386 defines debugreg[8] in the thread_struct and gives ptrace access
to it with special restrictions.

I would suggest ppc do the same thing and define a single debug array
in thread_struct which contains the processor specific debug registers
needed to support gdb's use of hardware breakpoints.  New ptrace
numbers (offsets) will need to be defined to access this array.

Ed.Swarthout@motorola.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Edward Swarthout wrote:

I would suggest ppc do the same thing and define a single debug array
in thread_struct which contains the processor specific debug registers
needed to support gdb's use of hardware breakpoints.

So, gdb has knowledge of hardware breakpoints and knows how to use
them across the different processors?  I would ask we consider using
a standard breakpoint interface to the kernel and allow the kernel
to implement the breakpoints as it desires.  It seems having this
knowledge and synchronizing the necessary information across the
interface could be challenging.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Mon, Oct 15, 2001 at 11:54:15AM -0400, Dan Malek wrote:

Edward Swarthout wrote:

quoted

I would suggest ppc do the same thing and define a single debug array
in thread_struct which contains the processor specific debug registers
needed to support gdb's use of hardware breakpoints.

So, gdb has knowledge of hardware breakpoints and knows how to use
them across the different processors?  I would ask we consider using
a standard breakpoint interface to the kernel and allow the kernel
to implement the breakpoints as it desires.  It seems having this
knowledge and synchronizing the necessary information across the
interface could be challenging.

Yes, I'd much prefer that the kernel handle it, from a purely GDB point
of view, but this does also introduce significant complexity; witness
Dave Miller's decision not to handle single-step in kernel on either
Sparc or MIPS.  The kernel would need to track the registers somewhere
process-specific, not allow them to be set via ptrace, etc.

As far as I know no platform currently has ptrace constants for setting
hardware breakpoints/watchpoints; instead, some export the registers
via ptrace.  It should be much cleaner to do it via an abstract
interface.

I'm willing to do the GDB support code for this if someone else
volunteers to do the kernel parts :)

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Daniel Jacobowitz wrote:

I'm willing to do the GDB support code for this if someone else
volunteers to do the kernel parts :)

I'll take you up on your offer very soon :-).

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/