All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Hui Zhu <teawater@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Geoff Levand <geoff@infradead.org>,
	jason.wessel@windriver.com
Subject: Re: [PATCH]KGTP (Linux Kernel debugger and tracer) lite patch for review
Date: Thu, 24 May 2012 17:07:54 +0200	[thread overview]
Message-ID: <20120524150754.GF27374@one.firstfloor.org> (raw)
In-Reply-To: <4FBE3938.30000@gmail.com>

> I remove them from asm files, and add:
> #ifndef ULONGEST
> #define ULONGEST		uint64_t
> #endif
> #ifndef CORE_ADDR
> #define CORE_ADDR		unsigned long
> #endif
> in gtp.c
> Then if not need, the arch didn't define ULONGEST and CORE_ADDR for itself.

Which architecture needs it? Linux prefers to use "native" types.

> For example ARM and MIPS have a lot of special reg that cannot be converted 
> by a for loop.
> 
> After check the code the kgdb, I thought that good ways is use dbg_reg_def 
> of kgdb to convert the reg to gdb rsp format.  But use it directly will 
> make kgtp depend on kgdb.

That's fine. Code reuse is good. Code duplication is bad.

> What I thought is move this part of code out from kgdb, when kgdb or kgtp 
> need, select it too.  But I am not sure Jason is OK with that.

Just send a patch.

> >
> >>+     memcpy(&freg->regs, regs, sizeof(struct pt_regs));
> >>+#ifdef CONFIG_X86_32
> >>+     freg->regs.sp = (unsigned long)&regs->sp;
> >>+#endif       /* CONFIG_X86_32 */
> >>+#ifdef CONFIG_X86
> >>+     freg->regs.ip -= 1;
> >>+#endif       /* CONFIG_X86 */
> >
> >What is that for? - 1?
> 
> That is because when kprobe, the ip of X86 point will have a offset with 
> current ip.

But a kprobe is not necessarily one byte. e.g. a jumper probe is longer.

Anyways if that is really needed there should be some macros provided
by kprobes to adjust IP. If it's not there it needs to be added.
> >>+
> >>+     if (gtp_start)
> >>+             return -EBUSY;
> >
> >This is in a lot of places. Can you put it somewhere more central?
> 
> Sorry I don't understand this part.  Do you want I change all "struct 
> gtp_entry        *tpe;" to "struct gtp_entry *tpe;"?

I mean the if (gtp_start) return -EBUSY check.

> >
> >>+     pr_devel("gtp_gdbrsp_QT: %s\n", pkg);
> >>+
> >>+     if (strcmp("init", pkg) == 0)
> >>+             ret = gtp_gdbrsp_qtinit();
> >
> >This if cascade should be probably a table walk
> 
> I cannot find the examle about it in the Kernel, could you give me a 
> example?


struct cmd {
	char *name;
	int (*init)(void);
};

struct cmd cmds[] = {
	{ "init", gtp_xyz_init }
	...
	{} 
};

int i;
for (i = 0; cmds[i].name; i++)
	if (!strcmp(cmds[i].name, pkg))
		ret = cmds->init();


> >Ok so what lock protects this buffer?
> 
> No.  The gtp_frame_lock protects the vars that follow it:
> static int			gtp_frame_num;
> static char			*gtp_frame;
> static char			*gtp_frame_r_start;
> static char			*gtp_frame_w_start;
> static char			*gtp_frame_w_end;
> static char			*gtp_frame_r_cache;
> static int			gtp_frame_is_circular;
> It protects them all.
> 
> gtp_m_buffer is protected by gtp_rw_lock that I just add in new patch.

Then your comment was wrong/unclear?

> 
> 
> OK.  Add some introduce.  checkpatch is OK with it.

You must be using an old version?

# check for Kconfig help text having a real description
# Only applies when adding the entry originally, after that we do not have
# sufficient context to determine whether it is indeed long enough.
...
        WARN("CONFIG_DESCRIPTION",
                             "please write a paragraph that describes the config symbol fully\n" . $herecurr) if ($is_start && $is_end && $length < 4);

I wonder how you avoided that.

-Andi

  reply	other threads:[~2012-05-24 15:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09  7:14 [PATCH]KGTP (Linux Kernel debugger and tracer) lite patch for review Hui Zhu
2012-05-09 14:05 ` Andi Kleen
2012-05-10 12:15   ` Hui Zhu
2012-05-10 17:38     ` Andi Kleen
2012-05-24 13:35       ` Hui Zhu
2012-05-24 15:07         ` Andi Kleen [this message]
2013-11-21  5:05           ` Hui Zhu

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=20120524150754.GF27374@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=geoff@infradead.org \
    --cc=hch@infradead.org \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=teawater@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.