[OpenWrt-Devel] uClibc bug: epoll_pwait broken on OpenWrt x86
mschiffer at universe-factory.net
Mon Sep 15 11:33:24 EDT 2014
Ping? I'd like to get this fixed as soon as possible (even though it's
probably too late for the OpenWrt BB final?). I guess I can try to write
a patch, but I had hoped someone on these lists could give some advice
on what the best way to fix this would be...
On 09/05/2014 02:15 PM, Matthias Schiffer wrote:
> I've found commit 555ae2e88cd16a83f854634b6c3f35715b11d3d4, which works
> around the issue in the current uClibc master:
>> commit 555ae2e88cd16a83f854634b6c3f35715b11d3d4
>> Author: Natanael Copa <natanael.copa at gmail.com>
>> Date: Thu Jul 5 11:55:19 2012 +0000
>> i386/bits/syscalls.h: allow immediate values as 6th syscall arg
>> Allow use of immedate values as the 6th syscall argument. Otherwise we must
>> store the arg on memory. This gives gcc more options to optimize better.
>> This also works around an issue with posix_fallocate.
> I guess the mentioned issue with posix_fallocate is the same I'm
> experiencing with epoll_pwait.
> Applying this patch to OpenWrt would workaround the issue in this
> particular case, but I don't think relying on compiler behaviour that is
> not guaranteed in any way is a good idea. There are a few cases where
> the 6th syscall argument can't be immediate, so the workaround doesn't
> help; one of these is splice(), which is still broken in the current master.
> I've also attached my .config; for testing I'm using GCC 4.9.1, but as
> mentioned, it also happens on OpenWrt, which uses the 4.6-linaro and
> 4.8-linaro toolchains.
> On 09/01/2014 12:41 PM, Matthias Schiffer wrote:
>> Sure, I've attached my testcase (source and compiled for Barrier Breaker).
>> On 09/01/2014 08:31 AM, Waldemar Brodkorb wrote:
>>> can you provide a simple testcase showing the bug?
>>> best regards
>>>> Am 01.09.2014 um 00:53 schrieb Matthias Schiffer <mschiffer at universe-factory.net>:
>>>> I'm posting this on both the OpenWrt and the uClibc lists to hopefully
>>>> find someone who has an idea how the code in question might ever have
>>>> worked (if it ever has...). The issue probably affects not only
>>>> epoll_pwait, but also other syscall6 on i386. It can be seen on all
>>>> OpenWrt versions ranging from Attitude Adjustment to Barrier Breaker
>>>> (and probably also the current trunk).
>>>> I noticed that epoll_pwait always returns EINVAL when I supply a signal
>>>> set; analzing it with gdb I found out that %ebp contains a stack address
>>>> instead of the length of the signal set (which should be 8).
>>>> Looking at the generated code reveals this:
>>>> 0000b360 <__libc_epoll_pwait>:
>>>> b360: 55 push %ebp
>>>> b361: 57 push %edi
>>>> b362: 56 push %esi
>>>> b363: 53 push %ebx
>>>> b364: 51 push %ecx
>>>> b365: e8 eb ef ff ff call a355 <__x86.get_pc_thunk.bx>
>>>> b36a: 81 c3 8a 4c 04 00 add $0x44c8a,%ebx
>>>> b370: 8b 74 24 24 mov 0x24(%esp),%esi
>>>> b374: 8b 7c 24 28 mov 0x28(%esp),%edi
>>>> b378: c7 04 24 08 00 00 00 movl $0x8,(%esp) #1
>>>> b37f: 65 a1 0c 00 00 00 mov %gs:0xc,%eax
>>>> b385: 85 c0 test %eax,%eax
>>>> b387: 75 33 jne b3bc
>>>> b389: 8b 44 24 18 mov 0x18(%esp),%eax
>>>> b38d: 8b 4c 24 1c mov 0x1c(%esp),%ecx
>>>> b391: 8b 54 24 20 mov 0x20(%esp),%edx
>>>> b395: 53 push %ebx #2
>>>> b396: 89 c3 mov %eax,%ebx
>>>> b398: 55 push %ebp #3
>>>> b399: 8b 2c 24 mov (%esp),%ebp #4
>>>> b39c: b8 3f 01 00 00 mov $0x13f,%eax
>>>> b3a1: cd 80 int $0x80
>>>> As can be seen, the value 8 is moved onto the stack at #1 and is
>>>> supposed to be moved to %ebp at #4. Unfortunately, #2 and #3 move the
>>>> stack pointer...
>>>> uClibc mailing list
>>>> uClibc at uclibc.org
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel