pt_regs.dbcr0/1

pt_regs.dbcr0/1

[Paul Mackerras]

Is anyone prepared to speak up for the dbcr0 and dbcr1 fields that
someone added to struct pt_regs for 4xx in the 2_4_devel tree?

If not, they are going.  If so, we can discuss it.

Better still, does anyone have a clearly thought-out vision of how the
debug facilities on 4xx should be managed?

I would much prefer to see these fields put in the thread_struct
rather than pt_regs.  I am reluctant to change pt_regs without a good
reason since it is visible to userspace and is therefore part of the
kernel API.  If the intention is to make the debug facilities
available to userspace then the thread_struct is a good place to put
fields relating to the debug facilities.

Paul.


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

Re: pt_regs.dbcr0/1

[Armin]

Paul Mackerras wrote:
> Is anyone prepared to speak up for the dbcr0 and dbcr1 fields that
> someone added to struct pt_regs for 4xx in the 2_4_devel tree?
>
> If not, they are going.  If so, we can discuss it.
>
> Better still, does anyone have a clearly thought-out vision of how the
> debug facilities on 4xx should be managed?
>
> I would much prefer to see these fields put in the thread_struct
> rather than pt_regs.  I am reluctant to change pt_regs without a good
> reason since it is visible to userspace and is therefore part of the
> kernel API.  If the intention is to make the debug facilities
> available to userspace then the thread_struct is a good place to put
> fields relating to the debug facilities.
>
> Paul.
>
>
>
>
>

Oh man its been a while... hmmm IIRC I thought we used pt_regs for kgdb.
  IIRC we already use the thread_struct for gdb.  There are two people
who did the bulk of the debugger work, if they don't pipe up , I will do
my best.

I'll get back to you.

armin


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

Re: pt_regs.dbcr0/1

[Dan Malek]

Paul Mackerras wrote:

> Is anyone prepared to speak up for the dbcr0 and dbcr1 fields that
> someone added to struct pt_regs for 4xx in the 2_4_devel tree?

I believe they were moved because those registers are copied between
the application context and the debugger.  I was part of making this
work, but not for moving the registers :-)  IIRC, the reason was we
wanted gdb to be '4xx-aware' so it could use more of the debug capabilities.
There is also a problem of context switching these registers when you
are trying to debug the kernel or applications.

> If not, they are going.  If so, we can discuss it.

You just can't toss them, they have to be context switched, but I think
the thread struct is the proper place.  There are always problems with
trying to run any combination of background debuggers, kgdb, or application
gdb at the same time, which raises the discussion as to where these
registers should be context switched.  I think we just resign ourselves
to only one debug interface active at a time and simplify the kernel.


> Better still, does anyone have a clearly thought-out vision of how the
> debug facilities on 4xx should be managed?

With better hardware support? :-)  The debug registers just have to be
context switched between the different threads (and the kernel if you
want to debug that as well).  A separate discussion is how much we want
gdb to be specifically aware of the 4xx, which will change the kernel
ptrace() interface and functions.

Thanks.


	-- Dan


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

Re: pt_regs.dbcr0/1

[Paul Mackerras]

Dan Malek writes:

> I believe they were moved because those registers are copied between
> the application context and the debugger.  I was part of making this
> work, but not for moving the registers :-)  IIRC, the reason was we
> wanted gdb to be '4xx-aware' so it could use more of the debug capabilities.

So has anyone done a 4xx-aware gdb yet?

> > If not, they are going.  If so, we can discuss it.
>
> You just can't toss them, they have to be context switched, but I think
> the thread struct is the proper place.  There are always problems with

I wasn't suggesting to get rid of them completely, I was saying that
they should not be in pt_regs.  I think we are in violent agreement. :)

> trying to run any combination of background debuggers, kgdb, or application
> gdb at the same time, which raises the discussion as to where these
> registers should be context switched.  I think we just resign ourselves
> to only one debug interface active at a time and simplify the kernel.

I think so too.  I think it will be basically impossible to do gdb +
external debugging or xmon/kgdb + external debugging.  gdb + xmon/kgdb
may be possible but we will have to see how complex it looks once we
know what the kernel support for gdb looks like.

Paul.

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

Re: pt_regs.dbcr0/1

[Dan Malek]

Paul Mackerras wrote:

