Messages in this thread | | | From | "Amit S. Kale" <> | Subject | Re: [Kgdb-bugreport] Document hooks in kgdb | Date | Thu, 25 Mar 2004 10:22:39 +0530 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |