Merging 64 bit changes to -HEAD - part 4

[Juli Mallett]

On Fri, Jul 9, 2010 at 14:34, M. Warner Losh <imp at bsdimp.com> wrote:
> In message: <AANLkTimcCqP2SinyKJUqpT9l0j07AqGCLxMCuCGXc2wA at mail.gmail.com>
>            Juli Mallett <jmallett at FreeBSD.org> writes:
> :  *    The value passed in '*virt' is a suggested virtual address for
> :  *    the mapping. Architectures which can support a direct-mapped
> :  *    physical to virtual region can return the appropriate address
> :  *    within that region, leaving '*virt' unchanged. Other
> :  *    architectures should map the pages starting at '*virt' and
> :  *    update '*virt' with the first usable address after the mapped
> :  *    region.
>
> That's rather generic, and on some mips we do a mixed-mode here...

I guess you and I read the word "can" differently wrt mixed-mode :)

> : > : mips-ddb-64.patch (from Juli's branch)
> : > : Minor fixups for ddb support.
> : >
> : > Can you explain the casting for all the calls to kbdpeek*?
> :
> : Yes.  sp is (or should be) a register_t.  You can't go from a
> : register_t to a pointer on n32.  Even if we don't intend to support
> : n32 kernels from head, we shouldn't make n32 harder by using the wrong
> : types without casts :)
>
> True, but can't we redefine these functions such that we don't need
> these great big ugly casts?  They are written in assembler, after all,
> but are specific to mips so the API can change here...

Of course we can change them.  We could change the function to not
take a pointer, but an intptr_t or a register_t, but the latter is
wrong and the former is kind of weird (especially if we spell it as
vm_offset_t, which is more normal for the kernel, since vm_offset_t is
unsigned and blah blah sign extension.)  It may make sense to make the
'sp' on the stack an intptr_t rather than a register_t.  What we
really can't do is keep sp a register_t and pass register_t to kdbpeek
and do the math on sp without a cast to intptr_t, since on n32 that's
extremely incorrect since 64-bit signed integer arithmetic works
differently to 32-bit signed integer arithmetic sign-extended to 64
bits :(