[OpenWrt-Devel] uClibc bug: epoll_pwait broken on OpenWrt x86

[Matthias Schiffer]

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...

Matthias


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.
> 
> Regards,
> Matthias
> 
> 
> On 09/01/2014 12:41 PM, Matthias Schiffer wrote:
>> Sure, I've attached my testcase (source and compiled for Barrier Breaker).
>>
>> Matthias
>>
>>
>> On 09/01/2014 08:31 AM, Waldemar Brodkorb wrote:
>>> Hi,
>>> can you provide a simple testcase showing the bug?
>>> best regards
>>>  Waldemar
>>>
>>>
>>>> Am 01.09.2014 um 00:53 schrieb Matthias Schiffer <mschiffer at universe-factory.net>:
>>>>
>>>> Hi,
>>>> 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
>>>> <__libc_epoll_pwait+0x5c>
>>>>    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
>>>> http://lists.busybox.net/mailman/listinfo/uclibc
>>
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140915/d26ff5c6/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel