Message-ID: <BANLkTi=BQVjXRLNxiCU0xaYrDShtRgiC6Q@mail.gmail.com>
Date:	Fri, 8 Apr 2011 16:25:28 +0800
From:	Hui Zhu <teawater@...il.com>
To:	Dongdong Deng <libfetion@...il.com>
Cc:	Jason Wessel <jason.wessel@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org,
	Marc Khouzam <marc.khouzam@...csson.com>,
	Thiago Jung Bauermann <thiago.bauermann@...il.com>,
	Steven <mqyoung@...il.com>, colyli@...il.com,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: KGTP (Linux Kernel debugger and tracer) 20110405 release

After a discussion with Dongdong, I think I have different idea with that.

1. I don't want change the current interface of kgtp.  Because a proc
interface is very simple and stable interface.
And with proc, kgtp can very easy connect with GDB without Kernel
help.  Please see
https://code.google.com/p/kgtp/wiki/HOWTO#Make_GDB_connect_to_gtp and
https://code.google.com/p/kgtp/wiki/HOWTO#Offline_debug

2. I don't want remove the kprobe.  Because what I want kgtp is to be
a Linux Kernel tracepoint interface with gdb.  I will add other
tracepoint like TRACE_EVENT.
And move it to gdb breakpoint is too far away from it.  And it is too
much depend on kgdb.

Of course, I am very happy to share the GDB rsp tracepoint parse code
with kgdb to make it support gdb tracepoint.
Trust me, My code is more clear than the doc of GDB.  :)

Thanks,
Hui

On Fri, Apr 8, 2011 at 15:58, Hui Zhu <teawater@...il.com> wrote:
> On Fri, Apr 8, 2011 at 14:41, Dongdong Deng <libfetion@...il.com> wrote:
>> On Fri, Apr 8, 2011 at 1:36 PM, Hui Zhu <teawater@...il.com> wrote:
>>> On Wed, Apr 6, 2011 at 16:19, Peter Zijlstra <peterz@...radead.org> wrote:
>>>> On Wed, 2011-04-06 at 13:54 +0800, Hui Zhu wrote:
>>>>
>>>>> This is a good question.
>>>>>
>>>>> The KGTP is completely different with KGDB.  It will not supply simple
>>>>> gdbrsp debug interface to user.  It just supply  interface between the
>>>>> kernel tracepoint(Now, just support kprobe, will add others later) and
>>>>> GDB tracepoint function.
>>>>>
>>>>> So user can debug and trace Linux kernel with GDB without stop the
>>>>> Linux Kernel (So the GDB can running on this Kernel).  It is a trace
>>>>> tools and debug tools.
>>>>
>>>> But this isn't really an answer either. Could you extend the existing
>>>> KGDB infrastructure to provide these features and thereby re-use
>>>> existing infrastructure to reduce your patch size and code duplication?
>>>>
>>>> Jason (the KGDB maintainer) certainly thought there was much possibility
>>>> there when I spoke to him yesterday.
>>>>
>>>> Think of it this way, wouldn't it be much better if there was one tool
>>>> that could provide the combined feature set of KGDB and KGTP?
>>>>
>>>
>>> Thanks Peter.  I think it is very good.
>>>
>>> Which part do you think kgtp can share with kgdb?
>>
>>
>> The main realizing of "kgtp" was based on the sub protocol
>> 'Tracepoint-Packets' of 'gdb Remote Serial Protocol'.
>>
>> http://sourceware.org/gdb/current/onlinedocs/gdb/Tracepoint-Packets.html#Tracepoint-Packets
>>
>> and kgdb have realized most of gdb remote serial protocols.
>>
>>
>> thus the protocol 'Tracepoint-Packets' implement of kgtp could share
>> with kgdb, and the breakpoint handler could follow kgdb's from kprobe,
>>
>> the offline gdb operate interface(an kernel inside gdbserver for gdb)
>> could realize a module like "kgdbts" module implement
>> (linux-2.6/drivers/misc/kgdbts.c).
>>
>> Thanks,
>> Dongdong
>>
>
> Cool.  Wish someone can do that.
>
> Thanks,
> Hui
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists