Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger <george@mvista.com>]

Amit S. Kale wrote:
> 8250.patch changes generic 8250/16550 driver behavior only in following ways
> 1. It adds a function serial8250_release_irq to release those serial ports 
> which share an irq with kgdb irq.
> 2. There are checks so that a serial port that uses an irq used by an 
> initialized kgdb can't be initialized or started.
> 
> File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on KGDB_8250 and 
> 8250.c depends on SERIAL_8250 which can be independently configured. 
> kgdb_8250.c can be compiled even if 8250.c is not included. kgdb_8250.c does 
> only the _minimum_ set of initializations required by hardware.

Ok.
> 
> Serial interface should be configurable independent of kgdb and may not be 
> configured if ethernet interface is configured.  Serial interface is far 
> simpler hence superior for debugging purposes. If it's available, using 
> ethernet interface is out of question. Ethernet interface can be used when 
> serial hardware isn't present or is being used for some other purposes.
> 
I rather think that the serial inteface should be the fall back unless the user 
has told us at configure time that it is not available.  I am not prepared to 
make a statment that it is better than eth.  The eth intface should be much 
faster, but it has its fingers into a large part of the kernel that MAY be the 
subject of the current session.  Thus, I think that eth may be better, IF one is 
clearly not involved in debugging those areas of the kernel.  (Which, by the 
way, we need to enumerate at some point.)

> On Monday 12 Jan 2004 11:30 am, George Anzinger wrote:
> 
>>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