Re: [PATCH 4/4] kgdb: x86: Detach gdb if machine shuts down or reboots

[Jan Kiszka]

On 2012-03-16 16:36, Jason Wessel wrote:
> On 03/16/2012 07:17 AM, Jan Kiszka wrote:
>> Hook into machine restart/power-off/halt handlers and call gdbstub_exit
>> so that a attached gdb frontend is properly informed. If kgdb is
>> disabled or no frontend attached, gdbstub_exit will do nothing.
>>
> 
> 
> We have long had an out of tree patch which hooked the reboot notifier, vs adding call backs to the actual reboot functions.  It seems at first glance that all of cases that Jan probably cares about are actually caught by the reboot notifier.
> 
> I attached the patch I am referencing, and perhaps Jan can try it out.   It applies on top of Jan's series at the moment.
> 
> A few more comments first.
> 
>>  static void __machine_emergency_restart(int emergency)
>>  {
>>  	reboot_emergency = emergency;
>> +	gdbstub_exit(1);
> 
> 
> If we do have to add callbacks at the arch level, my preference is to pass the stop code like you would have received in the reboot notifier.  Specifically something like:  gdbstub_exit(SYS_RESTART).

Yes, that sounds reasonable.

> 
>>  	machine_ops.emergency_restart();
>>  }
>>  
>> @@ -730,6 +732,7 @@ struct machine_ops machine_ops = {
>>  
>>  void machine_power_off(void)
>>  {
>> +	gdbstub_exit(0);
> 
> 
> Similarly gdbstub_exit(SYS_HALT) and so on.
> 
> Jan, what do you think about trying the reboot notifier version?

An arch-independent hook has its advantages, no question. Maybe we
should just start this way and then evolved on top as needed.

I was wondering why those other archs do not use the notifier. Maybe one
motivation is to avoid that too much code is excluded from the debugger
by detaching too early. Could possibly be addressed by making
detach-on-reboot runtime configurable.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/