Subject: Re: netbsd32 vs ktrace/kdump
To: matthew green <email@example.com>
From: Eduardo Horvath <eeh@NetBSD.org>
Date: 01/14/2004 17:15:39
On Wed, Jan 14, 2004 at 03:24:54PM +1100, matthew green wrote:
> i've been looking at fixing up the remaining issues with compat/netbsd32.
> one of them is ktrace/kdump. currently this doesn't work very well.. there
> is little interpretation of arguments, the arguments are wrong in some
> cases anyway, etc..
> i have patches to kdump that allow 32 bit apps on 64 bit kernels to be
> traced - but so far only with the 64 bit kdump. there are multiple cases
> that could be supported but i think something like this should work:
Did that break?
> - 32 bit ktrace should generate 32 bit ktrace.out records
> - 64 bit ktrace should generate 64 bit ktrace.out records
> both of these irrespective of what size the application itself is. this
> is because you'll likely (and this will "force" the case) to be running
> the same sized kdump as ktrace. ie, running 64 bit "ktrace" and then
> 32 bit "kdump" or vice versa will be documented to lose.
I don't think trying to get a 32-bit ktrace/kdump working on 64-bit
kernels is worth the effort. The only real use would be to share
the ktrace output between the 64-bit environment where it was created
and some other 32-bit environment. Attempting to do that gets difficult.
Consider that the ktrace flag is inherited. And every new exec() can
be of a different emulation. You could do:
32-bit ktrace -> 32-bit sh -> 64-bit vi -> 32-bit ls
You now have a mix of traces of 32-bit and 64-bit processes. First
you would need to teach your 32-bit kdump to grok 64-bit ktrace events.
I'm not sure that's possible to generate the correct 64-bit layout
of ioctl() arguments with for a 32-bit kdump.
Second, you need to tag each process with the size of the ktrace being
generated, and modify all the ktr* routines to check that tag and
generate either 32-bit or 64-bit structures. I don't think that code
could be lkm-ified as it will need to be in the base ktrace routines,
although it could be #ifdef-ed.