> So has anyone done a 4xx-aware gdb yet?

Not to my knowledge.  Daniel Jacobowitz (drow) has discussed it a little,
but I have not heard much about it lately.

> ....  I think we are in violent agreement. :)

Not again......It must be that Aussie English :-)


> ..... gdb + xmon/kgdb
> may be possible but we will have to see how complex it looks once we
> know what the kernel support for gdb looks like.

I believe we have tied the BDI context switch configuration option to
allowing external debugging by ensuring the kernel doesn't mess around
with the debug registers.  We have at least discussed doing it.  As
long as we properly context switch the debug registers, all of the software
modes should coexist happily.

Thanks.


	-- Dan


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

Re: pt_regs.dbcr0/1

[Kumar Gala]

I am not seeing where the other debug registers that are associated with
the debug state are being state changed and managed.  For example
IAC{1-4} [breakpnt], DACs [watchpnts], DVCs are being handled.

The 4xx debug hardware looks to be similar to what is spec'd in Book-E.
If this solution is not solved at this time it will come up in the
future with new Book-E parts coming down the pipes.

- kumar

On Tuesday, June 4, 2002, at 12:22 PM, Dan Malek wrote:

>
> Paul Mackerras wrote:
>
>> So has anyone done a 4xx-aware gdb yet?
>
> Not to my knowledge.  Daniel Jacobowitz (drow) has discussed it a
> little,
> but I have not heard much about it lately.
>
>> ....  I think we are in violent agreement. :)
>
> Not again......It must be that Aussie English :-)
>
>
>> ..... gdb + xmon/kgdb
>> may be possible but we will have to see how complex it looks once we
>> know what the kernel support for gdb looks like.
>
> I believe we have tied the BDI context switch configuration option to
> allowing external debugging by ensuring the kernel doesn't mess around
> with the debug registers.  We have at least discussed doing it.  As
> long as we properly context switch the debug registers, all of the
> software
> modes should coexist happily.
>
> Thanks.
>
>
> 	-- Dan
>
>


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

Re: pt_regs.dbcr0/1

[Frank Rowand]

Replying to a string of several messages:


Paul Mackerras wrote:
>
> Is anyone prepared to speak up for the dbcr0 and dbcr1 fields that
> someone added to struct pt_regs for 4xx in the 2_4_devel tree?
>
> If not, they are going.  If so, we can discuss it.
>
> Better still, does anyone have a clearly thought-out vision of how the
> debug facilities on 4xx should be managed?

That's a very important sentence...  If you are going to modify any of
the 4xx debug infrastructure, please be sure that you understand how
gdb (via ptrace.c), kgdb (via ppc_stub.c), and jtag debuggers use the
infrastructure and how they can interact.  Other interesting files
that get involved are head_4xx.S (saving state, handling the debug
exception), entry.S (restoring state), traps.c (single step handling),
ppc4xx_setup.c (debug register initialization), and I'm probably forgetting
some other file.  (Of course you also have to add in the 440 specific
files, which I'm not familiar with.)


> I would much prefer to see these fields put in the thread_struct
> rather than pt_regs.  I am reluctant to change pt_regs without a good
> reason since it is visible to userspace and is therefore part of the
> kernel API.  If the intention is to make the debug facilities
> available to userspace then the thread_struct is a good place to put
> fields relating to the debug facilities.

I had an early version of the kernel that used the thread_struct instead
of the pt_regs, but it was more complex than the current code, and gdb
and kgdb did not play well together.

Using pt_regs made it relatively easy for gdb and kgdb to coexist.


Dan Malek wrote:
>
> Paul Mackerras wrote:
>
> > Is anyone prepared to speak up for the dbcr0 and dbcr1 fields that
> > someone added to struct pt_regs for 4xx in the 2_4_devel tree?
>
> I believe they were moved because those registers are copied between
> the application context and the debugger.  I was part of making this
> work, but not for moving the registers :-)  IIRC, the reason was we
> wanted gdb to be '4xx-aware' so it could use more of the debug capabilities.
> There is also a problem of context switching these registers when you
> are trying to debug the kernel or applications.
>
> > If not, they are going.  If so, we can discuss it.
>
> You just can't toss them, they have to be context switched, but I think
> the thread struct is the proper place.  There are always problems with
> trying to run any combination of background debuggers, kgdb, or application
> gdb at the same time, which raises the discussion as to where these
> registers should be context switched.  I think we just resign ourselves
> to only one debug interface active at a time and simplify the kernel.

