linux-kernel - Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 Dec 2009 12:00:02 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	utrace-devel <utrace-devel@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>
Subject: Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

Hi -

On Tue, Dec 01, 2009 at 05:11:32PM +0100, Ingo Molnar wrote:
> Those facilities are not overlapping with kgdb though so my point doesnt 
> apply to them. An in-kernel gdb server sure overlaps/extends kgdb 
> though.

Only in name.  One is highly invasive, for debugging the kernel across
serial consoles.  The other is highly noninvasive, for debugging user
processes across normal userspace channels.  They both happen to talk
to gdb, but that's the end of the natural "overlap".

Even if kgdb was extended to be able to manage userspace, and if gdb
itself was extended to be able to use that same single channel, this
would still not duplicate the use scenario for an ordinary user
debugging his own processes.

(Plus, in the future where at least gdb is applied toward kernel+user
debugging, it is unlikely to be the case that this would need to be
done *over a single channel*.  A separate channel for kernel and
separate channels for userspace programs are no less likely.)

> Btw., perf does meet that definition: it functionally replaces all 
> facilities that it overlaps/extends - such as Oprofile. [...]

(And they currently separately coexist.)

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