From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2239 Path: news.gmane.org!not-for-mail From: Paul Schutte Newsgroups: gmane.linux.lib.musl.general Subject: Re: A few issues on MIPS Date: Mon, 5 Nov 2012 19:27:44 +0200 Message-ID: References: <20121105152832.GV24157@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33d4cca2248504cdc2cdb7 X-Trace: ger.gmane.org 1352136478 14179 80.91.229.3 (5 Nov 2012 17:27:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2012 17:27:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2240-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 05 18:28:08 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TVQSz-0006NI-TI for gllmg-musl@plane.gmane.org; Mon, 05 Nov 2012 18:28:06 +0100 Original-Received: (qmail 16293 invoked by uid 550); 5 Nov 2012 17:27:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16285 invoked from network); 5 Nov 2012 17:27:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0lHv2N4WYjsZFxfQnNPVFasbvBwTTqksmSOsHEIqw3w=; b=ewhK5oA7RVlxuxldqu99uYtaE1pqakA7i1JO86CAsT3tJ7xp7/gMqjB+2KxN/uQs0H yhmR72D16ViEGNas3HF/qLvxMDIMvTVW7vAUJWM+WzWW5Q+c8f9JQVo+7eVoGx4RSYky eVKvpi1oqq/AnxqauNO/HhKatS7NrvJ38yNxu7M8AXRpZEzySPxmeDck2u+mhYblGajo hnJ5B1EExCOCxOIJSCfSR2rlUF8o9furctx16zTwoIpxe3dGBvrtKtSJnn9ZXFDjDD9q NTLYOh9FcSMT8sAfuGo+pazyFG+awntOhNmDiQpv1FUjyRuhc+6pooJl8AVPp0ojO2Pj 0epg== In-Reply-To: <20121105152832.GV24157@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:2239 Archived-At: --047d7b33d4cca2248504cdc2cdb7 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reply. I suspected something like you mention and therefore I made sure that I installed the correct kernel headers before I compiled musl or any of the other software. It did not seem to make any difference. Regards Paul On Mon, Nov 5, 2012 at 5:28 PM, Szabolcs Nagy wrote: > * Paul Schutte [2012-11-05 16:34:47 +0200]: > > open("/root/file", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3 > > fcntl64(3, F_GETFD) = 0 > > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > > fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > > _llseek(3, 0, [0], SEEK_SET) = 0 > > read(3, "", 100) = 0 > ... > > writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) = 8 > > readv(0, [{"", 0}, > > {".schema\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024}], > 2) > > = 8 > > brk(0x4d6000) = 0x4d6000 > > fcntl64(3, 0xd /* F_??? */, 0x7fc84210) = -1 EINVAL (Invalid argument) > > writev(2, [{"Error: disk I/O error\n", 22}, {NULL, 0}], 2Error: disk I/O > > error > > ) = 22 > > writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) = 8 > > > > i guess the fcntl arguments are broken on mips > > > When using uclibc I do not get the error: > > > > write(1, "sqlite> ", 8sqlite> ) = 8 > > read(0,".schema\n", 4096) = 8 > > brk(0x6d1000) = 0x6d1000 > > fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, > > len=1}, 0x7ff28fd0) = 0 > > one should check the kernel vs musl definition of F_SETLK64 > > > If I compile it on amd64/i386 using musl and the same procedure, I also > do > > not get the problem. > > > > writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) = 8 > > readv(0, [{"", 0}, > > {".schema\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024}], > 2) > > = 8 > > brk(0x1d41000) = 0x1d41000 > > fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, > len=1}) > > = 0 > > > > I also statically compiled mongoose-3.3 and get a different problem > there. > > (Port 8080 is available): > > > > > > execve("./mongoose", ["./mongoose"], [/* 28 vars */]) = 0 > > open("./mongoose.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file > or > > directory) > > rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 16) = 0 > > set_thread_area(0x448974) = 0 > > set_tid_address(0x4418e4) = 16807 > > rt_sigaction(SIGTERM, {0x14000000, [RT_68 RT_69 RT_71 RT_72 RT_80 RT_82 > > RT_87], 0x4002f0 /* SA_??? */}, {SIG_DFL, [RT_68 RT_69 RT_71 RT_72 RT_80 > > RT_82 RT_87], 0}, 16) = 0 > > rt_sigaction(SIGINT, {0x14000000, [RT_68 RT_69 RT_71 RT_72 RT_80 RT_82 > > RT_87], 0x4002f0 /* SA_??? */}, {SIG_DFL, [RT_68 RT_69 RT_71 RT_72 RT_80 > > RT_82 RT_87], 0}, 16) = 0 > > brk(0) = 0x442000 > > brk(0x443000) = 0x443000 > > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > > setsockopt(3, SO_DEBUG, 2, [1], 4) = -1 ENOPROTOOPT (Protocol not > > available) > > seems to be similar issue: SO_DEBUG is probably bogus > > > On a different architecture (amd64) it works: > > > > execve("./mongoose", ["./mongoose"], [/* 39 vars */]) = 0 > > rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0 > > arch_prctl(ARCH_SET_FS, 0x621960) = 0 > > set_tid_address(0x621990) = 9789 > > open("./mongoose.conf", O_RDONLY) = -1 ENOENT (No such file or > > directory) > > rt_sigaction(SIGTERM, {0x4001f4, [], SA_RESTORER|SA_RESTART, 0x418ea8}, > > {SIG_DFL, [], 0}, 8) = 0 > > rt_sigaction(SIGINT, {0x4001f4, [], SA_RESTORER|SA_RESTART, 0x418ea8}, > > {SIG_DFL, [], 0}, 8) = 0 > > brk(0) = 0x1aab000 > > brk(0x1aac000) = 0x1aac000 > > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 > > setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > > > SOL_SOCKET is probably wrongly defined for mips > > --047d7b33d4cca2248504cdc2cdb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the reply.

I suspected something like you men= tion and therefore I made sure that I installed the correct kernel headers = before I compiled musl or any of the other software.

It did not seem to make any difference.

=A0Re= gards
Paul

On Mon, Nov 5, 2012 = at 5:28 PM, Szabolcs Nagy <nsz@port70.net> wrote:
* Paul Schutte <sjpschutte@gmail.com> [2012-11-05 16:34:47 +0200]: > open("/root/file", O_RDWR|O_CREAT|O_LARGEFILE, 0644) =3D 3 > fcntl64(3, F_GETFD) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) =A0 =A0 =A0 =A0 =3D 0
> fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0
> _llseek(3, 0, [0], SEEK_SET) =A0 =A0 =A0 =A0 =A0 =A0=3D 0
> read(3, "", 100) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=3D 0
...
> writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) =3D= 8
> readv(0, [{"", 0},
> {".schema\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"= ..., 1024}], 2)
> =3D 8
> brk(0x4d6000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0x4d6000
> fcntl64(3, 0xd /* F_??? */, 0x7fc84210) =3D -1 EINVAL (Invalid argumen= t)
> writev(2, [{"Error: disk I/O error\n", 22}, {NULL, 0}], 2Err= or: disk I/O
> error
> ) =3D 22
> writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) =3D= 8
>

