On Tue, Nov 18, 2003 at 11:28:34AM +0100, Matthias Drochner wrote:
> 
> david@l8s.co.uk said:
> > I wonder if kdump understands the xxx_32 emulations at all??? 
> 
> This remembers me of something.
> There is some confusion between use of sy_narg and sy_argsize
> in the ktrace code. (If you ask me, sy_narg should be nuked completely
> because it is worthless where 32-bit and 64-bit arguments are mixed,
> eg off_t on 32-bit platforms. See my change to kern_ktrace.c rev. 1.76.)

yes - totally borked!

> The svr4_32 emulation code actually deals with conversion of a 32-bit
> argument list into the 64-bit list understood by ktrsyscall(), see
> sparc64/trap.c around line 2116. The problem is that this conversion
> effectively doubles the size of the argument list, while ktrsyscall()
> only expects sy_argsize==sizeof(struct netbsd32_xxx_args) and leaves
> the other half uninitialized.
> sy_nargs callot be used reasonably, as said, so probably the best solution
> is to set up a ktrsyscall32() somewhere in sys/compat.

Or just modify kdump, it keeps track of the processes emulation, so could
easily be modified to explode the arguments from 32 -> 64 bits itself.

This whole kfarce interface is badly designed anyway.  Someone
definitely needs to go through ktrace.h and use fixed size types
before we have a system where int is 64 bits.  There is already a pad
field that got introduced when pid_t when to 32bits.

I will shortly commit a kdump that won't explode when the ioctl argument
list is too short.

	David

-- 
David Laight: david@l8s.co.uk