From: George Anzinger <george@mvista.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@zip.com.au>,
"Amit S. Kale" <amitkale@emsyssoft.com>
Subject: Re: kgdb cleanups
Date: Sun, 11 Jan 2004 21:41:57 -0800 [thread overview]
Message-ID: <400233A5.8080505@mvista.com> (raw)
In-Reply-To: <20040110175607.GH18208@waste.org>
Matt Mackall wrote:
> On Sat, Jan 10, 2004 at 12:12:06AM -0800, George Anzinger wrote:
>
>>Matt Mackall wrote:
>>
>>>On Fri, Jan 09, 2004 at 01:54:12PM -0800, George Anzinger wrote:
>>>
>>>
>>>>Pavel Machek wrote:
>>>>
>>>>
>>>>>Hi!
>>>>>
>>>>>No real code changes, but cleanups all over the place. What about
>>>>>applying?
>>>>>
>>>>>Ouch and arch-dependend code is moved to kernel/kgdb.c. I'll probably
>>>>>do x86-64 version so that is rather important.
>>>>>
>>>>> Pavel
>>>>
>>>>A few comments:
>>>>
>>>>I like the code seperation. Does it follow what Amit is doing? It would
>>>>be nice if Amit's version and this one could come together around this.
>>>>
>>>>I don't think we want to merge the eth and regular kgdb just yet. I
>>>>would, however, like to keep eth completly out of the stub. Possibly a
>>>>new module which just takes care of steering the I/O to the correct place.
>>>
>>>
>>>I've sent Amit the start of an plug interface for abstracting the
>>>communication layer. Should be relatively painless and allow for
>>>starting sessions on the interface of your choice.
>>>
>>
>>May I see?
A few comments:
First, I would like to keep kgdb.h for the user of kgdb so that it may be
included without concern most anywhere. In this light I think it should only
contain the breakpoint macro and the timestamp macro stuff, i.e. those things
that a user might want to put in his code.
For the internal kgdb stuff I have created kdgb_local.h which I intended to be
local to the workings of kgdb and not to contain anything a user would need.
Other comments below.
>
>
> Here's the interface plus the eth side of it:
>
> tiny-mpm/arch/i386/kernel/kgdb_stub.c | 59 +++++++++-------------------------
> tiny-mpm/drivers/net/kgdb_eth.c | 26 +++++++++-----
> tiny-mpm/include/asm-i386/kgdb.h | 14 +++++---
> 3 files changed, 44 insertions(+), 55 deletions(-)
>
> diff -puN include/asm-i386/kgdb.h~kgdb-plug include/asm-i386/kgdb.h
> --- tiny/include/asm-i386/kgdb.h~kgdb-plug 2003-12-27 12:18:47.000000000 -0600
> +++ tiny-mpm/include/asm-i386/kgdb.h 2003-12-27 13:19:16.000000000 -0600
> @@ -19,13 +19,19 @@ extern void breakpoint(void);
> #define BREAKPOINT asm(" int $3")
> #endif
>
> +struct kgdb_hook {
> + char *sendbuf;
> + int maxsend;
I don't see the need of maxsend, or sendbuff, for that matter, as kgdb uses it
now (for the eth code) it is redundant, in that the eth putchar also does the
same thing as is being done in the kgdb_stub.c code. I think this should be
removed from the stub and the limit in the ethcode relied upon.
> + int (*getchar)(void);
> + void (*putchar)(int chr);
> + void (*flush)(void);
> + void (*trap)(int enable);
> +};
> +
> +extern void kgdb_attach(struct kgdb_hook *hook);
> extern void kgdb_schedule_breakpoint(void);
> extern void kgdb_process_breakpoint(void);
>
> -extern int kgdb_tty_hook(void);
> -extern int kgdb_eth_hook(void);
> -extern int kgdboe;
> -
> /*
> * GDB debug stub (or any debug stub) can point the 'linux_debug_hook'
> * pointer to its routine and it will be entered as the first thing
> diff -puN arch/i386/kernel/kgdb_stub.c~kgdb-plug arch/i386/kernel/kgdb_stub.c
> --- tiny/arch/i386/kernel/kgdb_stub.c~kgdb-plug 2003-12-27 12:18:47.000000000 -0600
> +++ tiny-mpm/arch/i386/kernel/kgdb_stub.c 2003-12-27 13:19:19.000000000 -0600
> @@ -130,12 +130,7 @@ typedef void (*Function) (void); /* poin
> /* Thread reference */
> typedef unsigned char threadref[8];
>
> -extern int tty_putDebugChar(int); /* write a single character */
> -extern int tty_getDebugChar(void); /* read and return a single char */
> -extern void tty_flushDebugChar(void); /* flush pending characters */
> -extern int eth_putDebugChar(int); /* write a single character */
> -extern int eth_getDebugChar(void); /* read and return a single char */
> -extern void eth_flushDebugChar(void); /* flush pending characters */
> +struct kgdb_hook *kh = 0;
>
> /************************************************************************/
> /* BUFMAX defines the maximum number of characters in inbound/outbound buffers*/
> @@ -275,39 +270,25 @@ malloc(int size)
> }
> }
>
> -/*
> - * I/O dispatch functions...
> - * Based upon kgdboe, either call the ethernet
> - * handler or the serial one..
> - */
> void
> putDebugChar(int c)
> {
> - if (!kgdboe) {
> - tty_putDebugChar(c);
> - } else {
> - eth_putDebugChar(c);
> - }
> + if (kh)
> + kh->putchar(c);
> }
I was thinking that this might read something like:
if (xxx[kh].putchar(c))
xxx[kh].putchar(c);
One might further want to do something like:
if (!xxx[kh].putchar(c))
kh = 0;
In otherwords, an array (xxx must, of course, be renamed) of stuct kgdb_hook
(which name should also be changed to relate to I/O, kgdb_IO_hook, for example).
Then reserve entry 0 for the rs232 I/O code. An alternate possibility is an
array of pointer to struct kgdb_hook which allows one to define the struct
contents as below and to build the array, all at compile/link time. A legal
entry MUST define get and put, but why not define them all, using dummy
functions for the ones that make no sense in a particular interface.
I also think the functions that kgdb_stub calls should be putDebugChar and
friends, not the underlying functions. I.e. move these out of kgdb_stub.c to a
new common module. This would make it easy for other archs to use, as they
would be using something that looks very much like what they do today. So, in
short, kdgd_stub.c needs to know nothing of kh or the structure it references.
I would also like to see the index (kh in my code) in the kgdb_info structure so
that the user can examine it. I am not sure if I want to allow him to change
it, but I have considered it.
>
> int
> getDebugChar(void)
> {
> - if (!kgdboe) {
> - return tty_getDebugChar();
> - } else {
> - return eth_getDebugChar();
> - }
> + if (kh)
> + return kh->getchar();
> }
>
> void
> flushDebugChar(void)
> {
> - if (!kgdboe) {
> - tty_flushDebugChar();
> - } else {
> - eth_flushDebugChar();
> - }
> + if (kh)
> + kh->flush();
> }
>
> /*
> @@ -490,7 +471,7 @@ putpacket(char *buffer)
>
> /* $<packet info>#<checksum>. */
>
> - if (!kgdboe) {
> + if (kh && !kh->sendbuf) {
> do {
> if (remote_debug)
> printk("T:%s\n", buffer);
> @@ -516,10 +497,7 @@ putpacket(char *buffer)
> * We only transfer MAX_SEND_COUNT size bytes each time
> */
>
> -#define MAX_SEND_COUNT 30
> -
> int send_count = 0, i = 0;
> - char send_buf[MAX_SEND_COUNT];
>
> do {
> if (remote_debug)
> @@ -529,21 +507,21 @@ putpacket(char *buffer)
> count = 0;
> send_count = 0;
> while ((ch = buffer[count])) {
> - if (send_count >= MAX_SEND_COUNT) {
> - for(i = 0; i < MAX_SEND_COUNT; i++) {
> - putDebugChar(send_buf[i]);
> + if (send_count >= kh->maxsend) {
> + for(i = 0; i < kh->maxsend; i++) {
> + putDebugChar(kh->sendbuf[i]);
> }
As I observed above, the eth code already does all this. This code is redundant
and should be removed.
> flushDebugChar();
> send_count = 0;
> } else {
> - send_buf[send_count] = ch;
> + kh->sendbuf[send_count] = ch;
> checksum += ch;
> count ++;
> send_count++;
> }
> }
> for(i = 0; i < send_count; i++)
> - putDebugChar(send_buf[i]);
> + putDebugChar(kh->sendbuf[i]);
> putDebugChar('#');
> putDebugChar(hexchars[checksum >> 4]);
> putDebugChar(hexchars[checksum % 16]);
> @@ -1272,12 +1250,9 @@ kgdb_handle_exception(int exceptionVecto
> print_regs(®s);
> return (0);
> }
> - /*
> - * If we're using eth mode, set the 'mode' in the netdevice.
> - */
>
> - if (kgdboe)
> - netpoll_set_trap(1);
> + if (kh)
> + kh->trap(1);
>
> kgdb_local_irq_save(flags);
>
> @@ -1727,8 +1702,8 @@ kgdb_handle_exception(int exceptionVecto
> }
> }
>
> - if (kgdboe)
> - netpoll_set_trap(0);
> + if(kh)
> + kh->trap(0);
>
> correct_hw_break();
> asm volatile ("movl %0, %%db6\n"::"r" (0));
> diff -puN arch/i386/lib/kgdb_serial.c~kgdb-plug arch/i386/lib/kgdb_serial.c
> diff -puN drivers/net/kgdb_eth.c~kgdb-plug drivers/net/kgdb_eth.c
> --- tiny/drivers/net/kgdb_eth.c~kgdb-plug 2003-12-27 12:18:47.000000000 -0600
> +++ tiny-mpm/drivers/net/kgdb_eth.c 2003-12-27 13:19:18.000000000 -0600
> @@ -34,8 +34,6 @@ static int in_head, in_tail, out_count;
> static atomic_t in_count;
> int kgdboe = 0; /* Default to tty mode */
>
> -extern void set_debug_traps(void);
> -extern void breakpoint(void);
> static void rx_hook(struct netpoll *np, int port, char *msg, int len);
>
> static struct netpoll np = {
> @@ -47,7 +45,7 @@ static struct netpoll np = {
> .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
> };
>
> -int eth_getDebugChar(void)
> +static int getchar(void)
> {
> int chr;
>
> @@ -60,7 +58,7 @@ int eth_getDebugChar(void)
> return chr;
> }
>
> -void eth_flushDebugChar(void)
> +static void flush(void)
> {
> if(out_count && np.dev) {
> netpoll_send_udp(&np, out_buf, out_count);
> @@ -68,13 +66,24 @@ void eth_flushDebugChar(void)
> }
> }
>
> -void eth_putDebugChar(int chr)
> +static void putchar(int chr)
> {
> out_buf[out_count++] = chr;
> if(out_count == OUT_BUF_SIZE)
> eth_flushDebugChar();
> }
>
> +#define MAX_SEND 30
> +char sendbuf[MAX_SEND];
> +static struct kgdb_hook kh = {
> + .sendbuf = sendbuf,
> + .maxsend = MAX_SEND
> + .getchar = getchar,
> + .putchar = putchar,
> + .flush = flush,
> + .trap = netpoll_set_trap
> +};
> +
> static void rx_hook(struct netpoll *np, int port, char *msg, int len)
> {
> int i;
> @@ -82,8 +91,10 @@ static void rx_hook(struct netpoll *np,
> np->remote_port = port;
>
> /* Is this gdb trying to attach? */
> - if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8))
> + if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8)) {
> + kgdb_attach(kh);
> kgdb_schedule_breakpoint();
> + }
>
> for (i = 0; i < len; i++) {
> if (msg[i] == 3)
> @@ -117,12 +128,9 @@ static int init_kgdboe(void)
> }
> #endif
>
> - set_debug_traps();
> -
> if(!np.remote_ip || netpoll_setup(&np))
> return 1;
>
> - kgdboe = 1;
> printk(KERN_INFO "kgdb: debugging over ethernet enabled\n");
>
> return 0;
>
> _
>
>
--
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
next prev parent reply other threads:[~2004-01-12 5:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 18:38 kgdb cleanups Pavel Machek
2004-01-09 21:41 ` Andrew Morton
2004-01-09 21:54 ` George Anzinger
2004-01-10 4:47 ` Matt Mackall
2004-01-10 8:12 ` George Anzinger
2004-01-10 17:56 ` Matt Mackall
2004-01-10 19:34 ` Pavel Machek
2004-01-10 19:37 ` Matt Mackall
2004-01-12 5:41 ` George Anzinger [this message]
2004-01-12 6:49 ` Matt Mackall
2004-01-12 9:45 ` Pavel Machek
2004-01-13 20:54 ` George Anzinger
2004-01-13 21:00 ` Pavel Machek
2004-01-12 13:53 ` Amit S. Kale
2004-01-13 21:20 ` George Anzinger
2004-01-14 13:20 ` Amit S. Kale
2004-01-14 20:40 ` George Anzinger
2004-01-13 20:53 ` George Anzinger
2004-01-14 13:04 ` Amit S. Kale
2004-01-14 20:35 ` George Anzinger
2004-01-10 15:15 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2003-12-28 14:13 Pavel Machek
2003-12-28 20:14 ` Robert Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=400233A5.8080505@mvista.com \
--to=george@mvista.com \
--cc=akpm@zip.com.au \
--cc=amitkale@emsyssoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox