Re: CVS commit: src/sys/compat/freebsd
Date:Sat, 6 Apr 2019 10:48:32 -0700 From:Jason Thorpe Message-ID: | The only situation I know of where it's wacky is sparc64-built-as-ILP32 | and mips64-built-as-ILP32, where register_t is 64-bit and long is 32-bit. But that is kind of the point - from qhat I can see from a (very) quick scan, register_t is used almost exclusively for syscall args/results (for which it makes sense) - and those are objects which are likely being copied to/from user space. Just like ufetch_ptr() exists, even though a pointer is almost always the same as an int or a long in terms of number of bits, etc, register_t will essentially always be one or the other - but we never really know which. Unlike most of the other contrived types (size_t, intmax_t, ptrdiff_t) which aren't all that frequently shunted around, register_t is, which is why (just like ptr_t) I believe it would be one which should have its own access functions. But I will leave it for you to decide what is really needed there. kre
Re: CVS commit: src/sys/compat/freebsd
> On Apr 6, 2019, at 10:45 AM, Robert Elz wrote: > > Actually, fetching & storing registers (register_t) is a common enough > thing that it might be worth having ufetch_reg (and ustore_reg), probably > as MD #defines that map into one of the other calls. The only situation I know of where it's wacky is sparc64-built-as-ILP32 and mips64-built-as-ILP32, where register_t is 64-bit and long is 32-bit. -- thorpej
Re: CVS commit: src/sys/compat/freebsd
Actually, fetching & storing registers (register_t) is a common enough thing that it might be worth having ufetch_reg (and ustore_reg), probably as MD #defines that map into one of the other calls. kre
Re: CVS commit: src/sys/compat/freebsd
Date:Sat, 6 Apr 2019 10:30:39 -0700 From:Jason Thorpe Message-ID: <047ba730-614e-46fd-85e2-f501d18f4...@me.com> | This is wrong -- register_t is 64-bit on amd64 ... so u_long | is the better choice of cast. It was wrong anyway, it needs to be an unsigned type (even though code is signed) ... but yes, I will switch it back to the previous version, and we can just hope that this stuff never gets used on a system where long is 64 bits and register_t is 32. kre
