Message-ID: <400237F0.9020407@mvista.com>
Date: Sun, 11 Jan 2004 22:00:16 -0800
From: George Anzinger <george@mvista.com>
Organization: MontaVista Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
MIME-Version: 1.0
To: "Amit S. Kale" <amitkale@emsyssoft.com>
CC: Andrew Morton <akpm@osdl.org>, jim.houston@comcast.net, discuss@x86-64.org,
       ak@suse.de, shivaram.upadhyayula@wipro.com,
       lkml <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [discuss] Re: kgdb for x86_64 2.6 kernels
References: <000e01c3d476$2ebe03a0$4008720a@shivram.wipro.com> <200401091031.41493.amitkale@emsyssoft.com> <3FFF2851.4060501@mvista.com> <200401101611.53510.amitkale@emsyssoft.com>
In-Reply-To: <200401101611.53510.amitkale@emsyssoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4395
Lines: 114

Amit S. Kale wrote:
> George,
> 
> Well said!
> 
> I have released kgdb 2.0.1 for kernel 2.6.1:
> http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
> 
> It doesn't contain any assert stuff. I have split it into multiple parts to 
> make a merge easier. Please let me know if you want me to further split them 
> or if you want something to be changed. The README file from this tarball is 
> pasted below.
> 
> Here is two possible starting points:
> 1. SMP stuff -> Replace my old smp and nmi handling code.
> 2. Early boot -> Change 8250.patch to make configuration of serial port either 
> through config options or through command line.

What does messing with 8250.c code buy us?  I use a completely independent UART 
driver and only have "back off" code in the 8250 driver.  In fact, I usually 
recommend that the serial (i.e. 8250.c) driver not even be loaded.  My code also 
allows a more aggressive hookup to the interrupt code, to get the ^C to do its 
thing.  I REALLY would like to keep Mr. Heisenberg out of kgdb.  By using 
existing kernel code we are inviting him to visit.
> 
> I'll attempt reading your patch and merging as much stuff as possible.
> Thanks.

May I suggest reading the comments preceeding the patch itself in Andrew's 
breakout code.  These were written by Ingo and, I think, reflect some of the 
things he found useful.

Also, the information found in .../Documentation/i386/kgdb/* of the patch.


> 
> Patch:
> ------
> Patch the kernel out of following patches.
> core.patch -	KGDB architecture and interface independent code. Required.
> i386.patch -	i386 architecture dependent part. Required only for that
> 		architecture.
> x86_64.patch -	x86_64 architecture dependent part. Required only for that
> 		architecture.
> 8250.patch -	Generic serial port (8250 and 16550) interface for kgdb. This
> 		is the only working interface in this release. Hence required.
> eth.patch -	Ethernet interface for kgdb. This is still under development.
> 		Use only if you plan to contribute to its development.
> 
> Build:
> ------
> Enable following config options (in this order).
> 
> Kernel hacking ->
> 	KGDB: kernel debugging with remote gdb ->
> 		KGDB: Thread analysis
> 		KGDB: Console messages through gdb
> Device drivers ->
> 	Character devices ->
> 		Serial drivers ->
> 			KGDB: On generic serial port (8250)
If KGDB is on, this should not be needed.  Also the driver part of KGDB should 
be local to the KGDB configure in the configure file.  I think we should ALWAYS 
have the serial link.  The eth link should be backed up by the serial link.

By the way, I will be out of town on Monday, back on Tuesday.

George

> 	
> Boot:
> -----
> Supply command line options kgdbwait and kgdb8250 to the kernel.
> Example:  kgdbwait kgdb8250=1,115200
> 
> On Saturday 10 Jan 2004 3:46 am, George Anzinger wrote:
> 
>>Amit,
>>
>>The base line kgdb code in the mm patches was offered by me.  It derives
>>from (a long time ago) a kgdb I got from the RTIA (or was it the RTLINUX)
>>folks.  Prio to that, well, your name is on it as well as others.
>>
>>As you may have noted there have been a lot of changes, mostly for the
>>better, I hope.  I think we have slightly different objectives in our work.
>> I debug kernels, not drivers, so I am interested in getting into kgdb as
>>early as possible.  To this end the current mm patch allows one to put a
>>breakpoint() as the first line of C code in the kernel.  This required a
>>few adjustments, such as configuring the I/O port at CONFIG time, for
>>example.
>>
>>I would like for the two versions of kgdb to merge while keeping the
>>features of both.  The work on seperating the common code is something I
>>like and, while I never do modules, the automatic module stuff in gdb sound
>>good.
>>
>>May I suggest that we compare and contrast the two versions and take a look
>>at the differences and the overlaps and settle on one way of doing the
>>various things.
>>
>>George
> 
> 

-- 
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

-
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/