Debug Kernel - Revision history

Philippe Ferrucci: /* How to set it up */

2015-01-22T22:05:23Z

How to set it up

← Older revision		Revision as of 22:05, 22 January 2015
Line 44:		Line 44:

	; munge		; munge
	: Munges (fills) freed memory with a recognisable value so that memory ~~trashing~~ can be found more easily when using a debug ~~kernel~~.		: Munges (fills) freed memory with a recognisable value so that illegal memory accesses can be found more easily when using both the debug and non-debug kernels.
	: In other words, no valid data will persist past any deallocation function, so if someone reads from memory that has just been freed, they are likely to get a pointer address to an ~~area~~ that will cause ~~a DSI~~ exception when accessed, instead of its previous contents.		: In other words, no valid data will persist past any deallocation function, so if someone reads from memory that has just been freed, they are likely to get a pointer address to a region that will cause an exception when accessed, instead of its previous contents. The munging value written to freed memory is architecture dependant and allocation type dependant, here are some of the values you may encounter: 0xfefecafe, 0xabadcafe, 0xfefeabad, 0xabadabad, 0xfefebeef, 0xdeadbeef.
	: On the Sam440 and Sam460, the longword munge value is 0xfefecafe. On other machines it is 0xabadcafe.
	: Note: This argument does nothing on a release kernel.		: Note: This argument does nothing on a release kernel.

Philippe Ferrucci: /* How to set it up */

2015-01-21T21:22:00Z

How to set it up

← Older revision		Revision as of 21:22, 21 January 2015
Line 29:		Line 29:

	; serial		; serial
	: ~~Output~~ all debug via the serial port.		: Outputs all debug via the serial port, instead of using a memory buffer.

	; baudrate [N]		; baudrate [N]
Line 35:		Line 35:

	; debuglevel [N]		; debuglevel [N]
	: ~~Set~~ the debuglevel to level N.		: Sets the debuglevel to level N.
			: The debug level is the amount of information that should be output by the debug kernel.
	: Debug levels range between 0 to 20 ~~(higher levels are possible, but will produce too much output),~~ with 0 being no debug, 5 moderate output (all warnings are 5 or lower), 10 being lots of output, and 15 being an insane amount of output (fault conditions from kernel functions are displayed), and 20 being a ludicrous amount of output (entry and exit to functions will be logged).		: Debug levels range between 0 to 20 with 0 being no debug, 5 moderate output (all warnings are 5 or lower), 10 being lots of output, and 15 being an insane amount of output (fault conditions from kernel functions are displayed), and 20 being a ludicrous amount of output (entry and exit to functions will be logged).
			: Note: higher levels are possible, but will produce too much output to be useful.

	; nofpuemu		; nofpuemu
Line 42:		Line 44:

	; munge		; munge
	: Munges freed memory so that memory trashing can be found more easily when using a debug ~~kernel. Does nothing on a release~~ kernel.		: Munges (fills) freed memory with a recognisable value so that memory trashing can be found more easily when using a debug kernel.
			: In other words, no valid data will persist past any deallocation function, so if someone reads from memory that has just been freed, they are likely to get a pointer address to an area that will cause a DSI exception when accessed, instead of its previous contents.
			: On the Sam440 and Sam460, the longword munge value is 0xfefecafe. On other machines it is 0xabadcafe.
			: Note: This argument does nothing on a release kernel.

	{{Note\|text=It is strongly recommended that you do not rename the kernel.debug file.}}		{{Note\|text=It is strongly recommended that you do not rename the kernel.debug file.}}

Steven Solie: /* What is "debug kernel" exactly? */

2014-09-16T17:15:26Z

What is "debug kernel" exactly?

← Older revision		Revision as of 17:15, 16 September 2014
Line 11:		Line 11:
	#* If the value is 0x00000000 (or thereabouts), then you have accessed a null pointer (and you will see 0xABADCAFE in one or more registers);		#* If the value is 0x00000000 (or thereabouts), then you have accessed a null pointer (and you will see 0xABADCAFE in one or more registers);
	#* If the value is 0xDEADBEEF or 0xFEFEBEEF then you have accessed some memory after it has been freed;		#* If the value is 0xDEADBEEF or 0xFEFEBEEF then you have accessed some memory after it has been freed;
			#* If the value is 0xABADCAFE then you have accessed uninitialized memory;
	#* If the value is 0xCCCCCCCC (or thereabouts), then you have tried to free a Node a second time.		#* If the value is 0xCCCCCCCC (or thereabouts), then you have tried to free a Node a second time.

Steven Solie: /* FAQ */

2013-06-12T16:55:32Z

FAQ

← Older revision		Revision as of 16:55, 12 June 2013
Line 44:		Line 44:

	{{Note\|text=It is strongly recommended that you do not rename the kernel.debug file.}}		{{Note\|text=It is strongly recommended that you do not rename the kernel.debug file.}}

	== FAQ ==

	None at the moment

	[[Category:Debug]]		[[Category:Debug]]

