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...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc