Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[George Anzinger]

Comments below...

Tom Rini wrote:
> Hello.  The following patch moves all of the config options into one file,
> kernel/Kconfig.kgdb.
> 
> diff -zrupN linux-2.6.3+nothing/arch/i386/Kconfig linux-2.6.3+config+serial/arch/i386/Kconfig
> --- linux-2.6.3+nothing/arch/i386/Kconfig	2004-02-27 12:16:14.296187607 -0700
> +++ linux-2.6.3+config+serial/arch/i386/Kconfig	2004-02-27 12:16:13.707320867 -0700
> @@ -1253,36 +1253,7 @@ config DEBUG_SPINLOCK_SLEEP
>  	  If you say Y here, various routines which may sleep will become very
>  	  noisy if they are called with a spinlock held.	
>  
> -config KGDB
> -	bool "KGDB: kernel debugging with remote gdb"
> -	depends on DEBUG_KERNEL
> -	select DEBUG_INFO
> -	select FRAME_POINTER
> -	help
> -	  If you say Y here, it will be possible to remotely debug the
> -	  kernel using gdb. This enlarges your kernel image disk size by
> -	  several megabytes and requires a machine with more than 128 MB
> -	  RAM to avoid excessive linking time. 
> -	  Documentation of kernel debugger available at
> -	  http://kgdb.sourceforge.net
> -	  This is only useful for kernel hackers. If unsure, say N.
> -
> -config KGDB_THREAD
> -	bool "KGDB: Thread analysis"
> -	depends on KGDB
> -	help
> -	  With thread analysis enabled, gdb can talk to kgdb stub to list
> -	  threads and to get stack trace for a thread. This option also enables
> -	  some code which helps gdb get exact status of thread. Thread analysis
> -	  adds some overhead to schedule and down functions. You can disable
> -	  this option if you do not want to compromise on speed.
> -
> -config KGDB_CONSOLE
> -	bool "KGDB: Console messages through gdb"
> -	depends on KGDB
> -	help
> -	  If you say Y here, console messages will appear through gdb.
> -	  Other consoles such as tty or ttyS will continue to work as usual.
> +source "kernel/Kconfig.kgdb"
>  
>  config FRAME_POINTER
>  	bool "Compile the kernel with frame pointers"
> diff -zrupN linux-2.6.3+nothing/arch/ppc/Kconfig linux-2.6.3+config+serial/arch/ppc/Kconfig
> --- linux-2.6.3+nothing/arch/ppc/Kconfig	2004-02-27 12:16:14.403163398 -0700
> +++ linux-2.6.3+config+serial/arch/ppc/Kconfig	2004-02-27 12:16:13.771306387 -0700
> @@ -1170,52 +1170,7 @@ config DEBUG_SPINLOCK_SLEEP
>  	  If you say Y here, various routines which may sleep will become very
>  	  noisy if they are called with a spinlock held.
>  
> -config KGDB
> -	bool "Include kgdb kernel debugger"
> -	depends on DEBUG_KERNEL
> -	select DEBUG_INFO
> -	select FRAME_POINTER
> -	help
> -	  Include in-kernel hooks for kgdb, the Linux kernel source level
> -	  debugger.  See <http://kgdb.sourceforge.net/> for more information.
> -	  Unless you are intending to debug the kernel, say N here.
> -
> -choice
> -	prompt "Serial Port"
> -	depends on KGDB
> -	default KGDB_TTYS1
> -
> -config KGDB_TTYS0
> -	bool "ttyS0"
> -
> -config KGDB_TTYS1
> -	bool "ttyS1"
> -
> -config KGDB_TTYS2
> -	bool "ttyS2"
> -
> -config KGDB_TTYS3
> -	bool "ttyS3"
> -
> -endchoice
> -
> -config KGDB_THREAD
> -	bool "KGDB: Thread analysis"
> -	depends on KGDB
> -	help
> -	  With thread analysis enabled, gdb can talk to kgdb stub to list
> -	  threads and to get stack trace for a thread. This option also enables
> -	  some code which helps gdb get exact status of thread. Thread analysis
> -	  adds some overhead to schedule and down functions. You can disable
> -	  this option if you do not want to compromise on speed.
> -
> -config KGDB_CONSOLE
> -	bool "Enable serial console thru kgdb port"
> -	depends on KGDB && 8xx || 8260
> -	help
> -	  If you enable this, all serial console messages will be sent
> -	  over the gdb stub.
> -	  If unsure, say N.
> +source "kernel/Kconfig.kgdb"
>  
>  config XMON
>  	bool "Include xmon kernel debugger"
> diff -zrupN linux-2.6.3+nothing/arch/x86_64/Kconfig linux-2.6.3+config+serial/arch/x86_64/Kconfig
> --- linux-2.6.3+nothing/arch/x86_64/Kconfig	2004-02-27 12:16:14.350175389 -0700
> +++ linux-2.6.3+config+serial/arch/x86_64/Kconfig	2004-02-27 12:16:13.718318378 -0700
> @@ -465,37 +465,7 @@ config IOMMU_LEAK
>           Add a simple leak tracer to the IOMMU code. This is useful when you
>  	 are debugging a buggy device driver that leaks IOMMU mappings.
>         
> -config KGDB
> -	bool "KGDB: kernel debugging with remote gdb"
> -	depends on DEBUG_KERNEL
> -	select DEBUG_INFO
> -	select FRAME_POINTER
> -	help
> -	  If you say Y here, it will be possible to remotely debug the
> -	  kernel using gdb. This enlarges your kernel image disk size by
> -	  several megabytes and requires a machine with more than 128 MB
> -	  RAM to avoid excessive linking time. 
> -	  Documentation of kernel debugger available at
> -	  http://kgdb.sourceforge.net
> -	  This is only useful for kernel hackers. If unsure, say N.
> -
> -config KGDB_THREAD
> -	bool "KGDB: Thread analysis"
> -	depends on KGDB
> -	help
> -	  With thread analysis enabled, gdb can talk to kgdb stub to list
> -	  threads and to get stack trace for a thread. This option also enables
> -	  some code which helps gdb get exact status of thread. Thread analysis
> -	  adds some overhead to schedule and down functions. You can disable
> -	  this option if you do not want to compromise on speed.
> -
> -config KGDB_CONSOLE
> -	bool "KGDB: Console messages through gdb"
> -	depends on KGDB
> -	help
> -	  If you say Y here, console messages will appear through gdb.
> -	  Other consoles such as tty or ttyS will continue to work as usual.
> -
> +source "kernel/Kconfig.kgdb"
>  endmenu
>  
>  source "security/Kconfig"
> diff -zrupN linux-2.6.3+nothing/drivers/net/Kconfig linux-2.6.3+config+serial/drivers/net/Kconfig
> --- linux-2.6.3+nothing/drivers/net/Kconfig	2004-02-27 12:16:14.521136701 -0700
> +++ linux-2.6.3+config+serial/drivers/net/Kconfig	2004-02-27 12:06:22.000000000 -0700
> @@ -187,12 +187,6 @@ config NET_ETHERNET
>  	  Note that the answer to this question won't directly affect the
>  	  kernel: saying N will just cause the configurator to skip all
>  	  the questions about Ethernet network cards. If unsure, say N.
> -	
> -config KGDB_ETH
> -	bool "KGDB: On ethernet"
> -	depends on KGDB
> -	help
> -	  Uses ethernet interface for kgdb.
>  
>  config MII
>  	tristate "Generic Media Independent Interface device support"
> diff -zrupN linux-2.6.3+nothing/drivers/serial/Kconfig linux-2.6.3+config+serial/drivers/serial/Kconfig
> --- linux-2.6.3+nothing/drivers/serial/Kconfig	2004-02-27 12:16:14.545131271 -0700
> +++ linux-2.6.3+config+serial/drivers/serial/Kconfig	2004-02-27 12:06:30.000000000 -0700
> @@ -6,34 +6,6 @@
>  
>  menu "Serial drivers"
>  
> -config KGDB_8250
> -	bool "KGDB: On generic serial port (8250)"
> -	depends on KGDB
> -	help
> -	  Uses generic serial port (8250) for kgdb. This is independent of the
> -	  option 9250/16550 and compatible serial port.
> -
> -config KGDB_PORT
> -	hex "hex I/O port address of the debug serial port"
> -	depends on KGDB_8250
> -	default  3f8
> -	help
> -	  Some systems (x86 family at this writing) allow the port
> -	  address to be configured.  The number entered is assumed to be
> -	  hex, don't put 0x in front of it.  The standard address are:
> -	  COM1 3f8 , irq 4 and COM2 2f8 irq 3.  Setserial /dev/ttySx
> -	  will tell you what you have.  It is good to test the serial
> -	  connection with a live system before trying to debug.
> -
> -config KGDB_IRQ
> -	int "IRQ of the debug serial port"
> -	depends on KGDB_8250
> -	default 4
> -	help
> -	  This is the irq for the debug port.  If everything is working
> -	  correctly and the kernel has interrupts on a control C to the
> -	  port should cause a break into the kernel debug stub.
> -
>  #
>  # The new 8250/16550 serial drivers
>  config SERIAL_8250
> diff -zrupN linux-2.6.3+nothing/kernel/Kconfig.kgdb linux-2.6.3+config+serial/kernel/Kconfig.kgdb
> --- linux-2.6.3+nothing/kernel/Kconfig.kgdb	1969-12-31 17:00:00.000000000 -0700
> +++ linux-2.6.3+config+serial/kernel/Kconfig.kgdb	2004-02-27 12:16:13.000000000 -0700
> @@ -0,0 +1,141 @@
> +config KGDB
> +	bool "KGDB: kernel debugging with remote gdb"
> +	depends on DEBUG_KERNEL
> +	select DEBUG_INFO
> +	select FRAME_POINTER
This is not needed and may not be what you want.  It changes the code generated 
(Heisenberg).  With dwarf frames, it is no longer required or even useful.
> +	# XXX: Doesn't work w/o this right now
> +	select KGDB_THREAD if PPC32
> +	help
> +	  If you say Y here, it will be possible to remotely debug the
> +	  kernel using gdb. This enlarges your kernel image disk size by
> +	  several megabytes and requires a machine with more than 128 MB
> +	  RAM to avoid excessive linking time. 
> +	  Documentation of kernel debugger available at
> +	  http://kgdb.sourceforge.net
> +	  This is only useful for kernel hackers. If unsure, say N.
PLEASE, lets not use the word "hackers".  Surly "coders" or some such is more 
complementary.  After all these are US.
> +
> +choice
> +	prompt "Method for KGDB communication"
> +	depends on KGDB
> +	default PPC_SIMPLE_SERIAL if PPC32 && (8xx || 8260)
> +	default KGDB_8250
> +	help
> +	  There are a number of different ways in which you can communicate
> +	  with KGDB.  The oldest is using a serial driver.  A newer method
> +	  is to use UDP packets and a special network driver.
> +
> +config KGDB_8250
> +	bool "KGDB: On generic serial port (8250)"
> +	help
> +	  Uses generic serial port (8250) for kgdb. This is independent of the
> +	  option 9250/16550 and compatible serial port.
> +
> +config KGDB_ETH
> +	bool "KGDB: On ethernet"
> +	select NETPOLL
> +	select NETPOLL_TRAP
> +	select NETPOLL_RX
> +	help
> +	  Uses ethernet interface for kgdb.
> +
> +config PPC_SIMPLE_SERIAL 
> +	bool "KGDB: On any serial port"
> +	depends on PPC32
> +	help
> +	  Use a very simple, and not necessarily feature complete serial
> +	  driver.  This is the only serial option currently for MPC8xx or
> +	  MPC82xx based ports that do not offer an 8250-style UART.
> +
> +endchoice
> +
> +config KGDB_SIMPLE_SERIAL
> +	bool "Simple selection of KGDB serial port"
> +	depends on KGDB_8250 || PPC_SIMPLE_SERIAL
> +	help
> +	  If you say Y here, you will only have to pick the baud rate
> +	  and serial port (ttyS) that you wish to use for KGDB.  If you
> +	  say N, you will have provide the I/O port and IRQ number.  Note
> +	  that if your serial ports are iomapped, then you must say Y here.
> +	  If in doubt, say Y.
> +
> +choice
> +	depends on KGDB_8250 || PPC_SIMPLE_SERIAL
> +    	prompt "Debug serial port BAUD"
> +	default KGDB_115200BAUD
> +	help
> +	  Gdb and the kernel stub need to agree on the baud rate to be
> +	  used.  Some systems (x86 family at this writing) allow this to
> +	  be configured.

Should this depend on the archs that can use it?
> +
> +config KGDB_9600BAUD
> +	bool "9600"
> +
> +config KGDB_19200BAUD
> +	bool "19200"
> +
> +config KGDB_38400BAUD
> +	bool "38400"
> +
> +config KGDB_57600BAUD
> +	bool "57600"
> +
> +config KGDB_115200BAUD
> +	bool "115200"
> +endchoice
> +
> +choice
> +	prompt "Serial port for KGDB"
> +	depends on KGDB_SIMPLE_SERIAL
> +	default KGDB_TTYS0
> +
> +config KGDB_TTYS0
> +	bool "ttyS0"
> +
> +config KGDB_TTYS1
> +	bool "ttyS1"
> +
> +config KGDB_TTYS2
> +	bool "ttyS2"
> +
> +config KGDB_TTYS3
> +	bool "ttyS3"
> +
> +endchoice
> +
> +config KGDB_PORT
> +	hex "hex I/O port address of the debug serial port"
> +	depends on !KGDB_SIMPLE_SERIAL && (KGDB_8250 || PPC_SIMPLE_SERIAL)
> +	default  3f8
> +	help
> +	  Some systems (x86 family at this writing) allow the port
> +	  address to be configured.  The number entered is assumed to be
> +	  hex, don't put 0x in front of it.  The standard address are:
> +	  COM1 3f8 , irq 4 and COM2 2f8 irq 3.  Setserial /dev/ttySx
> +	  will tell you what you have.  It is good to test the serial
> +	  connection with a live system before trying to debug.
> +
> +config KGDB_IRQ
> +	int "IRQ of the debug serial port"
> +	depends on !KGDB_SIMPLE_SERIAL && (KGDB_8250 || PPC_SIMPLE_SERIAL)
> +	default 4
> +	help
> +	  This is the irq for the debug port.  If everything is working
> +	  correctly and the kernel has interrupts on a control C to the
> +	  port should cause a break into the kernel debug stub.
I think setserial will also spit this out.
> +
> +config KGDB_THREAD
> +	bool "KGDB: Thread analysis"
> +	depends on KGDB
> +	help
> +	  With thread analysis enabled, gdb can talk to kgdb stub to list
> +	  threads and to get stack trace for a thread. This option also enables
> +	  some code which helps gdb get exact status of thread. Thread analysis
> +	  adds some overhead to schedule and down functions. You can disable
> +	  this option if you do not want to compromise on speed.

