> Well, it's "necessary" for libc post-mips64, but I don't think anyone
> will terribly scream if their not-currently-working libc remains the same.
>
> Old (4.0) userland works just fine even without that fix.
sounds like we don't have to bother about fixing the recently
broken stuff then. goo
On Nov 25, 2010, at 2:20 PM, Simon Burge wrote:
> Matt Thomas wrote:
>
>> On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
>>
>>> On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
but shouldn't we fix stub first, then discuss pros and blah of the change?
Current binaries have
[ adding cc: tech-kern@ ]
hi,
> On Wed, Nov 24, 2010 at 11:26:39PM -0800, Matt Thomas wrote:
>>
>> On Nov 24, 2010, at 10:47 PM, Masao Uebayashi wrote:
>>
>> > On Thu, Nov 25, 2010 at 05:44:21AM +, YAMAMOTO Takashi wrote:
>> >> hi,
>> >>
>> >>> On Thu, Nov 25, 2010 at 04:18:25AM +, YAM
Matt Thomas wrote:
> On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
>
> > On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
> >> but shouldn't we fix stub first, then discuss pros and blah of the change?
> >> Current binaries have not worked at all on MIPS1 since the last December.
> >
On Thursday 25 November 2010 04:45:31 Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Thu Nov 25 04:45:30 UTC 2010
>
> Modified Files:
> src/sys/uvm: uvm_page.c uvm_page.h uvm_pglist.c
>
> Log Message:
> Revert vm_physseg allocation changes. A report say
> Please don't. I've changed the mips1 syscall handler to save t0-t2
> just like the mips3+ handler does.
What about brk.S?
---
Izumi Tsutsui
On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
> On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
>> but shouldn't we fix stub first, then discuss pros and blah of the change?
>> Current binaries have not worked at all on MIPS1 since the last December.
>
> Like I said, I don't have s
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
> but shouldn't we fix stub first, then discuss pros and blah of the change?
> Current binaries have not worked at all on MIPS1 since the last December.
Like I said, I don't have strong feelings about this.
If you want to fix stubs, go fo
> brk:
> syscall
> la t0 _C_LABEL
> sw v0 0(t0)
>
> and the new one:
>
> brk:
> la t0 _C_LABEL
> syscall
> sw v0 0(t0)
sbrk.S is that case:
http://cvsweb.NetBSD.org/bsdweb.cgi/src/lib/libc/arch/mips/sys/sbrk.S.diff?r1=1.16&r2=1.17
---
- lw v1, _C_LABEL(__curbrk)
+
> Actually, I'm not sure on "for sure". If we define the kernel to
> retain t regs over syscall, there is no need to touch the syscall stubs.
> The problem is essentially that the old stub did this:
>
> brk:
> syscall
> la t0 _C_LABEL
> sw v0 0(t0)
>
> and the new one:
>
> brk:
> la t
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote:
>
> > > --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
> > > +++ locore_mips1.S 25 Nov 2010 14:15:39 -
> > > @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
> > > sw a3, FRAME_A3(k1)
> > >
> > > --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
> > > +++ locore_mips1.S 25 Nov 2010 14:15:39 -
> > > @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
> > > sw a3, FRAME_A3(k1)
> > > lw a0, CPUVAR(CURLWP) # 1st arg is cu
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote:
>
> > > --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
> > > +++ locore_mips1.S 25 Nov 2010 14:15:39 -
> > > @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
> > > sw a3, FRAME_A3(k1)
> > >
On Thu Nov 25 2010 at 23:39:03 +0900, Izumi Tsutsui wrote:
> > One remaining problem (which was debugged by Alessandro Forin) is that
> > the post-mips64 brk/sbrk syscall stubs depend on "syscall" retaining t0,
> > and the kernel doesn't do that. I have this in my local tree and it makes
> > a mip
> > --- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
> > +++ locore_mips1.S 25 Nov 2010 14:15:39 -
> > @@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
> > sw a3, FRAME_A3(k1)
> > lw a0, CPUVAR(CURLWP) # 1st arg is curlwp
> >
> On Thu Nov 25 2010 at 14:05:28 +, Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: tsutsui
> > Date: Thu Nov 25 14:05:28 UTC 2010
> >
> > Modified Files:
> > src/sys/arch/pmax/stand/common: startprog.S
> >
> > Log Message:
> > Fix botch on mips64 me
On Thu Nov 25 2010 at 14:05:28 +, Izumi Tsutsui wrote:
> Module Name: src
> Committed By: tsutsui
> Date: Thu Nov 25 14:05:28 UTC 2010
>
> Modified Files:
> src/sys/arch/pmax/stand/common: startprog.S
>
> Log Message:
> Fix botch on mips64 merge:
> - use correct offsets to pas
> Now NetBSD/pmax kernel properly boots, but init(8) still doesn't start
> on GXemul emulating R3000 3MAX.
GXemul's trace shows it's in infinite loop of uvm_fault():
---
:
<_splset_noprof(0xfc01,0x0,"PATH_LOCALE",0x7ded1044,..)>
On Wed, Nov 24, 2010 at 11:26:39PM -0800, Matt Thomas wrote:
>
> On Nov 24, 2010, at 10:47 PM, Masao Uebayashi wrote:
>
> > On Thu, Nov 25, 2010 at 05:44:21AM +, YAMAMOTO Takashi wrote:
> >> hi,
> >>
> >>> On Thu, Nov 25, 2010 at 04:18:25AM +, YAMAMOTO Takashi wrote:
> hi,
>
>
19 matches
Mail list logo
