Re: Someone using COMPAT_SVR4(_32) ?
Eduardo Horvath <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 13 Sep 2017, Robert Swindells wrote: > Eduardo Horvath <[email protected]> wrote: > >On Wed, 13 Sep 2017, Jerome Ibanes wrote: > > > >> 6.0.6 sparc64, 6.1.5 sparc64, 7.1 sparc64 (all GENERIC), fail with the same > >> behavior (meaning, same ktrace ouput) given the same payload (sparc > >> solaris 2.6), ktrace shows: > >> > >> [...] > >> 1119 1 k CALL mmap(0x2000,0x80000002,0,0x45f,2,0) > >> 1119 1 k RET mmap 1074167808/0x40068000 > >> 1119 1 k PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, > >> addr=0x0, trap=48) > > > >Hm. What binary is this? Solaris 2.6, so that's 32-bits, right? > >That's a really old version. I should know, I got the tee shirt. > > > >Is that on a 32-bit or 64-bit NetBSD kernel? > > > >Compat svr4_32 mmap should be this: > > > >115 STD { netbsd32_voidp|svr4_32_sys||mmap(netbsd32_voidp addr, > > svr4_32_size_t len, int prot, int flags, int fd, > > svr4_32_off_t pos); } > > > >So according to ktrace, it's requesting some huuuuuuge mapping be added at > >address 0x2000 from FD 2. > > Does the emulated mmap() restrict segment sizes to be less than one of > the resource limits, it looks to me as if it does. > > Several Lisp systems have to chop up big allocations into smaller chunks > when running on NetBSD. Don't think that's what's happenning. The mmap() succeeds, it just mapped at the wrong address. Eduardo