Re: PPC KGDB changes and some help?

[George Anzinger <george _at_ xxxxxxxxxx>]

Tom Rini wrote:
>>>>>+
>>>>>/*
>>>>>* Routines
>>>>>*/
>>>>>static void
>>>>>kgdb_debugger(struct pt_regs *regs)
>>>>>{
>>>>>-	(*linux_debug_hook) (0, 0, 0, regs);
>>>>>+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>>	return;
>>>>>}
>>>>>
>>>>>@@ -52,14 +109,14 @@
>>>>>int
>>>>>kgdb_iabr_match(struct pt_regs *regs)
>>>>>{
>>>>>-	(*linux_debug_hook) (0, 0, 0, regs);
>>>>>+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>>	return 1;
>>>>>}
>>>>>
>>>>>int
>>>>>kgdb_dabr_match(struct pt_regs *regs)
>>>>>{
>>>>>-	(*linux_debug_hook) (0, 0, 0, regs);
>>>>>+	(*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>>	return 1;
>>>>>}
>>>>>
>>>>>
>>>>>Now, not being as well versed in all of the debugging infos that can be
>>>>>passed around, it sounds like this patch could be dropped in the future
>>>>>for a cleaner method using some of the dwarf2 bits being talked about.
>>>>>But I don't know, and clarification and pointers (if so) to how to do
>>>>>this would be appreciated.
>>>>
>>>>I am not sure what this buys you.  I don't think dwarf2 will help here.
>>>
>>>
>>>OK.
>>>
>>>
>>>
>>>>There is a real danger of passing signal info back to gdb as it will want 
>>>>to try to deliver the signal which is a non-compute in most kgdbs in the 
>>>>field.  I did put code in the mm-kgdb to do just this, but usually the 
>>>>arrival of such a signal (other than SIGTRAP) is the end of the kernel.  
>>>>All that is left is to read the tea leaves.
>>>
>>>
>>>The gdb I've been testing this with knows better than to try and send a
>>>singal back, so that's not a worry.  The motivation behind doing this
>>>however is along the lines of "if it ain't broke, don't remove it".  The
>>>original stub was getting all of this information correctly, so why stop
>>>doing it?
>>>
>>
>>OK, but I still don't like losing the return address.  Tell me again, why 
>>do you need three different functions all doing the same thing?
> 
> 
> You get:
> - kgdb_breakpoint => debugger_bpt : This is how the various PPC codes
>   drop you into KGDB.
> - kgdb_iabr_match => debugger_iabr_match : Called from
>   InstructionBreakpoint, exception.
> - kgdb_dabr_match => debugger_dabr_match : Called from do_page_fault,
>   this is a Data Access Breakpoint Register match.
> 
> So we need at least 2 for the KGDB side of things (prototypes) and 3
> just to make it clear.

But they all end up at the exact same place with the same set of parameters. 
The only difference I can see is that some return 1 while the other is void.  It 
seems to me that you could send them all to one of the ones that returns 1. 
Once that is done, then you could just send them all to where ever 
linux_debug_hook points and have it do the signal resolution and return the 1. 
That way that code could look at its return address and see something useful.
> 

-- 
George Anzinger   george _at_ mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

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