Steven Solie: /* How to set it up */

2013-06-12T16:55:05Z

How to set it up

← Older revision		Revision as of 16:55, 12 June 2013
Line 23:		Line 23:
	Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.		Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.

	{{Note\|text=Do not confuse environment variables with command line parameters. ~~I.e.~~ ~~you can't~~ set kernel options via amigaboot.of like "amigaboot.of os4_commandline 'serial', ~~they~~ will be just ignored. Instead you ~~should~~ set those variables via "setenv" in the firmware, and then amigaboot.of will ~~get~~ them ~~from~~.}}		{{Note\|text=Do not confuse environment variables with command line parameters. You cannot set kernel options via amigaboot.of like "amigaboot.of os4_commandline 'serial'" and the extra parameters will be just ignored. Instead you must set those variables via the "setenv" command in the firmware and then amigaboot.of will parse them.}}

	The following kernel parameters are available:		The following kernel parameters are available:

Roman Kargin: /* How to set it up */

2013-06-12T14:02:51Z

How to set it up

← Older revision		Revision as of 14:02, 12 June 2013
Line 23:		Line 23:
	Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.		Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.

	{{Note\|text=Do not confuse environment variables with command line parameters. I.e. you can't set kernel options via amigaboot.of like "amigaboot.of os4_commandline 'serial', they will be just ignored. Instead you should set those variables in the firmware, and then amigaboot.of will get them from.}}		{{Note\|text=Do not confuse environment variables with command line parameters. I.e. you can't set kernel options via amigaboot.of like "amigaboot.of os4_commandline 'serial', they will be just ignored. Instead you should set those variables via "setenv" in the firmware, and then amigaboot.of will get them from.}}

	The following kernel parameters are available:		The following kernel parameters are available:

Roman Kargin: /* How to set it up */

2013-06-12T13:51:19Z

How to set it up

← Older revision		Revision as of 13:51, 12 June 2013
Line 23:		Line 23:
	Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.		Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.

	{{Note\|text=Do not confuse environment variables with command line parameters. I.e. you can't set kernel options like "amigaboot.of os4_commandline 'serial', they will be just ignored. Instead you should set those variables in the firmware, and then amigaboot.of will get them from.}}		{{Note\|text=Do not confuse environment variables with command line parameters. I.e. you can't set kernel options via amigaboot.of like "amigaboot.of os4_commandline 'serial', they will be just ignored. Instead you should set those variables in the firmware, and then amigaboot.of will get them from.}}

	The following kernel parameters are available:		The following kernel parameters are available:

Roman Kargin: /* How to set it up */

2013-06-12T13:48:02Z

How to set it up

← Older revision		Revision as of 13:48, 12 June 2013
Line 21:		Line 21:
	The preferred way to use the debug kernel is to edit your kicklayout file, duplicate the current layout and in this duplicate modify the line pointing to "kernel" so it points to "kernel.debug", do not forget to change the label associated with this new layout by adding 'debug' or something. This way you will be able to choose which configuration you want to boot at any time.		The preferred way to use the debug kernel is to edit your kicklayout file, duplicate the current layout and in this duplicate modify the line pointing to "kernel" so it points to "kernel.debug", do not forget to change the label associated with this new layout by adding 'debug' or something. This way you will be able to choose which configuration you want to boot at any time.

	Once you have setup the use of the debug kernel, you must also add some ~~commandline~~ options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like os4_commandline='munge', if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline='serial munge' to have the debug output to serial port and the munge option activated.		Once you have setup the use of the debug kernel, you must also add some options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like "setenv os4_commandline munge" or "setenv os4_commandline=munge" (depends on your firmware), if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline 'serial munge' to have the debug output to serial port and the munge option activated.

			{{Note\|text=Do not confuse environment variables with command line parameters. I.e. you can't set kernel options like "amigaboot.of os4_commandline 'serial', they will be just ignored. Instead you should set those variables in the firmware, and then amigaboot.of will get them from.}}

		⚫	The following kernel parameters are available:

⚫	The following kernel ~~command line~~ parameters are available:
	; serial		; serial
	: Output all debug via the serial port.		: Output all debug via the serial port.

Philippe Ferrucci: /* How to set it up */ added more details on the debug levels

2013-05-10T08:39:17Z

How to set it up: added more details on the debug levels

← Older revision		Revision as of 08:39, 10 May 2013
Line 19:		Line 19:
	The kernel.debug file is already placed in the Kickstart directory with all the other kernel modules. By default this directory is "SYS:Kickstart/".		The kernel.debug file is already placed in the Kickstart directory with all the other kernel modules. By default this directory is "SYS:Kickstart/".

	The preferred way to use the debug kernel is to edit your ~~file~~ kicklayout, duplicate the current layout and in this duplicate modify the line pointing to "kernel" so it points to "kernel.debug", do not forget to change the label associated with this new layout by adding 'debug' or something. This way you will be able to choose which configuration you want to boot at any time.		The preferred way to use the debug kernel is to edit your kicklayout file, duplicate the current layout and in this duplicate modify the line pointing to "kernel" so it points to "kernel.debug", do not forget to change the label associated with this new layout by adding 'debug' or something. This way you will be able to choose which configuration you want to boot at any time.

	Once you have setup the use of the debug kernel, you must also add some commandline options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like os4_commandline='munge', if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline='serial munge' to have the debug output to serial port and the munge option activated.		Once you have setup the use of the debug kernel, you must also add some commandline options to the kernel. Basically in order to activate the munge option of the debug kernel you must set the variable "os4_commandline" adds the keyword "munge". This part depends on your platform firmware, please report to your documentation to know how to do it, but you have to do something like os4_commandline='munge', if os4_commandline is already set with another value you can concatenate using space e.g. os4_commandline='serial munge' to have the debug output to serial port and the munge option activated.
Line 31:		Line 31:

	; debuglevel [N]		; debuglevel [N]
	: Set the debuglevel ~~where~~ N ~~is a value from 0 to 10~~.		: Set the debuglevel to level N.
			: Debug levels range between 0 to 20 (higher levels are possible, but will produce too much output), with 0 being no debug, 5 moderate output (all warnings are 5 or lower), 10 being lots of output, and 15 being an insane amount of output (fault conditions from kernel functions are displayed), and 20 being a ludicrous amount of output (entry and exit to functions will be logged).

	; nofpuemu		; nofpuemu

Steven Solie: /* What is "debug kernel" exactly? */

2013-03-04T00:10:27Z

What is "debug kernel" exactly?

← Older revision		Revision as of 00:10, 4 March 2013
Line 8:		Line 8:

	# Clobbering of succ/pred pointers when a Node is removed from a list.<BR>One common mistake when dealing with lists is to access successor and/or previous pointers from a removed node. While at first sight it may seems harmless it may reveal itself as a dreadful bug to spot because once a node has been removed from a list nothing guarantees you that the list has not be reworked/copied/reallocated or anything else. This will give you a bug that is very hard to reproduce or even non reproducible at all. As such one should NEVER access Succ/Prev pointers from a removed Node, instead if he needs to, he should access them prior the call to Remove(). To help spotting such errors the debug kernel will modify the ln_Succ/ln_Prev pointer to a given fixed invalid value thus the bug automatically becomes always reproducible. This will also help you spot the fact one is trying to free a Node twice.		# Clobbering of succ/pred pointers when a Node is removed from a list.<BR>One common mistake when dealing with lists is to access successor and/or previous pointers from a removed node. While at first sight it may seems harmless it may reveal itself as a dreadful bug to spot because once a node has been removed from a list nothing guarantees you that the list has not be reworked/copied/reallocated or anything else. This will give you a bug that is very hard to reproduce or even non reproducible at all. As such one should NEVER access Succ/Prev pointers from a removed Node, instead if he needs to, he should access them prior the call to Remove(). To help spotting such errors the debug kernel will modify the ln_Succ/ln_Prev pointer to a given fixed invalid value thus the bug automatically becomes always reproducible. This will also help you spot the fact one is trying to free a Node twice.
	# "Munge" of memory. With this option the debug kernel will do additional ~~action/~~tests on memory pointers. It will help spotting what really ~~happen under the hood~~ just by observing the DAR (or DEAR on 440ep and 460ex CPUs) value in the crash log:		# "Munge" of memory. With this option the debug kernel will do additional tests on memory pointers. It will help spotting what really happened just by observing the DAR (or DEAR on 440ep and 460ex CPUs) value in the crash log:
	#* If the value is 0x00000000 (or thereabouts), then you have accessed a null pointer (and you will see 0xABADCAFE in one or more registers);		#* If the value is 0x00000000 (or thereabouts), then you have accessed a null pointer (and you will see 0xABADCAFE in one or more registers);
	#* If the value is 0xDEADBEEF (or ~~thereabouts),~~ then you have accessed some memory after it has been freed;		#* If the value is 0xDEADBEEF or 0xFEFEBEEF then you have accessed some memory after it has been freed;
	#* If the value is 0xCCCCCCCC (or thereabouts), then you have tried to free a Node a second time.		#* If the value is 0xCCCCCCCC (or thereabouts), then you have tried to free a Node a second time.

	~~So, in other words, when~~ you want to catch all those problems which you can't catch by just simply running MemGuard on a ~~"plain"~~ kernel, you should use the debug kernel. ~~I.e.~~ to ~~say~~ it ~~more~~ ~~clear,~~ ~~when~~ you ~~develop~~ ~~anything you should be just on~~ debug kernel.		When you want to catch all those problems which you can't catch by just simply running MemGuard on a release kernel then you should use the debug kernel. When developing software, it is recommended that you use the debug kernel.

	== How to set it up ==		== How to set it up ==