Hello,
seems I really don't understand much presently.
The p9p install(1) says:
Once the system is built for the first time, it can be maintained and
rebuilt using mk(1). To rebuild individual commands or libraries, run
mk install and mk clean in the appropriate source directory (see
src(1))
2011/1/22 Rudolf Sykora :
> Hello,
>
> seems I really don't understand much presently.
>
> The p9p install(1) says:
>
> Once the system is built for the first time, it can be maintained and
> rebuilt using mk(1). To rebuild individual commands or libraries, run
> mk install and mk clean in the
On Sat, 22 Jan 2011 17:10:11 +0100 Rudolf Sykora
wrote:
>
> I use hg. So from time to time I do 'hg pull -u'. Now, it seems to be
> always safe to run ./INSTALL from the top directory. This, however,
> seems to build everything over again, probably unnecessarily. I
> thought I'd call sth like '
For those of you who showed interest in the jtag, it is finished now
(still beta, though). It fully supports acid (and some). You can
stop a kernel (directly, via breakpoints or catching interrupts),
look at its memory, change it, change its registers...
Looking for testers, it is in contrib/paurea
Setting NPROC to a reasonable number with cause mk to build n targets at
once. I set NPROC to 8 (the number of threads my cpu has) and p9p rebuilds
in less than 5 minutes.
> cd $PLAN9/src
> 9 mk all && 9 mk install
I'll try this.
Thanks
Ruda
This started to look like a 32/64 problem and I think it is. If you
trace the cmpswap, at some point we see 1 as a value, just
like somebody added 1 to , and it went to, not 0, as expected,
but a bigger value.
See this code:
long
syssemacquire(uint32 *arg)
{
int block;
> And note how the u32int is actually converted to a pointer to a long,
> which is 64 bits. I put a panic in there on sizeof(*addr) !=
> sizeof(*arg) and bang! away we go.
>
> So it's a 32/64 bit cleanliness problem. And it's not just for go,
> it's for everything.
>
> This is a huge problem as p
On Sat, Jan 22, 2011 at 6:48 PM, erik quanstrom wrote:
> the plan 9 core needs to religiously use uintptr and not long. long
> is always wrong for these things.
It's a bit messier than that. When 9vx is built as 64-bit, it's a
64-bit kernel supporting 32-bit binaries. uintptr is still a 64-bit
> It's a bit messier than that. When 9vx is built as 64-bit, it's a
> 64-bit kernel supporting 32-bit binaries. uintptr is still a 64-bit
> entity. There's no way to take a 32-bit reference parameter as used in
> semacquire and treat it as a pointer to a 64-bit item and have it end
> well ...
righ
10 matches
Mail list logo