Lets remove the overhead and eliminate the need for this option in favor of 
always having threads.  Works in the mm kgdb...
> +
> +config KGDB_CONSOLE
> +	bool "KGDB: Console messages through gdb"
> +	depends on KGDB
> +	help
> +	  If you say Y here, console messages will appear through gdb.
> +	  Other consoles such as tty or ttyS will continue to work as usual.
> 
Might want to warn them of the need to connect prior to the first message from 
the kernel....

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

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Tom Rini]

On Fri, Feb 27, 2004 at 02:30:57PM -0800, George Anzinger wrote:

> Comments below...

I'm going to set aside some of the comments, simply because I'm not
going to change behavior / content right now, we can do that afterwards.

[snip]
> >+choice
> >+	depends on KGDB_8250 || PPC_SIMPLE_SERIAL
> >+    	prompt "Debug serial port BAUD"
> >+	default KGDB_115200BAUD
> >+	help
> >+	  Gdb and the kernel stub need to agree on the baud rate to be
> >+	  used.  Some systems (x86 family at this writing) allow this to
> >+	  be configured.
> 
> Should this depend on the archs that can use it?

The help is wrong, that's all, it's not arch-dependant, it's driver
dependant.

> >+config KGDB_IRQ
> >+	int "IRQ of the debug serial port"
> >+	depends on !KGDB_SIMPLE_SERIAL && (KGDB_8250 || PPC_SIMPLE_SERIAL)
> >+	default 4
> >+	help
> >+	  This is the irq for the debug port.  If everything is working
> >+	  correctly and the kernel has interrupts on a control C to the
> >+	  port should cause a break into the kernel debug stub.
>
> I think setserial will also spit this out.

