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.


Eduardo