Re: Someone using COMPAT_SVR4(_32) ?

[Jerome Ibanes <jibanes%gmail.com@localhost>]

Here is the ktrace/kdump under 5.2.3 sparc64 and 7.1 sparc64, both running
GENERIC with the same sparc solaris 2.6 32-bits payload, the same binary is
being used.

5.2.3:
[...]
   463      1 k        NAMI  "/emul/svr4_32/usr/lib/libX11.so.4"
   463      1 k        RET   open 4
   463      1 k        CALL  fstat(4,0xffffd83c)
   463      1 k        RET   fstat 0, 4294957116/0xffffd83c
   463      1 k        CALL  mmap(0,0x2000,5,0x80000002,4,0)
   463      1 k        RET   mmap 1074118656/0x4005c000, 8192/0x2000
   463      1 k        CALL  mmap(0,0x88000,5,0x80000002,4,0)
   463      1 k        RET   mmap 1074135040/0x40060000, 557056/0x88000
   463      1 k        CALL  munmap(0x400d4000,0xe000)
   463      1 k        RET   munmap 0, 57344/0xe000
   463      1 k        CALL  mmap(0x400e2000,0x4d10,7,0x80000012,4,0x72000)
   463      1 k        RET   mmap 1074667520/0x400e2000, 19728/0x4d10
   463      1 k        CALL  close(4)
   463      1 k        RET   close 0, 8192/0x2000
   463      1 k        CALL  open(0x1002b9ac,0,0xffffd8c4)
[...] emulation pursues with no issue.

7.1:
[...]
  1119      1 k        NAMI  "/emul/svr4_32/usr/lib/libX11.so.4"
  1119      1 k        RET   open 4
  1119      1 k        CALL  fstat(0xffffd84c,0x80000002)
  1119      1 k        RET   fstat 0
  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)
  1119      1 k        NAMI  "test.core"

Please note that we observe exactly the same behavior under 6.0.6,
6.1.5, 7.0.2 and 7.1.
The machine has 2GB of ram.


Jerome

On Wed, Sep 13, 2017 at 11:17 AM, Eduardo Horvath <eeh%netbsd.org@localhost> wrote:
> On Wed, 13 Sep 2017, Robert Swindells wrote:
>
>> Eduardo Horvath <eeh%NetBSD.org@localhost> 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