And of course, ^C isn't needed now too.

> >+config KGDB_THREAD
> >+	bool "KGDB: Thread analysis"
> >+	depends on KGDB
> >+	help
> >+	  With thread analysis enabled, gdb can talk to kgdb stub to list
> >+	  threads and to get stack trace for a thread. This option also 
> >enables
> >+	  some code which helps gdb get exact status of thread. Thread 
> >analysis
> >+	  adds some overhead to schedule and down functions. You can disable
> >+	  this option if you do not want to compromise on speed.
> 
> Lets remove the overhead and eliminate the need for this option in favor of 
> always having threads.  Works in the mm kgdb...

Once it's clean, perhaps.

> >+config KGDB_CONSOLE
> >+	bool "KGDB: Console messages through gdb"
> >+	depends on KGDB
> >+	help
> >+	  If you say Y here, console messages will appear through gdb.
> >+	  Other consoles such as tty or ttyS will continue to work as usual.
>
> Might want to warn them of the need to connect prior to the first message 
> from the kernel....

There is no such need.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Pavel Machek]

Hi!


> >+config KGDB_THREAD
> >+	bool "KGDB: Thread analysis"
> >+	depends on KGDB
> >+	help
> >+	  With thread analysis enabled, gdb can talk to kgdb stub to list
> >+	  threads and to get stack trace for a thread. This option also 
> >enables
> >+	  some code which helps gdb get exact status of thread. Thread 
> >analysis
> >+	  adds some overhead to schedule and down functions. You can disable
> >+	  this option if you do not want to compromise on speed.
> 
> Lets remove the overhead and eliminate the need for this option in favor of 
> always having threads.  Works in the mm kgdb...