i guess the fcntl arguments are broken on mips

> When using uclibc I do not get the error:
>
> write(1, "sqlite> ", 8sqlite> ) =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =3D 8
> read(0,".schema\n", 4096) =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 8 > brk(0x6d1000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0x6d1000
> fcntl64(3, F_SETLK64, {type=3DF_RDLCK, whence=3DSEEK_SET, start=3D1073= 741824,
> len=3D1}, 0x7ff28fd0) =3D 0

one should check the kernel vs musl definition of F_SETLK64

> If I compile it on amd64/i386 using musl and the same procedure, I als= o do
> not get the problem.
>
> writev(1, [{"sqlite> ", 8}, {NULL, 0}], 2sqlite> ) =3D= 8
> readv(0, [{"", 0},
> {".schema\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"= ..., 1024}], 2)
> =3D 8
> brk(0x1d41000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D = 0x1d41000
> fcntl(3, F_SETLK, {type=3DF_RDLCK, whence=3DSEEK_SET, start=3D10737418= 24, len=3D1})
> =3D 0


> I also statically compiled mongoose-3.3 and get a different problem th= ere.
> (Port 8080 is available):
>
>
> execve("./mongoose", ["./mongoose"], [/* 28 vars *= /]) =3D 0
> open("./mongoose.conf", O_RDONLY|O_LARGEFILE) =3D -1 ENOENT = (No such file or
> directory)
> rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 16) =3D 0
> set_thread_area(0x448974) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 0
> set_tid_address(0x4418e4) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 16807
> rt_sigaction(SIGTERM, {0x14000000, [RT_68 RT_69 RT_71 RT_72 RT_80 RT_8= 2
> RT_87], 0x4002f0 /* SA_??? */}, {SIG_DFL, [RT_68 RT_69 RT_71 RT_72 RT_= 80
> RT_82 RT_87], 0}, 16) =3D 0
> rt_sigaction(SIGINT, {0x14000000, [RT_68 RT_69 RT_71 RT_72 RT_80 RT_82=
> RT_87], 0x4002f0 /* SA_??? */}, {SIG_DFL, [RT_68 RT_69 RT_71 RT_72 RT_= 80
> RT_82 RT_87], 0}, 16) =3D 0
> brk(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=3D 0x442000
> brk(0x443000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D = 0x443000
> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) =3D 3
> setsockopt(3, SO_DEBUG, 2, [1], 4) =A0 =A0 =A0=3D -1 ENOPROTOOPT (Prot= ocol not
> available)

seems to be similar issue: SO_DEBUG is probably bogus

> On a different architecture (amd64) it works:
>
> execve("./mongoose", ["./mongoose"], [/* 39 vars *= /]) =3D 0
> rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) =3D 0
> arch_prctl(ARCH_SET_FS, 0x621960) =A0 =A0 =A0 =3D 0
> set_tid_address(0x621990) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 9789
> open("./mongoose.conf", O_RDONLY) =A0 =A0 =A0 =3D -1 ENOENT = (No such file or
> directory)
> rt_sigaction(SIGTERM, {0x4001f4, [], SA_RESTORER|SA_RESTART, 0x418ea8}= ,
> {SIG_DFL, [], 0}, 8) =3D 0
> rt_sigaction(SIGINT, {0x4001f4, [], SA_RESTORER|SA_RESTART, 0x418ea8},=
> {SIG_DFL, [], 0}, 8) =3D 0
> brk(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=3D 0x1aab000
> brk(0x1aac000) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D = 0x1aac000
> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) =3D 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) =3D 0


SOL_SOCKET is probably wrongly defined for mips


--047d7b33d4cca2248504cdc2cdb7--