The last time that I fixed the 4xx debug infrastructure, I had gdb and kgdb
coexisting.  Adding RISCWatch (jtag based) to the mix made things a little
bit more fragile.  But for someone who was intimitely familiar with the
debug infrastructure (me), RISCWatch was somewhat useful in a tightly
constrained usage model coexistant with gdb/kgdb (I was debugging the
debugging infrastructure) before occassionally blowing everything up.
Using a jtag debugger simultaneously with gdb/kgdb is not an exercise
for the meek.

By gdb and kgdb coexisting, I mean having both debuggers actively
debugging a problem at the same time, without interfering with
each other.


>
> > Better still, does anyone have a clearly thought-out vision of how the
> > debug facilities on 4xx should be managed?
>
> With better hardware support? :-)  The debug registers just have to be
> context switched between the different threads (and the kernel if you
> want to debug that as well).  A separate discussion is how much we want
> gdb to be specifically aware of the 4xx, which will change the kernel
> ptrace() interface and functions.

I don't think you would have to change the ptrace() interface.  The major
features that the 4xx debug architecture provides that aren't currently
being used are hardware breakpoints, and hardware watchpoints (detecting
access of an address range).  I think that this can be handled with the
current API (but I defer to any gdb expert who wants to jump in...).



Paul Mackerras wrote:
>
> Dan Malek writes:

< stuff deleted >

> I think so too.  I think it will be basically impossible to do gdb +
> external debugging or xmon/kgdb + external debugging.

Note for the curious - the key problem areas are restoring process state (see
CONFIG_BDI_SWITCH in entry.S) and entering the kernel via exceptions
(head_4xx.S).



Dan Malek wrote:
>

< stuff deleted >

> I believe we have tied the BDI context switch configuration option to
> allowing external debugging by ensuring the kernel doesn't mess around
> with the debug registers.  We have at least discussed doing it.  As

Yes, someone did it.  See CONFIG_BDI_SWITCH in entry.S.



One final note:  I did not implement xmon support when I did the 405gp (walnut)
bringup.  I got kgdb working fairly quickly and didn't need a second debugger
at the time.  I don't know if anyone has since added 4xx xmon support.  If not,
that might be a good project for someone.


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: pt_regs.dbcr0/1

[Frank Rowand]

Kumar Gala wrote:
>
> I am not seeing where the other debug registers that are associated with
> the debug state are being state changed and managed.  For example
> IAC{1-4} [breakpnt], DACs [watchpnts], DVCs are being handled.

The current kernel does not take advantage (use) the hardware breakpoint
and watchpoint registers.  Current jtag based debuggers are capable of
using these registers.  It would be extremely useful to add support
of these resources.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: pt_regs.dbcr0/1

[Paul Mackerras]

Frank Rowand writes:

> That's a very important sentence...  If you are going to modify any of
> the 4xx debug infrastructure, please be sure that you understand how
> gdb (via ptrace.c), kgdb (via ppc_stub.c), and jtag debuggers use the
> infrastructure and how they can interact.  Other interesting files

It would be really nice if you would document this somewhere...

Paul.

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

Re: pt_regs.dbcr0/1

[Dan Malek]

Kumar Gala wrote:

> I am not seeing where the other debug registers that are associated with
> the debug state are being state changed and managed....


They aren't, and are the reason for the gdb 4xx-aware discussion.  Today,
all of those features are handled in the generic manner with code modification.
The only thing the debug registers are used to support are single step.
If the book-E MSR would have kept the single step, we wouldn't need any
of the debug context switching to be compliant with other PPCs.

Many of the processors have some form of (incompatible :-) hardware debug
capability.  I know the external debuggers use these registers, but we
don't use these with standard software tools.  I guess if we knew gdb
was setting a breakpoint (instead of just the modification of memory), we
could have the kernel set these registers.  The alternative is to make
gdb aware of all of these different hardware debug capabilities and have
some interface to support it.

This isn't a 4xx or even book-E specific discussion.  The MPC8xx, and I
believe the 7xx and 74xx all have some form of hardware debug support
accessible from software.

Thanks.


	-- Dan


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