No. Thread analysis is unsuitable for the mainline (manipulates
sched.c in ugly way). It may be okay for -mm, but in such case it
should better be separated.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
> 
>>>+config KGDB_THREAD
>>>+	bool "KGDB: Thread analysis"
>>>+	depends on KGDB
>>>+	help
>>>+	  With thread analysis enabled, gdb can talk to kgdb stub to list
>>>+	  threads and to get stack trace for a thread. This option also 
>>>enables
>>>+	  some code which helps gdb get exact status of thread. Thread 
>>>analysis
>>>+	  adds some overhead to schedule and down functions. You can disable
>>>+	  this option if you do not want to compromise on speed.
>>
>>Lets remove the overhead and eliminate the need for this option in favor of 
>>always having threads.  Works in the mm kgdb...
> 
> 
> No. Thread analysis is unsuitable for the mainline (manipulates
> sched.c in ugly way). It may be okay for -mm, but in such case it
> should better be separated.

Not in the -mm version.  I agree that sched.c should NEVER be treated this way 
and it is not in the -mm version.  I also think that, most of the time, it is 
useful to have the thread stuff, but that may be just my usage...


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

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Amit S. Kale]

On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >>>+config KGDB_THREAD
> >>>+	bool "KGDB: Thread analysis"
> >>>+	depends on KGDB
> >>>+	help
> >>>+	  With thread analysis enabled, gdb can talk to kgdb stub to list
> >>>+	  threads and to get stack trace for a thread. This option also
> >>>enables
> >>>+	  some code which helps gdb get exact status of thread. Thread
> >>>analysis
> >>>+	  adds some overhead to schedule and down functions. You can disable
> >>>+	  this option if you do not want to compromise on speed.
> >>
> >>Lets remove the overhead and eliminate the need for this option in favor
> >> of always having threads.  Works in the mm kgdb...
> >
> > No. Thread analysis is unsuitable for the mainline (manipulates
> > sched.c in ugly way). It may be okay for -mm, but in such case it
> > should better be separated.
>
> Not in the -mm version.  I agree that sched.c should NEVER be treated this
> way and it is not in the -mm version.  I also think that, most of the time,
> it is useful to have the thread stuff, but that may be just my usage...

If threads stuff didn't introduce any unclean code changes, I too would prefer 
to have it on all the time. As things stands, threads stuff is rather 
intrusive.

