Hi. The following is my first attempt at documenting the hooks found in
the KGDB found on kgdb.sf.net. I'm not quite sure about the description
of some of the optional hooks (used under hw breakpoints) so corrections
/ suggestions welcome. After I got done with it, it hit me that maybe I
should have done this in the code, and in DocBook format, so I'll go and
do that next...
<-- snip -->
This is an attempt to document the various architecture specific functions
that are part of KGDB. There are a number of optional functions, depending
on hardware setps, for which empty defaults are provided. There are also
functions which must be implemented and for which no default is provided.
The required functions are:
int kgdb_arch_handle_exception(int vector, int signo, int err_code,
char *InBuffer, char *outBuffer, struct pt_regs *regs)
This function MUST handle the 'c' and 's' command packets,
as well packets to set / remove a hardware breakpoint, if used.
void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the ptrace regs in regs into what GDB expects to
see for registers, in gdb_regs.
void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
Like regs_to_gdb_regs, except that the process in p is sleeping,
so we cannot get as much information.
void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Convert the GDB regs in gdb_regs into the ptrace regs pointed
to in regs.
The optional functions are:
int kgdb_arch_init(void) :
This function will handle the initalization of any architecture
specific hooks. If there is a suitable early output driver,
kgdb_serial can be pointed at it now.
void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
Write into buffer and information about the exception that has
occured that can be gleaned from exceptionNo and errorcode.
void kgdb_disable_hw_debug(struct pt_regs *regs)
Disable hardware debugging while we are in kgdb.
void kgdb_correct_hw_break(void)
A hook to allow for changes to the hardware breakpoint, called
after a single step (s) or continue (c) packet, and once we're about
to let the kernel continue running.
void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
Store the raw vector and error, for later retreival.
void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int threadid)
struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int threadid)
If we have a shadow thread (determined by setting
kgdb_ops->shadowth = 1), these functions are required to return
information about this thread.
--
Tom Rini
http://gate.crashing.org/~trini/
That's a good idea. Go ahead.
-Amit
On Friday 19 Mar 2004 9:50 pm, Tom Rini wrote:
> Hi. The following is my first attempt at documenting the hooks found in
> the KGDB found on kgdb.sf.net. I'm not quite sure about the description
> of some of the optional hooks (used under hw breakpoints) so corrections
> / suggestions welcome. After I got done with it, it hit me that maybe I
> should have done this in the code, and in DocBook format, so I'll go and
> do that next...
>
> <-- snip -->
> This is an attempt to document the various architecture specific functions
> that are part of KGDB. There are a number of optional functions, depending
> on hardware setps, for which empty defaults are provided. There are also
> functions which must be implemented and for which no default is provided.
>
> The required functions are:
> int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> char *InBuffer, char *outBuffer, struct pt_regs *regs)
> This function MUST handle the 'c' and 's' command packets,
> as well packets to set / remove a hardware breakpoint, if used.
>
> void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> Convert the ptrace regs in regs into what GDB expects to
> see for registers, in gdb_regs.
>
> void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct
> task_struct *p) Like regs_to_gdb_regs, except that the process in p is
> sleeping,
> so we cannot get as much information.
>
> void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> Convert the GDB regs in gdb_regs into the ptrace regs pointed
> to in regs.
>
> The optional functions are:
> int kgdb_arch_init(void) :
> This function will handle the initalization of any architecture
> specific hooks. If there is a suitable early output driver,
> kgdb_serial can be pointed at it now.
>
> void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
> Write into buffer and information about the exception that has
> occured that can be gleaned from exceptionNo and errorcode.
>
> void kgdb_disable_hw_debug(struct pt_regs *regs)
> Disable hardware debugging while we are in kgdb.
>
> void kgdb_correct_hw_break(void)
> A hook to allow for changes to the hardware breakpoint, called
> after a single step (s) or continue (c) packet, and once we're about
> to let the kernel continue running.
>
> void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
> Store the raw vector and error, for later retreival.
>
> void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
> struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int
> threadid) struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int
> threadid) If we have a shadow thread (determined by setting
> kgdb_ops->shadowth = 1), these functions are required to return
> information about this thread.
An addition: shadow threads are needed to provide information not retrievable
by gdb. e.g. Backtraces beyond interrupt entrypoints, that aren't retrievable
in absence of debugging info for interrupt entrypoint code.
Rest is fine.
-Amit
On Wed, Mar 24, 2004 at 08:11:26PM +0530, Amit S. Kale wrote:
> That's a good idea. Go ahead.
> -Amit
> On Friday 19 Mar 2004 9:50 pm, Tom Rini wrote:
> > Hi. The following is my first attempt at documenting the hooks found in
> > the KGDB found on kgdb.sf.net. I'm not quite sure about the description
> > of some of the optional hooks (used under hw breakpoints) so corrections
> > / suggestions welcome. After I got done with it, it hit me that maybe I
> > should have done this in the code, and in DocBook format, so I'll go and
> > do that next...
> >
> > <-- snip -->
> > This is an attempt to document the various architecture specific functions
> > that are part of KGDB. There are a number of optional functions, depending
> > on hardware setps, for which empty defaults are provided. There are also
> > functions which must be implemented and for which no default is provided.
> >
> > The required functions are:
> > int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> > char *InBuffer, char *outBuffer, struct pt_regs *regs)
> > This function MUST handle the 'c' and 's' command packets,
> > as well packets to set / remove a hardware breakpoint, if used.
> >
> > void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > Convert the ptrace regs in regs into what GDB expects to
> > see for registers, in gdb_regs.
> >
> > void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct
> > task_struct *p) Like regs_to_gdb_regs, except that the process in p is
> > sleeping,
> > so we cannot get as much information.
> >
> > void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > Convert the GDB regs in gdb_regs into the ptrace regs pointed
> > to in regs.
> >
> > The optional functions are:
> > int kgdb_arch_init(void) :
> > This function will handle the initalization of any architecture
> > specific hooks. If there is a suitable early output driver,
> > kgdb_serial can be pointed at it now.
> >
> > void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
> > Write into buffer and information about the exception that has
> > occured that can be gleaned from exceptionNo and errorcode.
> >
> > void kgdb_disable_hw_debug(struct pt_regs *regs)
> > Disable hardware debugging while we are in kgdb.
> >
> > void kgdb_correct_hw_break(void)
> > A hook to allow for changes to the hardware breakpoint, called
> > after a single step (s) or continue (c) packet, and once we're about
> > to let the kernel continue running.
> >
> > void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
> > Store the raw vector and error, for later retreival.
> >
> > void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
> > struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int
> > threadid) struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int
> > threadid) If we have a shadow thread (determined by setting
> > kgdb_ops->shadowth = 1), these functions are required to return
> > information about this thread.
>
> An addition: shadow threads are needed to provide information not retrievable
> by gdb. e.g. Backtraces beyond interrupt entrypoints, that aren't retrievable
> in absence of debugging info for interrupt entrypoint code.
If I follow everything right, this could go in favor of cfi macros,
right ?
--
Tom Rini
http://gate.crashing.org/~trini/
On Wednesday 24 Mar 2004 9:13 pm, Tom Rini wrote:
> On Wed, Mar 24, 2004 at 08:11:26PM +0530, Amit S. Kale wrote:
> > That's a good idea. Go ahead.
> > -Amit
> >
> > On Friday 19 Mar 2004 9:50 pm, Tom Rini wrote:
> > > Hi. The following is my first attempt at documenting the hooks found
> > > in the KGDB found on kgdb.sf.net. I'm not quite sure about the
> > > description of some of the optional hooks (used under hw breakpoints)
> > > so corrections / suggestions welcome. After I got done with it, it hit
> > > me that maybe I should have done this in the code, and in DocBook
> > > format, so I'll go and do that next...
> > >
> > > <-- snip -->
> > > This is an attempt to document the various architecture specific
> > > functions that are part of KGDB. There are a number of optional
> > > functions, depending on hardware setps, for which empty defaults are
> > > provided. There are also functions which must be implemented and for
> > > which no default is provided.
> > >
> > > The required functions are:
> > > int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> > > char *InBuffer, char *outBuffer, struct pt_regs *regs)
> > > This function MUST handle the 'c' and 's' command packets,
> > > as well packets to set / remove a hardware breakpoint, if used.
> > >
> > > void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > > Convert the ptrace regs in regs into what GDB expects to
> > > see for registers, in gdb_regs.
> > >
> > > void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct
> > > task_struct *p) Like regs_to_gdb_regs, except that the process in p is
> > > sleeping,
> > > so we cannot get as much information.
> > >
> > > void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > > Convert the GDB regs in gdb_regs into the ptrace regs pointed
> > > to in regs.
> > >
> > > The optional functions are:
> > > int kgdb_arch_init(void) :
> > > This function will handle the initalization of any architecture
> > > specific hooks. If there is a suitable early output driver,
> > > kgdb_serial can be pointed at it now.
> > >
> > > void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char
> > > *buffer) Write into buffer and information about the exception that has
> > > occured that can be gleaned from exceptionNo and errorcode.
> > >
> > > void kgdb_disable_hw_debug(struct pt_regs *regs)
> > > Disable hardware debugging while we are in kgdb.
> > >
> > > void kgdb_correct_hw_break(void)
> > > A hook to allow for changes to the hardware breakpoint, called
> > > after a single step (s) or continue (c) packet, and once we're about
> > > to let the kernel continue running.
> > >
> > > void kgdb_post_master_code(struct pt_regs *regs, int eVector, int
> > > err_code) Store the raw vector and error, for later retreival.
> > >
> > > void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned
> > > threadid) struct task_struct *kgdb_get_shadow_thread(struct pt_regs
> > > *regs, int threadid) struct pt_regs *kgdb_shadow_regs(struct pt_regs
> > > *regs, int threadid) If we have a shadow thread (determined by setting
> > > kgdb_ops->shadowth = 1), these functions are required to return
> > > information about this thread.
> >
> > An addition: shadow threads are needed to provide information not
> > retrievable by gdb. e.g. Backtraces beyond interrupt entrypoints, that
> > aren't retrievable in absence of debugging info for interrupt entrypoint
> > code.
>
> If I follow everything right, this could go in favor of cfi macros,
> right ?
Yes. Shadow threads won't be required with CFI macros.
I believe they are not required with x86_64. I have to verify this.
How about keeping the shadow thread framework in place even after we get
x86_64, x86 and ppc CFI macros. That'll help when we have other architectures
coming in.
-Amit
On Thu, Mar 25, 2004 at 10:22:39AM +0530, Amit S. Kale wrote:
> On Wednesday 24 Mar 2004 9:13 pm, Tom Rini wrote:
> > On Wed, Mar 24, 2004 at 08:11:26PM +0530, Amit S. Kale wrote:
> > > That's a good idea. Go ahead.
> > > -Amit
> > >
> > > On Friday 19 Mar 2004 9:50 pm, Tom Rini wrote:
> > > > Hi. The following is my first attempt at documenting the hooks found
> > > > in the KGDB found on kgdb.sf.net. I'm not quite sure about the
> > > > description of some of the optional hooks (used under hw breakpoints)
> > > > so corrections / suggestions welcome. After I got done with it, it hit
> > > > me that maybe I should have done this in the code, and in DocBook
> > > > format, so I'll go and do that next...
> > > >
> > > > <-- snip -->
> > > > This is an attempt to document the various architecture specific
> > > > functions that are part of KGDB. There are a number of optional
> > > > functions, depending on hardware setps, for which empty defaults are
> > > > provided. There are also functions which must be implemented and for
> > > > which no default is provided.
> > > >
> > > > The required functions are:
> > > > int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> > > > char *InBuffer, char *outBuffer, struct pt_regs *regs)
> > > > This function MUST handle the 'c' and 's' command packets,
> > > > as well packets to set / remove a hardware breakpoint, if used.
> > > >
> > > > void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > > > Convert the ptrace regs in regs into what GDB expects to
> > > > see for registers, in gdb_regs.
> > > >
> > > > void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct
> > > > task_struct *p) Like regs_to_gdb_regs, except that the process in p is
> > > > sleeping,
> > > > so we cannot get as much information.
> > > >
> > > > void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
> > > > Convert the GDB regs in gdb_regs into the ptrace regs pointed
> > > > to in regs.
> > > >
> > > > The optional functions are:
> > > > int kgdb_arch_init(void) :
> > > > This function will handle the initalization of any architecture
> > > > specific hooks. If there is a suitable early output driver,
> > > > kgdb_serial can be pointed at it now.
> > > >
> > > > void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char
> > > > *buffer) Write into buffer and information about the exception that has
> > > > occured that can be gleaned from exceptionNo and errorcode.
> > > >
> > > > void kgdb_disable_hw_debug(struct pt_regs *regs)
> > > > Disable hardware debugging while we are in kgdb.
> > > >
> > > > void kgdb_correct_hw_break(void)
> > > > A hook to allow for changes to the hardware breakpoint, called
> > > > after a single step (s) or continue (c) packet, and once we're about
> > > > to let the kernel continue running.
> > > >
> > > > void kgdb_post_master_code(struct pt_regs *regs, int eVector, int
> > > > err_code) Store the raw vector and error, for later retreival.
> > > >
> > > > void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned
> > > > threadid) struct task_struct *kgdb_get_shadow_thread(struct pt_regs
> > > > *regs, int threadid) struct pt_regs *kgdb_shadow_regs(struct pt_regs
> > > > *regs, int threadid) If we have a shadow thread (determined by setting
> > > > kgdb_ops->shadowth = 1), these functions are required to return
> > > > information about this thread.
> > >
> > > An addition: shadow threads are needed to provide information not
> > > retrievable by gdb. e.g. Backtraces beyond interrupt entrypoints, that
> > > aren't retrievable in absence of debugging info for interrupt entrypoint
> > > code.
> >
> > If I follow everything right, this could go in favor of cfi macros,
> > right ?
>
> Yes. Shadow threads won't be required with CFI macros.
>
> I believe they are not required with x86_64. I have to verify this.
x86_64 is currently the only arch implementing this.
> How about keeping the shadow thread framework in place even after we get
> x86_64, x86 and ppc CFI macros. That'll help when we have other architectures
> coming in.
We should probably drop the shadow stuff altogether, and get the CFI
stuff done right, first on x86_64. Especially given how vocal the arch
maintainer has been on this issue.
--
Tom Rini
http://gate.crashing.org/~trini/
Hi!
Where can I get latest kgdb? The version on kgdb.sf.net is still
against 2.6.3, afaics. Or should I forward port it?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Mar 31, 2004 at 05:29:25PM +0200, Pavel Machek wrote:
> Hi!
>
> Where can I get latest kgdb? The version on kgdb.sf.net is still
> against 2.6.3, afaics. Or should I forward port it?
CVS is against 2.6.4. Once 2.6.5 comes out, I'll move it forward again.
Locally, I've got a series of patches vs 2.6.5-rc3 + some -mm bits for
Andrew which I hope to post today, but might not make it until tomorrow.
--
Tom Rini
http://gate.crashing.org/~trini/
Hi!
> > Where can I get latest kgdb? The version on kgdb.sf.net is still
> > against 2.6.3, afaics. Or should I forward port it?
>
> CVS is against 2.6.4. Once 2.6.5 comes out, I'll move it forward again.
> Locally, I've got a series of patches vs 2.6.5-rc3 + some -mm bits for
> Andrew which I hope to post today, but might not make it until tomorrow.
Okay, CVS *is* against 2.6.4, but it says it is against 2.6.3. Okay to
commit?
Pavel
Index: README
===================================================================
RCS file: /cvsroot/kgdb/kgdb-2/README,v
retrieving revision 1.5
diff -u -u -r1.5 README
--- README 2 Mar 2004 11:10:36 -0000 1.5
+++ README 31 Mar 2004 15:52:54 -0000
@@ -1,4 +1,4 @@
-Base Kernel version: 2.6.3
+Base Kernel version: 2.6.4
Patch:
------
@@ -39,8 +39,8 @@
Supply command line options kgdbwait and kgdb8250 to the kernel.
Example: kgdbwait kgdb8250=0,115200
(for ttyS0), then
- % stty 115200 < /dev/ttyS0
% gdb ./vmlinux
+ (gdb) set remotebaud 115200
(gdb) target remote /dev/ttyS0
Example for kgdb ethernet interface
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Mar 31, 2004 at 06:08:06PM +0200, Pavel Machek wrote:
> Hi!
>
> > > Where can I get latest kgdb? The version on kgdb.sf.net is still
> > > against 2.6.3, afaics. Or should I forward port it?
> >
> > CVS is against 2.6.4. Once 2.6.5 comes out, I'll move it forward again.
> > Locally, I've got a series of patches vs 2.6.5-rc3 + some -mm bits for
> > Andrew which I hope to post today, but might not make it until tomorrow.
>
> Okay, CVS *is* against 2.6.4, but it says it is against 2.6.3. Okay to
> commit?
> Pavel
> Index: README
> ===================================================================
> RCS file: /cvsroot/kgdb/kgdb-2/README,v
> retrieving revision 1.5
> diff -u -u -r1.5 README
> --- README 2 Mar 2004 11:10:36 -0000 1.5
> +++ README 31 Mar 2004 15:52:54 -0000
> @@ -1,4 +1,4 @@
> -Base Kernel version: 2.6.3
> +Base Kernel version: 2.6.4
>
> Patch:
> ------
> @@ -39,8 +39,8 @@
> Supply command line options kgdbwait and kgdb8250 to the kernel.
> Example: kgdbwait kgdb8250=0,115200
> (for ttyS0), then
> - % stty 115200 < /dev/ttyS0
> % gdb ./vmlinux
> + (gdb) set remotebaud 115200
> (gdb) target remote /dev/ttyS0
>
> Example for kgdb ethernet interface
Sure.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wednesday 31 Mar 2004 9:42 pm, Tom Rini wrote:
> On Wed, Mar 31, 2004 at 06:08:06PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > Where can I get latest kgdb? The version on kgdb.sf.net is still
> > > > against 2.6.3, afaics. Or should I forward port it?
> > >
> > > CVS is against 2.6.4. Once 2.6.5 comes out, I'll move it forward
> > > again. Locally, I've got a series of patches vs 2.6.5-rc3 + some -mm
> > > bits for Andrew which I hope to post today, but might not make it until
> > > tomorrow.
> >
> > Okay, CVS *is* against 2.6.4, but it says it is against 2.6.3. Okay to
> > commit?
> > Pavel
> > Index: README
> > ===================================================================
> > RCS file: /cvsroot/kgdb/kgdb-2/README,v
> > retrieving revision 1.5
> > diff -u -u -r1.5 README
> > --- README 2 Mar 2004 11:10:36 -0000 1.5
> > +++ README 31 Mar 2004 15:52:54 -0000
> > @@ -1,4 +1,4 @@
> > -Base Kernel version: 2.6.3
> > +Base Kernel version: 2.6.4
> >
> > Patch:
> > ------
> > @@ -39,8 +39,8 @@
> > Supply command line options kgdbwait and kgdb8250 to the kernel.
> > Example: kgdbwait kgdb8250=0,115200
> > (for ttyS0), then
> > - % stty 115200 < /dev/ttyS0
> > % gdb ./vmlinux
> > + (gdb) set remotebaud 115200
> > (gdb) target remote /dev/ttyS0
> >
> > Example for kgdb ethernet interface
>
> Sure.
Yes. We have to keep that in mind. This has happened second time.
Thanks, Pavel.
-Amit