Date: Mon, 12 Jul 2010 11:00:08 +0400 From: pluknet <pluknet@gmail.com> To: Gabor Kovesdan <gabor@freebsd.org> Cc: Dimitry Andric <dimitry@andric.com>, FreeBSD Hackers <hackers@freebsd.org> Subject: Re: strange problem with int64_t variables Message-ID: <AANLkTilqEfe_EL_3ExodMgqfmU-DubIdlRs-5NXXT4dO@mail.gmail.com> In-Reply-To: <4C39DBFF.2000307@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 July 2010 18:58, Gabor Kovesdan <gabor@freebsd.org> wrote: > Em 2010.07.11. 16:54, Dimitry Andric escreveu: >> >> On 2010-07-11 16:46, Gabor Kovesdan wrote: >> >>> >>> I have two int64_t variables in kernel code, first is stored internally >>> and the second one is passed from a syscall argument. When I print them >>> with printf %lld modifier, the internal one behaves correctly but the >>> other one I pass from a syscall has a corrupted value. If I pass 1, it >>> prints out 3735348794091372545. I'm not doing anything special with it >>> just reading it out from the struct that was generated with make sysent= . >>> >> >> Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper >> word got corrupted somehow. =A0Maybe some part of it got non-atomically >> assigned? =A0Maybe the wrong word was read? =A0It is hard to tell withou= t >> code... =A0:) >> > > Userland syscall calling: > > killjob(getjid(), SIGINT); =A0//getjid() returns 1 this case, whose type = is > jid_t > Looking at getjid() impl, I see you're trying to put jid_t into the one register_t which are 64-bit vs 32-bit capable respectively. You need to cast so you put 64-bit into two 32-bit as done for e.g. lseek()= . --=20 wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilqEfe_EL_3ExodMgqfmU-DubIdlRs-5NXXT4dO>