-Amit

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[George Anzinger]

Amit S. Kale wrote:
> On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
> 
>>Pavel Machek wrote:
>>
>>>Hi!
>>>
>>>
>>>>>+config KGDB_THREAD
>>>>>+	bool "KGDB: Thread analysis"
>>>>>+	depends on KGDB
>>>>>+	help
>>>>>+	  With thread analysis enabled, gdb can talk to kgdb stub to list
>>>>>+	  threads and to get stack trace for a thread. This option also
>>>>>enables
>>>>>+	  some code which helps gdb get exact status of thread. Thread
>>>>>analysis
>>>>>+	  adds some overhead to schedule and down functions. You can disable
>>>>>+	  this option if you do not want to compromise on speed.
>>>>
>>>>Lets remove the overhead and eliminate the need for this option in favor
>>>>of always having threads.  Works in the mm kgdb...
>>>
>>>No. Thread analysis is unsuitable for the mainline (manipulates
>>>sched.c in ugly way). It may be okay for -mm, but in such case it
>>>should better be separated.
>>
>>Not in the -mm version.  I agree that sched.c should NEVER be treated this
>>way and it is not in the -mm version.  I also think that, most of the time,
>>it is useful to have the thread stuff, but that may be just my usage...
> 
> 
> If threads stuff didn't introduce any unclean code changes, I too would prefer 
> to have it on all the time. As things stands, threads stuff is rather 
> intrusive.

Lets put the threads stuff in the stub.  The only stuff we need in the kernel is 
the flag that indicateds that the pid hash table has been initialized.

Meanwhile, I would like to make a change to the gdb "info thread" command to do 
a better job of displaying the threads.  Here is what I am proposing:

Gdb would work as it does now if the following set is not done.

A new "set thread_level" command that would take the "bt" level to use on the 
thread display.
A new "set thread_limits command that would take two expressions that would 
reduce to two memory addresses.

Which ever of these is entered last will be active and used by "info thread" as 
follows:

if thread_level is active gdb will do the indicated number of  "up" operations 
and display the result on the info thread line for that thread (note there is 
other info on this line that will not be changed).

if thread_limits is active gdb will do 0 or more "up" commands until the 
resultant PC is NOT between the given limits.

The kernel, at this time, has defined symbols for the thread_limits command (it 
is used in the kernel for its internal display of threads).  I would expect that 
the thread_level version would be the answer for theaded application programs.

Daniel, how does this sound?

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

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Amit S. Kale]

On Wednesday 03 Mar 2004 3:08 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
> >>Pavel Machek wrote:
> >>>Hi!
> >>>
> >>>>>+config KGDB_THREAD
> >>>>>+	bool "KGDB: Thread analysis"
> >>>>>+	depends on KGDB
> >>>>>+	help
> >>>>>+	  With thread analysis enabled, gdb can talk to kgdb stub to list
> >>>>>+	  threads and to get stack trace for a thread. This option also
> >>>>>enables
> >>>>>+	  some code which helps gdb get exact status of thread. Thread
> >>>>>analysis
> >>>>>+	  adds some overhead to schedule and down functions. You can disable
> >>>>>+	  this option if you do not want to compromise on speed.
> >>>>
> >>>>Lets remove the overhead and eliminate the need for this option in
> >>>> favor of always having threads.  Works in the mm kgdb...
> >>>
> >>>No. Thread analysis is unsuitable for the mainline (manipulates
> >>>sched.c in ugly way). It may be okay for -mm, but in such case it
> >>>should better be separated.
> >>
> >>Not in the -mm version.  I agree that sched.c should NEVER be treated
> >> this way and it is not in the -mm version.  I also think that, most of
> >> the time, it is useful to have the thread stuff, but that may be just my
> >> usage...
> >
> > If threads stuff didn't introduce any unclean code changes, I too would
> > prefer to have it on all the time. As things stands, threads stuff is
> > rather intrusive.
>
> Lets put the threads stuff in the stub.  The only stuff we need in the
> kernel is the flag that indicateds that the pid hash table has been
> initialized.
>
> Meanwhile, I would like to make a change to the gdb "info thread" command
> to do a better job of displaying the threads.  Here is what I am proposing:
>
> Gdb would work as it does now if the following set is not done.
>
> A new "set thread_level" command that would take the "bt" level to use on
> the thread display.
> A new "set thread_limits command that would take two expressions that would
> reduce to two memory addresses.
>
> Which ever of these is entered last will be active and used by "info
> thread" as follows:
>
> if thread_level is active gdb will do the indicated number of  "up"
> operations and display the result on the info thread line for that thread
> (note there is other info on this line that will not be changed).

