Subject: Re: port-sparc64/23473: kdump dumps core on sparc64/compat_svr4
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: David Laight <email@example.com>
Date: 11/18/2003 11:41:38
On Tue, Nov 18, 2003 at 11:28:34AM +0100, Matthias Drochner wrote:
> firstname.lastname@example.org 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 Laight: email@example.com