> Cool. It's been on my list to look into exposing those features
> somehow. I hadn't planned on doing it until after the utrace stuff
> settles and there is a more coherent interface context in which to do
> it.
I'm looking very much forward to utrace. From what I read so far, this is
a much nicer interface.
I would expect that this feature, together with all other ptrace extensions,
would need to be adapted to utrace, once that is in.
> If they are tackling the MSR hacking and context switch and so forth,
> I'd like to see them start out by just adding block-step
> (debugctlmsr.btf) with the PTRACE_SINGLEBLOCK interface as ia64 has.
> That should lay some of the same groundwork needed here, but is much
> simpler.
There seems to be support for block stepping in arch/x86/kernel/step.c,
which is used by kernel/ptrace.c.
This is now another user for the DEBUGCTL MSR; the access needs to be
synchronized. I'll look into it.
> I am not really in favor of this new ptrace interface. I think they
> should look around across arch's and think about sane general-purpose
> interfaces for features of this kind that might be built with some
> commonality across machines.
I looked at the include/asm-*/ptrace.h files and some arch/*/kernel/ptrace.c
files. Most arch's support a few variants of GET<whatever>REGS.
Most implementations simply copy_to_user the kernel structures for the
requested registers.
Sparc64 needs to convert pointer sizes and defines the returned struct
directly in the implementation.
Xtensa provides access to an array of FP regs of varying size. They provide
a ptrace command to query for the size, but otherwise also copy_to_user
the entire array.
I have not found any arch that does anything more fancy than return a single
integer value or an array of registers.
In all cases, the command carries enough information to interpret the result.
In our case, the array we're querying for can be rather big and
typically only some
of the information is interesting. The data we return is inhomogeneous.
The former may be true for register arrays as well, but they are
typically small
enough. The latter would compare to a general GETREGS command that returns
all registers in a self-describing format (that might be an
interesting extension, if
one got tired of yet another GET<new-type-of>REGS command).
Instead of providing the entire array in one command, we introduced commands to
handle that array.
Instead of carrying the information how to interpret the result in the
command itself,
we provide that information directly in the result.
I would argue that this interface may be directly (re)used and
extended by other arch's.
Do you have specific concerns regarding the interface?
> Also do it in a layered way from
> low-level, with something usable for kernel-mode too.
To disable cpl0-filtering should be fairly easy; we would simply clear
the cpl-bit
in the debugctl_mask. This way, you can trace the kernel
part of the application, but you would still debug the application.
You could call the ptrace_bts_ functions directly or we might add a new set of
interface functions that simply forward the request (or the other way round).
To provide a per-cpu trace instead of a per-thread trace would be a
completely new
feature that only has the configuration part in common with our patch.
What did you have in mind when you asked for kernel-mode support?
thanks and regards,
markus.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