You can already do a backtrace on all threads using gdb command
"thread apply all backtrace".

>
> if thread_limits is active gdb will do 0 or more "up" commands until the
> resultant PC is NOT between the given limits.

How does a user specify PC? There are umpteen number of kernel entry points 
(irqs, exceptions, system calls).

> The kernel, at this time, has defined symbols for the thread_limits command
> (it is used in the kernel for its internal display of threads).  I would
> expect that the thread_level version would be the answer for theaded
> application programs.
>
> Daniel, how does this sound?


The problem with kernel backtraces not stopping at kernel entry points is a 
tough one. gdbmod at kgdb.sourceforge.net attempts to do that. This gdb 
detects if we are debugging a kernel. If we are, a few things kick in like 
scanning of modules instead of .so libraries and stopping backtraces earlier.

GDB uses main as the function where backtraces stop unless overridden. This is 
broken by definition for multithreaded programs becauses non initial threads 
don't start from main. Kernel too doesn't have main and has several entry 
points.

If there is a way for gdb to know entry points from the kernel, it would be 
very easy to maintain. Say a .entrypoint section that lists pc ranges of 
entry points. GDB then stop a backtrace as soon as it enters one of these 
ranges.
-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Jim Houston]

> Meanwhile, I would like to make a change to the gdb "info thread"
> command to do a better job of displaying the threads.  Here is what
> I am proposing:
> 
> Gdb would work as it does now if the following set is not done.
> 
> A new "set thread_level" command that would take the "bt" level to use
> on the thread display.
> A new "set thread_limits command that would take two expressions that
> would reduce to two memory addresses.

Hi George,

I already did a bit of work in this space.  You might give my 
gdb-thread-skip-frame.patch a try.  

You can find it archived here:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/gdb/gdb-6.0/gdb-thread-skip-frame.patch

Jim Houston

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[George Anzinger]

Jim Houston wrote:
>>Meanwhile, I would like to make a change to the gdb "info thread"
>>command to do a better job of displaying the threads.  Here is what
>>I am proposing:
>>
>>Gdb would work as it does now if the following set is not done.
>>
>>A new "set thread_level" command that would take the "bt" level to use
>>on the thread display.
>>A new "set thread_limits command that would take two expressions that
>>would reduce to two memory addresses.
> 
> 
> Hi George,
> 
> I already did a bit of work in this space.  You might give my 
> gdb-thread-skip-frame.patch a try.  
> 
> You can find it archived here:
> 
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/gdb/gdb-6.0/gdb-thread-skip-frame.patch

I have been talking with the gdb folks and I think we are real close to having a 
solution that makes very minimal (if any) changes to gdb.  At this point we can 
write a couple of macros that do almost all that we need.  The only problem 
seems to be the number of lines per thread in the report.  So, the only change 
to gdb would be to suppress a carrage return in a couple of places.

It does require that we implement a new command in the stub, or rather, that we 
change the ThreadExtraInfo command to do the same thing with a different command.

I will keep you posted, or better yet, sign up for the gdb@sources.redhat.com 
mailing list and listen in.

-g
> 
> Jim Houston
> 

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

Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[George Anzinger]

[-- Attachment #1: Type: text/plain, Size: 4879 bytes --]

Amit S. Kale wrote:
> On Wednesday 03 Mar 2004 3:08 am, George Anzinger wrote:
> 
>>Amit S. Kale wrote:
>>
>>>On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
>>>
>>>>Pavel Machek wrote:
>>>>
>>>>>Hi!
>>>>>
>>>>>
>>>>>>>+config KGDB_THREAD
>>>>>>>+	bool "KGDB: Thread analysis"
>>>>>>>+	depends on KGDB
>>>>>>>+	help
>>>>>>>+	  With thread analysis enabled, gdb can talk to kgdb stub to list
>>>>>>>+	  threads and to get stack trace for a thread. This option also
>>>>>>>enables
>>>>>>>+	  some code which helps gdb get exact status of thread. Thread
>>>>>>>analysis
>>>>>>>+	  adds some overhead to schedule and down functions. You can disable
>>>>>>>+	  this option if you do not want to compromise on speed.
>>>>>>
>>>>>>Lets remove the overhead and eliminate the need for this option in
>>>>>>favor of always having threads.  Works in the mm kgdb...
>>>>>
>>>>>No. Thread analysis is unsuitable for the mainline (manipulates
>>>>>sched.c in ugly way). It may be okay for -mm, but in such case it
>>>>>should better be separated.
>>>>
>>>>Not in the -mm version.  I agree that sched.c should NEVER be treated
>>>>this way and it is not in the -mm version.  I also think that, most of
>>>>the time, it is useful to have the thread stuff, but that may be just my
>>>>usage...
>>>
>>>If threads stuff didn't introduce any unclean code changes, I too would
>>>prefer to have it on all the time. As things stands, threads stuff is
>>>rather intrusive.
>>
>>Lets put the threads stuff in the stub.  The only stuff we need in the
>>kernel is the flag that indicateds that the pid hash table has been
>>initialized.
>>
>>Meanwhile, I would like to make a change to the gdb "info thread" command
>>to do a better job of displaying the threads.  Here is what I am proposing:
>>
>>Gdb would work as it does now if the following set is not done.
>>
>>A new "set thread_level" command that would take the "bt" level to use on
>>the thread display.
>>A new "set thread_limits command that would take two expressions that would
>>reduce to two memory addresses.
>>
>>Which ever of these is entered last will be active and used by "info
>>thread" as follows:
>>
>>if thread_level is active gdb will do the indicated number of  "up"
>>operations and display the result on the info thread line for that thread
>>(note there is other info on this line that will not be changed).
> 
> 
> You can already do a backtrace on all threads using gdb command
> "thread apply all backtrace".
> 
> 
>>if thread_limits is active gdb will do 0 or more "up" commands until the
>>resultant PC is NOT between the given limits.
> 
> 
> How does a user specify PC? There are umpteen number of kernel entry points 
> (irqs, exceptions, system calls).

We are not interested in that.  There are two entry points in the kernel:

void scheduling_functions_start_here(void);
void scheduling_functions_end_here(void);

that bound the area we don't want to show the task in in the info thread 
command.  $PC is the same as $ESP in the x86, but it is defined in all archs 
regardless of the particular local name for the stack pointer.

> 
> 
>>The kernel, at this time, has defined symbols for the thread_limits command
>>(it is used in the kernel for its internal display of threads).  I would
>>expect that the thread_level version would be the answer for theaded
>>application programs.
>>
>>Daniel, how does this sound?
> 
> 
> 
> The problem with kernel backtraces not stopping at kernel entry points is a 
> tough one. gdbmod at kgdb.sourceforge.net attempts to do that. This gdb 
> detects if we are debugging a kernel. If we are, a few things kick in like 
> scanning of modules instead of .so libraries and stopping backtraces earlier.

Stopping "bt" is a different problem, one which should be addressed by fixing up 
the debug frame records to indicate where the bottom of the stack is.  I have 
code for this for the x86, but it uses CPP macros rather than the gas interface 
for such which is rather restrictive.
> 
> GDB uses main as the function where backtraces stop unless overridden. This is 
> broken by definition for multithreaded programs becauses non initial threads 
> don't start from main. Kernel too doesn't have main and has several entry 
> points.
> 
> If there is a way for gdb to know entry points from the kernel, it would be 
> very easy to maintain. Say a .entrypoint section that lists pc ranges of 
> entry points. GDB then stop a backtrace as soon as it enters one of these 
> ranges.

No, this is not enough.  It needs to also know to stop when the interrupt/ trap 
returns to user space.  You might try the attached patch.  Be warned, however, 
that it requires a CVS gdb (I found broken code).

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

[-- Attachment #2: kgdb-dwarf2-2.6.0-1.0.patch.gz --]
[-- Type: application/x-gzip, Size: 11623 bytes --]