git-1.8.4 fails to build due to fgetc is a macro

2013-08-27 Thread Natanael Copa 
Hi,

git-1.8.4 fails to build with this error:

cc -o config.o -c -MF ./.depend/config.o.d -MQ config.o -MMD -MP -Os
-fomit-frame-pointer -pipe -g -O2 -Wall -I. -DUSE_LIBPCRE -DNO_NSEC
-DNO_GETTEXT -DNO_ICONV  -DHAVE_PATHS_H -DHAVE_DEV_TTY
-DSHA1_HEADER=''  -DNO_STRLCPY -DUSE_WILDMATCH -DNO_MKSTEMPS
-DSHELL_PATH='"/bin/sh"' -DETC_GITCONFIG='"/etc/gitconfig"' config.c
In file included from /usr/include/stdio.h:72:0,
 from git-compat-util.h:99,
 from cache.h:4,
 from config.c:8:
config.c: In function 'get_next_char':
config.c:220:14: error: expected identifier before '(' token
  int c = cf->fgetc(cf);
  ^
config.c:220:14: error: expected statement before ')' token
  int c = cf->fgetc(cf);
  ^
config.c:220:14: error: expected statement before ')' token
  int c = cf->fgetc(cf);
  ^
config.c:224:11: error: expected identifier before '(' token
   c = cf->fgetc(cf);
   ^
make: *** [config.o] Error 1

The problem appear to be that fgetc is a macro in uClibc.

Any idea what the proper fix for this would be? Is it really a good idea to
use macro instead of function for fgetc/fputc?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Next release of uclibc

2013-04-16 Thread Natanael Copa 
reverting 342a3d861fde5651ee53486addbacddcec6a0a58 is a good start


On Fri, Apr 12, 2013 at 5:31 PM, Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:

> On 12 April 2013 11:10:54 Natanael Copa  wrote:
>
>  This must be reverted as it breaks x86_64 (qemu disk images gets corrupt):
>> http://git.uclibc.org/uClibc/**commit/libc/sysdeps/linux/**
>> common/pread_write.c?h=0.9.33&**id=**342a3d861fde5651ee53486addbacd**
>> dcec6a0a58<http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/pread_write.c?h=0.9.33&id=342a3d861fde5651ee53486addbacddcec6a0a58>
>>
>> As mentioned here with proper fix:
>> http://www.mail-archive.com/**uclibc@uclibc.org/msg08424.**html<http://www.mail-archive.com/uclibc@uclibc.org/msg08424.html>
>>
>
> Mike installed a fix for this on master, I would prefer not to pull in the
> complete stuff on the branch.
>
>>
>> -nc
>>
>
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
>
>
>


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Next release of uclibc

2013-04-12 Thread Natanael Copa 
On Tue, Apr 9, 2013 at 12:25 PM, Florian Fainelli wrote:

> Hello Bernhard,
>
> Le 03/29/13 13:42, Bernhard Reutner-Fischer a écrit :
>
>  On 20 March 2013 22:39, Bernd Kuhls  wrote:
>>
>>  But that original patch from OpenWRT (
> https://dev.openwrt.org/**ticket/11495)
>  seems to be wrong
>

 Do you have a testcase for this second one? I'm not sure what this is
 supposed to fix.

>>>
>>> It fixes a cosmetic error message shown by nslookup, a console log can be
>>> found in the forementioned OpenWRT ticket.
>>>
>>
>> I applied Felix' patch.
>>
>
> Thanks! Are there more pending patches that you want to queue for 0.9.33.3
> ?
>

This must be reverted as it breaks x86_64 (qemu disk images gets corrupt):
http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/pread_write.c?h=0.9.33&id=342a3d861fde5651ee53486addbacddcec6a0a58

As mentioned here with proper fix:
http://www.mail-archive.com/uclibc@uclibc.org/msg08424.html

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: uClibc Hardening Guide?

2013-03-04 Thread Natanael Copa 
On Fri, Mar 1, 2013 at 2:25 PM, Anthony G. Basile  wrote:

> I produce hardened uclibc gentoo stage3 tarballs for amd64, mips32r2 and
> x86.



 ...and I produce an x86 and x86_64 Linux distro with SSP and PIE enabled
uClibc and a PAXed kernel with lots of precompiled packages. (everything
from xen, qemu, libvirt to xfce and firefox)

http://alpinelinux.org

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] res_query() silently rejects responses against T_ANY DNS questions.

2013-03-04 Thread Natanael Copa 
looks similar to this issue:
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/0002-resolv-res_query-for-CNAMEs.patch

Sent to the list 2009:
http://lists.busybox.net/pipermail/uclibc/2009-June/042583.html



On Mon, Jul 9, 2012 at 3:01 AM, Chris Luke  wrote:

> res_query() is rejecting T_ANY and T_CNAME requests since they give
> answers with a different type. It also doesn't reject them cleanly,
> returning the length of the packet that would be returned (but not filling
> in the buffer) instead of -1.
>
> This commit fixes that by allowing T_ANY questions to have any type of
> answer and T_A or T_ questions to have T_CNAME answers.
>
> It also returns -1 if it otherwise rejects the response.
>
> See 
> https://bugs.busybox.net/show_**bug.cgi?id=5342<https://bugs.busybox.net/show_bug.cgi?id=5342>which
>  has a test case for this.
>
> Patch has been tested on OpenWrt and i386 buildroot.
>
> Signed-off-by: Chris Luke 
> ---
>  libc/inet/resolv.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c
> index e9f550b..06af2dc 100644
> --- a/libc/inet/resolv.c
> +++ b/libc/inet/resolv.c
> @@ -3736,10 +3736,16 @@ int res_query(const char *dname, int class, int
> type,
>  free(a.dotted);
>  -   if (a.atype == type) { /* CNAME */
> +   /* Copy the answer only if the type asked for is the same as the
> answer,
> +* we asked for T_ANY, or an A or  returned a CNAME first.
> +*/
> +   if (a.atype == type || type == T_ANY || (a.atype == T_CNAME &&
> (type == T_A || type == T_))) {
> if (i > anslen)
> i = anslen;
> memcpy(answer, packet, i);
> +   } else {
> +   h_errno = NO_DATA;
> +   i = -1;
> }
> free(packet);
> return i;
> --
> 1.7.9.5
>
>
> __**_____
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/**mailman/listinfo/uclibc<http://lists.busybox.net/mailman/listinfo/uclibc>
>



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Fw: [libvirt] [PATCH] build: trivial fix error: implicit declaration of function 'malloc'

2012-11-28 Thread Natanael Copa 
On Fri, Nov 23, 2012 at 4:38 PM, Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:

> On 22 November 2012 16:29, Natanael Copa  wrote:
> > __sched_cpualloc
>
> right. Can you check if this fixes it, please?
>
> diff --git a/libc/sysdeps/linux/common/bits/sched.h
> b/libc/sysdeps/linux/common/bits/sched.h
> index b1f94ce..a5eb6ee 100644
> --- a/libc/sysdeps/linux/common/bits/sched.h
> +++ b/libc/sysdeps/linux/common/bits/sched.h
> @@ -108,6 +108,7 @@ struct __sched_param
>  /* Size definition for CPU sets.  */
>  # define __CPU_SETSIZE 1024
>  # define __NCPUBITS(8 * sizeof (__cpu_mask))
> +# include 
>
>  /* Type for array elements in 'cpu_set_t'.  */
>  typedef unsigned long int __cpu_mask;
>


Yes. This seems to fix it. Thanks!

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Fw: [libvirt] [PATCH] build: trivial fix error: implicit declaration of function 'malloc'

2012-11-22 Thread Natanael Copa 
Hi,

I am forwarding this issue I had with a compile warning when building libvirtd.

It turns out that sched.h uses malloc without including stdlib.h. This
results in a silent compiling error on 64 bit platforms.


Begin forwarded message:

Date: Thu, 22 Nov 2012 06:53:12 -0700
From: Eric Blake 
To: Natanael Copa 
Cc: "Daniel P. Berrange" , libvir-l...@redhat.com
Subject: Re: [libvirt] [PATCH] build: trivial fix error: implicit declaration 
of function 'malloc'


On 11/22/2012 06:46 AM, Natanael Copa wrote:
>> If your headers are defining this in terms of malloc(), then IMHO,
>> the sched.h should be including stdlib.h on our behalf. IOW, I
>> think this is a bug in the c library headers
> 
> You are right. uclibc does this:
> 
> #if 0 /* in uClibc we use macros */
> extern cpu_set_t *__sched_cpualloc (size_t __count) __THROW __wur;
> extern void __sched_cpufree (cpu_set_t *__set) __THROW;
> #else
> # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt)))

Ouch.

> # define __sched_cpufree(__set) free(__set)
> #endif
> 
> And since this is only a warning, I don't think its worth the effort.

And that's where you're wrong.  Using malloc() without a prototype means
you are attempting to call 'int malloc(int)' instead of 'void
*malloc(size_t)'; and if sizeof(size_t)>sizeof(int) (as on most 64-bit
platforms), you have silently miscompiled.  The warning exists for a
reason, and we only have K&R C to blame that this is just a warning
rather than a hard error by default (at least C++ did it right by
mandating it as a hard error).

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] _scanf.c: Implement 'm' modifier for 'c' and '[' conversions.

2012-11-01 Thread Natanael Copa 
On Thu, Nov 1, 2012 at 1:02 PM, Will Newton  wrote:
> On Tue, Oct 16, 2012 at 12:00 PM, Will Newton  wrote:
>> The current code implements the 'm' modifier only for 's'
>> conversions and would cause a segfault if it was used for 'c'
>> or '[' conversions. This patch extends the code to cover these
>> cases too.
>>
>> Signed-off-by: Will Newton 
>> ---
>>  libc/stdio/_scanf.c |   51 
>> ---
>>  1 files changed, 32 insertions(+), 19 deletions(-)
>
> Any comments on this patch?

Are there any current applications that triggers this issue?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: dlclose segfaults on x86_64

2012-11-01 Thread Natanael Copa 
On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa  wrote:
> building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
...
> Core was generated by
> `/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen
> ../modules'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
> at libc/stdlib/malloc-standard/free.c:324
> 324 p->fd = *fb;
> (gdb) bt
> #0  0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
> at libc/stdlib/malloc-standard/free.c:324
> #1  0x7f9e5f0843d6 in do_dlclose (vhandle=0x7f9e60ca7be0, need_fini=1)
> at ldso/libdl/libdl.c:960
> #2  0x7f9e5f084a47 in dlclose (vhandle=0x7f9e60ca7be0)
> at ldso/libdl/libdl.c:1063
> #3  0x7f9e5ff06e1c in module_Unload (handle=)
> at posix/plugin.c:89
...

Does not seem like anybody really cares, but for the record, Timo
Teräs solved it with:
--- ./ldso/libdl/libdl.c.orig
+++ ./ldso/libdl/libdl.c
@@ -951,8 +951,8 @@

dtv_t *dtv = THREAD_DTV ();

-
_dl_assert(!(dtv[tls_lmap->l_tls_modid].pointer.is_static));
-   if
(dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
+   if
(!(dtv[tls_lmap->l_tls_modid].pointer.is_static) &&
+
dtv[tls_lmap->l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
/* Note that free is
called for NULL is well.  We
deallocate even if it
is this dtv entry we are
supposed to load.  The
reason is that we call


Downloadable patch is available here:
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/uclibc-dlclose-fix.patch

I have a relatively small testcase application that can reproduce it
(using vlc's plugins)

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] libc/sysdeps: add {get,make,set,swap}context for x86_64

2012-10-31 Thread Natanael Copa 
imported from glibc

Signed-off-by: Natanael Copa 
---
 libc/sysdeps/linux/x86_64/Makefile.arch |  39 +
 libc/sysdeps/linux/x86_64/__start_context.S |  49 +++
 libc/sysdeps/linux/x86_64/getcontext.S  |  88 
 libc/sysdeps/linux/x86_64/makecontext.c | 121 
 libc/sysdeps/linux/x86_64/setcontext.S  | 103 +++
 libc/sysdeps/linux/x86_64/swapcontext.S | 121 
 libc/sysdeps/linux/x86_64/ucontext_i.sym|  37 +
 7 files changed, 558 insertions(+)
 create mode 100644 libc/sysdeps/linux/x86_64/__start_context.S
 create mode 100644 libc/sysdeps/linux/x86_64/getcontext.S
 create mode 100644 libc/sysdeps/linux/x86_64/makecontext.c
 create mode 100644 libc/sysdeps/linux/x86_64/setcontext.S
 create mode 100644 libc/sysdeps/linux/x86_64/swapcontext.S
 create mode 100644 libc/sysdeps/linux/x86_64/ucontext_i.sym

diff --git a/libc/sysdeps/linux/x86_64/Makefile.arch 
b/libc/sysdeps/linux/x86_64/Makefile.arch
index 7491d92..d9a48ef 100644
--- a/libc/sysdeps/linux/x86_64/Makefile.arch
+++ b/libc/sysdeps/linux/x86_64/Makefile.arch
@@ -10,6 +10,9 @@ CSRC := brk.c __syscall_error.c sigaction.c
 SSRC := \
__longjmp.S setjmp.S syscall.S bsd-setjmp.S bsd-_setjmp.S
 
+LIBC_ARCH_DIR := $(top_srcdir)/libc/sysdeps/linux/$(TARGET_ARCH)
+LIBC_ARCH_OUT := $(top_builddir)/libc/sysdeps/linux/$(TARGET_ARCH)
+
 ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
 SSRC += vfork.S clone.S
 endif
@@ -20,3 +23,39 @@ ifeq ($(UCLIBC_HAS_TLS),y)
 SSRC += sched_getcpu.S
 endif
 endif
+
+ifeq ($(UCLIBC_SUSV4_LEGACY),y)
+CSRC += makecontext.c
+
+SSRC += setcontext.S getcontext.S swapcontext.S __start_context.S
+
+ASFLAGS-setcontext.S   := -D_LIBC_REENTRANT
+ASFLAGS-getcontext.S   := -D_LIBC_REENTRANT
+ASFLAGS-swapcontext.S  := -D_LIBC_REENTRANT
+
+ifeq ($(UCLIBC_HAS_THREADS_NATIVE),y)
+#Needed to use the correct SYSCALL_ERROR_HANDLER
+ASFLAGS-setcontext.S   += -DUSE___THREAD
+ASFLAGS-getcontext.S   += -DUSE___THREAD
+ASFLAGS-swapcontext.S  += -DUSE___THREAD
+endif
+
+pregen-headers-$(UCLIBC_SUSV4_LEGACY) += $(LIBC_ARCH_OUT)/ucontext_i.h
+
+headers_clean-y += libc_arch_headers_clean
+
+CFLAGS-ucontext_i.c = -S
+
+$(LIBC_ARCH_OUT)/ucontext_i.c: $(LIBC_ARCH_DIR)/ucontext_i.sym
+   $(do_awk) $(top_srcdir)extra/scripts/gen-as-const.awk $< > $@
+
+$(LIBC_ARCH_OUT)/ucontext_i.s: $(LIBC_ARCH_OUT)/ucontext_i.c
+   $(compile.c)
+
+$(LIBC_ARCH_OUT)/ucontext_i.h: $(LIBC_ARCH_OUT)/ucontext_i.s
+$(do_sed) -n 
"s/^.*@@@name@@@\([^@]*\)@@@value@@@[^0-9Xxa-fA-F-]*\([0-9Xxa-fA-F-][0-9Xxa-fA-F-]*\).*@@@end@@@.*$\/#define
 \1 \2/p" $< > $@
+
+libc_arch_headers_clean:
+   $(do_rm) $(addprefix $(LIBC_ARCH_OUT)/ucontext_i., c h s)
+endif
+
diff --git a/libc/sysdeps/linux/x86_64/__start_context.S 
b/libc/sysdeps/linux/x86_64/__start_context.S
new file mode 100644
index 000..9f2ee23
--- /dev/null
+++ b/libc/sysdeps/linux/x86_64/__start_context.S
@@ -0,0 +1,49 @@
+/* Copyright (C) 2002-2012 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+   Contributed by Andreas Jaeger , 2002.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include 
+
+/* This is the helper code which gets called if a function which is
+   registered with 'makecontext' returns.  In this case we have to
+   install the context listed in the uc_link element of the context
+   'makecontext' manipulated at the time of the 'makecontext' call.
+   If the pointer is NULL the process must terminate.  */
+
+
+ENTRY(__start_context)
+   /* This removes the parameters passed to the function given to
+  'makecontext' from the stack.  RBX contains the address
+  on the stack pointer for the next context.  */
+   movq%rbx, %rsp
+
+   popq%rdi/* This is the next context.  */
+   cfi_adjust_cfa_offset(-8)
+   testq   %rdi, %rdi
+   je  2f  /* If it is zero exit.  */
+
+   callJUMPTARGET(__setcontext)
+   /* If this returns (which can happen if the syscall fails) we'll
+  exit the program with the return error value (-1).  */
+   movq%rax,%rdi
+
+2:
+   callHIDDEN_JUMPTARGET(exit)
+   /* The '

[PATCH] libc/sysdeps: {get,make,set,swap}context for i386

2012-10-31 Thread Natanael Copa 
imported from glibc

Signed-off-by: Natanael Copa 
---
 .gitignore |   1 +
 libc/sysdeps/linux/i386/Makefile.arch  |  37 ++
 libc/sysdeps/linux/i386/getcontext.S   |  84 ++
 libc/sysdeps/linux/i386/makecontext.S  | 123 +
 libc/sysdeps/linux/i386/setcontext.S   |  96 +
 libc/sysdeps/linux/i386/swapcontext.S  | 110 +
 libc/sysdeps/linux/i386/ucontext_i.sym |  30 
 7 files changed, 481 insertions(+)
 create mode 100644 libc/sysdeps/linux/i386/getcontext.S
 create mode 100644 libc/sysdeps/linux/i386/makecontext.S
 create mode 100644 libc/sysdeps/linux/i386/setcontext.S
 create mode 100644 libc/sysdeps/linux/i386/swapcontext.S
 create mode 100644 libc/sysdeps/linux/i386/ucontext_i.sym

diff --git a/.gitignore b/.gitignore
index 3ded06e..d09c929 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,6 +18,7 @@ install_dir/
 .*.dep
 /*.log
 cscope.*
+ucontext_i.[chs]
 
 #
 # Debugging files
diff --git a/libc/sysdeps/linux/i386/Makefile.arch 
b/libc/sysdeps/linux/i386/Makefile.arch
index a3bf32f..a12c42c 100644
--- a/libc/sysdeps/linux/i386/Makefile.arch
+++ b/libc/sysdeps/linux/i386/Makefile.arch
@@ -11,6 +11,9 @@ SSRC := \
__longjmp.S setjmp.S bsd-setjmp.S bsd-_setjmp.S \
sync_file_range.S syscall.S mmap.S mmap64.S
 
+LIBC_ARCH_DIR := $(top_srcdir)/libc/sysdeps/linux/$(TARGET_ARCH)
+LIBC_ARCH_OUT := $(top_builddir)/libc/sysdeps/linux/$(TARGET_ARCH)
+
 ifeq ($(UCLIBC_HAS_ADVANCED_REALTIME),y)
 SSRC += posix_fadvise64.S
 endif
@@ -18,3 +21,37 @@ endif
 ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
 SSRC += vfork.S clone.S
 endif
+
+ifeq ($(UCLIBC_SUSV4_LEGACY),y)
+SSRC += makecontext.S setcontext.S getcontext.S swapcontext.S
+
+ASFLAGS-setcontext.S   := -D_LIBC_REENTRANT
+ASFLAGS-getcontext.S   := -D_LIBC_REENTRANT
+ASFLAGS-swapcontext.S  := -D_LIBC_REENTRANT
+
+ifeq ($(UCLIBC_HAS_THREADS_NATIVE),y)
+#Needed to use the correct SYSCALL_ERROR_HANDLER
+ASFLAGS-setcontext.S   += -DUSE___THREAD
+ASFLAGS-getcontext.S   += -DUSE___THREAD
+ASFLAGS-swapcontext.S  += -DUSE___THREAD
+endif
+
+pregen-headers-$(UCLIBC_SUSV4_LEGACY) += $(LIBC_ARCH_OUT)/ucontext_i.h
+
+headers_clean-y += libc_arch_headers_clean
+
+CFLAGS-ucontext_i.c = -S
+
+$(LIBC_ARCH_OUT)/ucontext_i.c: $(LIBC_ARCH_DIR)/ucontext_i.sym
+   $(do_awk) $(top_srcdir)extra/scripts/gen-as-const.awk $< > $@
+
+$(LIBC_ARCH_OUT)/ucontext_i.s: $(LIBC_ARCH_OUT)/ucontext_i.c
+   $(compile.c)
+
+$(LIBC_ARCH_OUT)/ucontext_i.h: $(LIBC_ARCH_OUT)/ucontext_i.s
+   $(do_sed) -n 
"s/^.*@@@name@@@\([^@]*\)@@@value@@@[^0-9Xxa-fA-F-]*\([0-9Xxa-fA-F-][0-9Xxa-fA-F-]*\).*@@@end@@@.*$\/#define
 \1 \2/p" $< > $@
+
+libc_arch_headers_clean:
+   $(do_rm) $(addprefix $(LIBC_ARCH_OUT)/ucontext_i., c h s)
+endif
+
diff --git a/libc/sysdeps/linux/i386/getcontext.S 
b/libc/sysdeps/linux/i386/getcontext.S
new file mode 100644
index 000..3221b59
--- /dev/null
+++ b/libc/sysdeps/linux/i386/getcontext.S
@@ -0,0 +1,84 @@
+/* Save current context.
+   Copyright (C) 2001-2012 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+   Contributed by Ulrich Drepper , 2001.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include 
+
+#include "ucontext_i.h"
+
+
+ENTRY(__getcontext)
+   /* Load address of the context data structure.  */
+   movl4(%esp), %eax
+
+   /* Return value of getcontext.  EAX is the only register whose
+  value is not preserved.  */
+   movl$0, oEAX(%eax)
+
+   /* Save the 32-bit register values and the return address.  */
+   movl%ecx, oECX(%eax)
+   movl%edx, oEDX(%eax)
+   movl%edi, oEDI(%eax)
+   movl%esi, oESI(%eax)
+   movl%ebp, oEBP(%eax)
+   movl(%esp), %ecx
+   movl%ecx, oEIP(%eax)
+   leal4(%esp), %ecx   /* Exclude the return address.  */
+   movl%ecx, oESP(%eax)
+   movl%ebx, oEBX(%eax)
+
+   /* Save the FS segment register.  We don't touch the GS register
+  since it is used for threads.  */
+   xorl%edx, %edx
+   movw%fs, %dx
+   movl%edx, oFS(%eax)
+
+   /* We have separate floating-point register content memory on the
+  s

Re: dlclose segfaults on x86_64

2012-10-05 Thread Natanael Copa 
On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa  wrote:
> Hi,
>
> I have an issue that I suspect is a bug in uclibc, 0.9.33.2 and gcc-4.7
>
> building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
> On 32bit x86 it works.

Looking at the commits...
This looks like doing evil stuff on 64 bit:

http://git.uclibc.org/uClibc/commit/ldso?h=0.9.33&id=9b42da7d0558884e2a3cc9a8674ccfc752369610

Infact, that 'unsigned int' and 'addr' looks suspicious.


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

dlclose segfaults on x86_64

2012-10-05 Thread Natanael Copa 
Hi,

I have an issue that I suspect is a bug in uclibc, 0.9.33.2 and gcc-4.7

building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
On 32bit x86 it works.

I enabled debugging symbols and got a backtrace:
dev64-edge:~/aports/main/vlc/src/vlc-2.0.3/bin$ gdb --core core .libs/lt-vlc-cac
he-gen
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen...done.

warning: core file may not match specified executable file.
[New LWP 15590]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by
`/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen
../modules'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
at libc/stdlib/malloc-standard/free.c:324
324 p->fd = *fb;
(gdb) bt
#0  0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
at libc/stdlib/malloc-standard/free.c:324
#1  0x7f9e5f0843d6 in do_dlclose (vhandle=0x7f9e60ca7be0, need_fini=1)
at ldso/libdl/libdl.c:960
#2  0x7f9e5f084a47 in dlclose (vhandle=0x7f9e60ca7be0)
at ldso/libdl/libdl.c:1063
#3  0x7f9e5ff06e1c in module_Unload (handle=)
at posix/plugin.c:89
#4  0x7f9e5fef3ac4 in AllocatePluginFile (st=0x7fff6b2237f8,
relpath=0x7f9e60c7f8a0 "notify/.libs/libnotify_plugin.so",
abspath=0x7f9e60c79aa0 "../modules/notify/.libs/libnotify_plugin.so",
bank=0x7fff6b223b00) at modules/bank.c:489
#5  AllocatePluginDir (bank=bank@entry=0x7fff6b223b00, maxdepth=2,
maxdepth@entry=3, absdir=,
reldir=0x7f9e60c4bab0 "notify/.libs") at modules/bank.c:440
#6  0x7f9e5fef3b5a in AllocatePluginDir (bank=bank@entry=0x7fff6b223b00,
maxdepth=3, maxdepth@entry=4, absdir=,
reldir=0x7f9e60c76e00 "notify") at modules/bank.c:444
#7  0x7f9e5fef3b5a in AllocatePluginDir (bank=bank@entry=0x7fff6b223b00,
maxdepth=4, maxdepth@entry=5,
absdir=absdir@entry=0x7f9e60db7990 "../modules", reldir=reldir@entry=0x0)
at modules/bank.c:444
#8  0x7f9e5fef3ca0 in AllocatePluginPath (
p_this=p_this@entry=0x7f9e60c311e8, path=0x7f9e60db7990 "../modules",
mode=mode@entry=CACHE_USE) at modules/bank.c:353
#9  0x7f9e5fef4081 in AllocateAllPlugins (p_this=0x7f9e60c311e8)
at modules/bank.c:298
#10 module_LoadPlugins (obj=obj@entry=0x7f9e60c311e8) at modules/bank.c:189
#11 0x7f9e5fe9f8ef in libvlc_InternalInit (
p_libvlc=p_libvlc@entry=0x7f9e60c311e8, i_argc=i_argc@entry=3,
ppsz_argv=ppsz_argv@entry=0x7fff6b223ce0) at libvlc.c:247
#12 0x7f9e601508be in libvlc_new (argc=argc@entry=2,
argv=argv@entry=0x7fff6b223d68) at core.c:59
#13 0x7f9e6056eba9 in main (argc=2, argv=0x7fff6b224008) at cachegen.c:107
(gdb)

I ran the command in valgrind but could not see anything about double free.

I am not sure if another issue with dlopen is related with sdl:
http://git.alpinelinux.org/cgit/aports/commit/main/sdl?id=be91866229a76e73f1ecdbdbfec83b8e69cb6e69

Any ideas?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 0.9.33 0/7] Backport pread/pwrite fixes from master

2012-08-29 Thread Natanael Copa 
On Wed, Aug 29, 2012 at 2:42 PM, Johannes Stezenbach  wrote:
> Hi Natanael,
>
> On Wed, Aug 29, 2012 at 09:18:57AM +, Natanael Copa wrote:
>> I previously sent a bug report for pread/pwrite with a link to a
>> patch that i hacked up quick and dirty. This showed up to be severly
>> broken on x86_64 and corrupted several qemu disks images for me.
>>
>> I see that this bad patch made it into 0.9.33 stabel tree. I think it
>> should be reverted and instead use cherry-picks from master. This is
>> what we currently use with success in Alpine Linux.
>>
>> Tested on x86_64 and x86.
>
> I just built a toolchain for ARM from 0.9.33 stable branch
> and I'm trying to figure out if the breakage is x86_64 only.
> could you give more details what breaks and why?

It is only 64bit that is broke. On 64bit it should be an alias to the
pread64/pwrite64 syscalls and not do the offset hi/lo stuff like it
need to do on 32bit. The result was that offsets bigger than 4G (or
2G?) got cutted. Typical 64 bit vs 32 bit bug.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 0.9.33 6/7] pread_write.c: make all archs use common code

2012-08-29 Thread Natanael Copa 
From: "Peter S. Mazinger" 

c6x does not need own version at all

Signed-off-by: Peter S. Mazinger 
Signed-off-by: Bernhard Reutner-Fischer 
(cherry picked from commit 836d74b92d70b71792d3d6136db7cdf0c3775ee3)
---
 libc/sysdeps/linux/c6x/Makefile.arch |   3 +-
 libc/sysdeps/linux/c6x/pread_write.c | 103 ---
 libc/sysdeps/linux/common/pread_write.c  |   2 +
 libc/sysdeps/linux/mips/pread_write.c| 116 +--
 libc/sysdeps/linux/powerpc/pread_write.c |  70 +--
 libc/sysdeps/linux/sh/pread_write.c  | 109 -
 libc/sysdeps/linux/xtensa/pread_write.c  |  79 +
 7 files changed, 88 insertions(+), 394 deletions(-)
 delete mode 100644 libc/sysdeps/linux/c6x/pread_write.c

diff --git a/libc/sysdeps/linux/c6x/Makefile.arch 
b/libc/sysdeps/linux/c6x/Makefile.arch
index 6bb44f2..5f8aaec 100644
--- a/libc/sysdeps/linux/c6x/Makefile.arch
+++ b/libc/sysdeps/linux/c6x/Makefile.arch
@@ -5,6 +5,7 @@
 # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
 #
 
-CSRC := brk.c pread_write.c syscall.c prctl.c
+CSRC := brk.c syscall.c prctl.c
+#CSRC :=
 
 SSRC := __longjmp.S bsd-_setjmp.S bsd-setjmp.S clone.S setjmp.S _vfork.S
diff --git a/libc/sysdeps/linux/c6x/pread_write.c 
b/libc/sysdeps/linux/c6x/pread_write.c
deleted file mode 100644
index f985b43..000
--- a/libc/sysdeps/linux/c6x/pread_write.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/* vi: set sw=4 ts=4:
- *
- * Copyright (C) 2002 by Erik Andersen 
- * Based in part on the files
- * ./sysdeps/unix/sysv/linux/pwrite.c,
- * ./sysdeps/unix/sysv/linux/pread.c,
- * sysdeps/posix/pread.c
- * sysdeps/posix/pwrite.c
- * from GNU libc 2.2.5, but reworked considerably...
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Library General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License
- * for more details.
- *
- * You should have received a copy of the GNU Library General Public License
- * along with this program; if not, write to the Free Software Foundation,
- * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#define _LARGEFILE64_SOURCE
-#include 
-#undef __OPTIMIZE__
-/* We absolutely do _NOT_ want interfaces silently
- *  *  * renamed under us or very bad things will happen... */
-#ifdef __USE_FILE_OFFSET64
-# undef __USE_FILE_OFFSET64
-#endif
-
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-extern __typeof(pread) __libc_pread;
-extern __typeof(pwrite) __libc_pwrite;
-#ifdef __UCLIBC_HAS_LFS__
-extern __typeof(pread64) __libc_pread64;
-extern __typeof(pwrite64) __libc_pwrite64;
-#endif
-
-#ifdef __NR_pread64 /* Newer kernels renamed but it's the same.  */
-# ifdef __NR_pread
-#  error "__NR_pread and __NR_pread64 both defined???"
-# endif
-# define __NR_pread __NR_pread64
-#endif
-
-#define __NR___syscall_pread __NR_pread
-static inline _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf,
-   size_t, count, off_t, offset_hi, off_t, offset_lo);
-
-ssize_t __libc_pread(int fd, void *buf, size_t count, off_t offset)
-{
-   return(__syscall_pread(fd,buf,count,offset,offset >> 31));
-}
-weak_alias (__libc_pread, pread)
-
-#if defined __UCLIBC_HAS_LFS__
-ssize_t __libc_pread64(int fd, void *buf, size_t count, off64_t offset)
-{
-uint32_t low = offset & 0x;
-uint32_t high = offset >> 32;
-   return(__syscall_pread(fd, buf, count, low, high));
-}
-weak_alias (__libc_pread64, pread64)
-#endif /* __UCLIBC_HAS_LFS__  */
-
-
-#ifdef __NR_pwrite64/* Newer kernels renamed but it's the same.  */
-# ifdef __NR_pwrite
-#  error "__NR_pwrite and __NR_pwrite64 both defined???"
-# endif
-# define __NR_pwrite __NR_pwrite64
-#endif
-
-#define __NR___syscall_pwrite __NR_pwrite
-static inline _syscall5(ssize_t, __syscall_pwrite, int, fd, const void *, buf,
-   size_t, count, off_t, offset_hi, off_t, offset_lo);
-
-ssize_t __libc_pwrite(int fd, const void *buf, size_t count, off_t offset)
-{
-   return(__syscall_pwrite(fd,buf,count,offset,offset >> 31));
-}
-weak_alias (__libc_pwrite, pwrite)
-
-#if defined __UCLIBC_HAS_LFS__
-ssize_t __libc_pwrite64(int fd, const void *buf, size_t count, off64_t offset)
-{
-uint32_t low = offset & 0x;
-uint32_t high = offset >> 32;
-   return(__syscall_pwrite(fd, buf, count, low, high));
-}
-weak_alias (__libc_pwrite64, pwrite64)
-#endif /* __UCLIBC_HAS_LFS__  */
-
diff --git a/libc/sysdeps/linux/common/pread_write.c 
b/libc/sysdeps/linux/common/pread_write.c
index 3

[PATCH 0.9.33 4/7] pread/pwrite: drop fallback funcs

2012-08-29 Thread Natanael Copa 
From: Mike Frysinger 

Linux has provided these functions since the 2.1.x era, so no need to
keep these around.  We'd rather find out when things are missing (and
fix that) than fall back to the unsafe hacks.

Signed-off-by: Mike Frysinger 
(cherry picked from commit 80c9bfc4668e2370b3434a801dc266f336265832)
---
 libc/sysdeps/linux/common/pread_write.c  | 112 -
 libc/sysdeps/linux/powerpc/pread_write.c | 117 ---
 libc/sysdeps/linux/xtensa/pread_write.c  | 112 -
 3 files changed, 341 deletions(-)

diff --git a/libc/sysdeps/linux/common/pread_write.c 
b/libc/sysdeps/linux/common/pread_write.c
index 089ee93..48fe7dd 100644
--- a/libc/sysdeps/linux/common/pread_write.c
+++ b/libc/sysdeps/linux/common/pread_write.c
@@ -83,115 +83,3 @@ ssize_t __libc_pwrite64(int fd, const void *buf, size_t 
count, off64_t offset)
 weak_alias(__libc_pwrite64,pwrite64)
 # endif /* __UCLIBC_HAS_LFS__  */
 #endif /* __NR_pwrite */
-
-#if ! defined __NR_pread || ! defined __NR_pwrite
-
-static ssize_t __fake_pread_write(int fd, void *buf,
-   size_t count, off_t offset, int do_pwrite)
-{
-   int save_errno;
-   ssize_t result;
-   off_t old_offset;
-
-   /* Since we must not change the file pointer preserve the
-* value so that we can restore it later.  */
-   if ((old_offset=lseek(fd, 0, SEEK_CUR)) == (off_t) -1)
-   return -1;
-
-   /* Set to wanted position.  */
-   if (lseek(fd, offset, SEEK_SET) == (off_t) -1)
-   return -1;
-
-   if (do_pwrite == 1) {
-   /* Write the data.  */
-   result = write(fd, buf, count);
-   } else {
-   /* Read the data.  */
-   result = read(fd, buf, count);
-   }
-
-   /* Now we have to restore the position.  If this fails we
-* have to return this as an error.  */
-   save_errno = errno;
-   if (lseek(fd, old_offset, SEEK_SET) == (off_t) -1)
-   {
-   if (result == -1)
-   __set_errno(save_errno);
-   return -1;
-   }
-   __set_errno(save_errno);
-   return(result);
-}
-
-# ifdef __UCLIBC_HAS_LFS__
-
-static ssize_t __fake_pread_write64(int fd, void *buf,
-   size_t count, off64_t offset, int do_pwrite)
-{
-   int save_errno;
-   ssize_t result;
-   off64_t old_offset;
-
-   /* Since we must not change the file pointer preserve the
-* value so that we can restore it later.  */
-   if ((old_offset=lseek64(fd, 0, SEEK_CUR)) == (off64_t) -1)
-   return -1;
-
-   /* Set to wanted position.  */
-   if (lseek64(fd, offset, SEEK_SET) == (off64_t) -1)
-   return -1;
-
-   if (do_pwrite == 1) {
-   /* Write the data.  */
-   result = write(fd, buf, count);
-   } else {
-   /* Read the data.  */
-   result = read(fd, buf, count);
-   }
-
-   /* Now we have to restore the position. */
-   save_errno = errno;
-   if (lseek64(fd, old_offset, SEEK_SET) == (off64_t) -1) {
-   if (result == -1)
-   __set_errno (save_errno);
-   return -1;
-   }
-   __set_errno (save_errno);
-   return result;
-}
-# endif /* __UCLIBC_HAS_LFS__  */
-#endif /*  ! defined __NR_pread || ! defined __NR_pwrite */
-
-#ifndef __NR_pread
-ssize_t __libc_pread(int fd, void *buf, size_t count, off_t offset)
-{
-   return __fake_pread_write(fd, buf, count, offset, 0);
-}
-weak_alias(__libc_pread,pread)
-
-# ifdef __UCLIBC_HAS_LFS__
-ssize_t __libc_pread64(int fd, void *buf, size_t count, off64_t offset)
-{
-   return __fake_pread_write64(fd, buf, count, offset, 0);
-}
-weak_alias(__libc_pread64,pread64)
-# endif /* __UCLIBC_HAS_LFS__  */
-#endif /* ! __NR_pread */
-
-#ifndef __NR_pwrite
-ssize_t __libc_pwrite(int fd, const void *buf, size_t count, off_t offset)
-{
-   /* we won't actually be modifying the buffer,
-*just cast it to get rid of warnings */
-   return __fake_pread_write(fd, (void*)buf, count, offset, 1);
-}
-weak_alias(__libc_pwrite,pwrite)
-
-# ifdef __UCLIBC_HAS_LFS__
-ssize_t __libc_pwrite64(int fd, const void *buf, size_t count, off64_t offset)
-{
-   return __fake_pread_write64(fd, (void*)buf, count, offset, 1);
-}
-weak_alias(__libc_pwrite64,pwrite64)
-# endif /* __UCLIBC_HAS_LFS__  */
-#endif /* ! __NR_pwrite */
diff --git a/libc/sysdeps/linux/powerpc/pread_write.c 
b/libc/sysdeps/linux/powerpc/pread_write.c
index 23f256f..92a184c 100644
--- a/libc/sysdeps/linux/powerpc/pread_write.c
+++ b/libc/sysdeps/linux/powerpc/pread_write.c
@@ -77,120 +77,3 @@ ssize_t __libc_pwrite64(int fd, const void *buf, size_t 
count, off64_t offset)
 weak_alias(__libc_pwrite64,pwrite64)
 # endif /* __UCLIBC_HAS_LFS__  */
 #endif /* __NR_pwrite */
-
-
-
-#if ! defined __NR_pread || ! defined __NR_pwrite
-
-static ssize_t __fake_pre

[PATCH 0.9.33 7/7] endian.h: add some handy macros to be used in syscalls

2012-08-29 Thread Natanael Copa 
From: "Peter S. Mazinger" 

Signed-off-by: Peter S. Mazinger 
Signed-off-by: Bernhard Reutner-Fischer 
(cherry picked from commit f6a03f19cf2807170717593b4de8056a1248b99b)
---
 include/endian.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/endian.h b/include/endian.h
index 0ba7384..1e2fc93 100644
--- a/include/endian.h
+++ b/include/endian.h
@@ -55,6 +55,17 @@
 # define __LONG_LONG_PAIR(HI, LO) HI, LO
 #endif
 
+#ifdef _LIBC
+# ifndef __ASSEMBLER__
+#  include 
+#  define OFF_HI(offset) (offset >> 31)
+#  define OFF_LO(offset) (offset)
+#  define OFF64_HI(offset) (uint32_t)(offset >> 32)
+#  define OFF64_LO(offset) (uint32_t)(offset & 0x)
+#  define OFF_HI_LO(offset) __LONG_LONG_PAIR(OFF_HI(offset), OFF_LO(offset))
+#  define OFF64_HI_LO(offset) __LONG_LONG_PAIR(OFF64_HI(offset), 
OFF64_LO(offset))
+# endif
+#endif
 
 #ifdef __USE_BSD
 /* Conversion interfaces.  */
-- 
1.7.12

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 0.9.33 2/7] cancel.h: add generic file to ease cancellation support

2012-08-29 Thread Natanael Copa 
From: "Peter S. Mazinger" 

Signed-off-by: Peter S. Mazinger 
Signed-off-by: Bernhard Reutner-Fischer 
(cherry picked from commit 9f68f0cbf8c8eea6a7f9e195e4617bbaa808d7c6)

Conflicts:
Makefile.in
---
 Makefile.in  |   1 +
 include/cancel.h | 101 +++
 2 files changed, 102 insertions(+)
 create mode 100644 include/cancel.h

diff --git a/Makefile.in b/Makefile.in
index 9ba590d..e81926d 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -210,6 +210,7 @@ $(top_builddir)extra/scripts/unifdef: 
$(top_srcdir)extra/scripts/unifdef.c
 # a "y" here means the feature is enabled and so we should *not* rm it.
 # if the option expands to nothing though, we can punt the headers.
 HEADERS_RM- := \
+   cancel.h \
dl-osinfo.h \
hp-timing.h \
_lfs_64.h \
diff --git a/include/cancel.h b/include/cancel.h
new file mode 100644
index 000..ac6f6b6
--- /dev/null
+++ b/include/cancel.h
@@ -0,0 +1,101 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * Copyright (C) 2000-2011 Erik Andersen 
+ *
+ * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
+ */
+
+#ifndef _CANCEL_H
+#define _CANCEL_H
+
+/*
+ * Usage of this header:
+ * 1. define a static or hidden function __NC(NAME) - expands to 
__NAME_nocancel
+ * 2. if it is hidden, add the prototype to the appropiate header where NAME 
has
+ * it's prototype (guarded by _LIBC)
+ * 3. add a CANCELLABLE_SYSCALL(...) line at the end, this will create the 
function
+ * NAME (as weak) with enabled cancellation for NPTL (and later for new LT), 
for
+ * LT_OLD it will also create a strong_alias to __libc_NAME to be used in 
libpthread
+ * 4. if you need libc_hidden_(weak|def) line, use instead lt_libc_hidden, 
this will
+ * take care of the correct type, weak or strong depending on the THREADS type
+ * 5. If the implementation can't be done using CANCELLABLE_SYSCALL (like for 
fcntl)
+ * you need to manually add lt_strong_alias() line too, to optionally create 
the
+ * __libc_NAME alias
+ * 6. if functions are needed to implement __NC(NAME), that themselves are 
cancellable,
+ * decide how the cancellation should be solved, two variants are possible:
+ *  a. use the other function as __NC(FUNC), this way you access the 
non-cancellable
+ *  variant and provide by CANCELLABLE_SYSCALL(...) the dedicated cancellation 
for NAME.
+ *  be aware, that for this case __NC(FUNC) has to be hidden (not static)
+ *  b. use the other function with it's name (FUNC) and add 
LIBC_CANCEL_HANDLED(); at
+ *  the end of file with a comment telling us which function took care of the 
cancellation
+ * Note: LIBC_CANCEL_HANDLED() is noop on uClibc, glibc uses it only for 
tests, we use
+ * it only for "documentation".
+ *
+ * For now the use of this file is limited to libc, will expand later to 
support libpthread
+ * and librt as well.
+ */
+
+#include 
+
+#ifndef NOT_IN_libc
+
+#define __NC(name) _NC(name)
+#define _NC(name) __##name##_nocancel
+
+#define __NC_OLD(name) _NC_OLD(name)
+#define _NC_OLD(name) __libc_##name
+
+#define __NC_PROTO(name) extern __typeof(name) __NC(name) attribute_hidden;
+#define __NC_OLD_PROTO(name) extern __typeof(name) __NC_OLD(name);
+
+#if defined __UCLIBC_HAS_THREADS__ && !defined __LINUXTHREADS_OLD__
+# define __NEW_THREADS 1
+#else
+# define SINGLE_THREAD_P 1
+#endif
+
+#ifdef __NEW_THREADS
+# include 
+
+# define CANCELLABLE_SYSCALL(res_type, name, param_list, params)   \
+res_type weak_function name param_list \
+{  \
+   if (SINGLE_THREAD_P)\
+   return __NC(name) params;   \
+   int oldtype = LIBC_CANCEL_ASYNC();  \
+   res_type result = __NC(name) params;\
+   LIBC_CANCEL_RESET(oldtype); \
+   return result;  \
+}
+
+# define lt_strong_alias(name)
+# define lt_libc_hidden(name) libc_hidden_def(name)
+
+#elif defined __LINUXTHREADS_OLD__
+
+# define CANCELLABLE_SYSCALL(res_type, name, param_list, params)   \
+weak_alias(__NC(name),name)\
+lt_strong_alias(name)
+
+# define lt_strong_alias(name) \
+__NC_OLD_PROTO(name)   \
+strong_alias(name,__NC_OLD(name))
+# define lt_libc_hidden(name) libc_hidden_weak(name)
+
+#else
+
+# define CANCELLABLE_SYSCALL(res_type, name, param_list, params)   \
+strong_alias(__NC(name),name)
+
+# define lt_strong_alias(name)
+# define lt_libc_hidden(name) libc_hidden_def(name)
+
+#endif
+
+/* disable it, useless, glibc uses it only for tests */
+# undef LIBC_CANCEL_HANDLED
+# define LIBC_CANCEL_HANDLED()
+
+#endif /* NOT_IN_libc */
+
+#endif
-- 
1.7.12

___

[PATCH 0.9.33 3/7] pread/pwrite: handle renamed syscalls in common/ppc/xtensa code

2012-08-29 Thread Natanael Copa 
From: Mike Frysinger 

Some arches got this fix, but many did not.  So copy the ifdef logic to
the ones that missed it to fix behavior in linux-2.6+.

URL: https://bugs.busybox.net/show_bug.cgi?id=5258
Reported-by: David Laight 
Signed-off-by: Mike Frysinger 
(cherry picked from commit 52fa45da0f86651b70608a58914f3aece7fdfed5)
---
 libc/sysdeps/linux/common/pread_write.c  | 10 ++
 libc/sysdeps/linux/powerpc/pread_write.c | 13 +
 libc/sysdeps/linux/xtensa/pread_write.c  | 14 ++
 3 files changed, 37 insertions(+)

diff --git a/libc/sysdeps/linux/common/pread_write.c 
b/libc/sysdeps/linux/common/pread_write.c
index 88e6957..089ee93 100644
--- a/libc/sysdeps/linux/common/pread_write.c
+++ b/libc/sysdeps/linux/common/pread_write.c
@@ -25,6 +25,11 @@ extern __typeof(pread64) __libc_pread64;
 extern __typeof(pwrite64) __libc_pwrite64;
 #endif
 
+#ifdef __NR_pread64 /* Newer kernels renamed but it's the same.  */
+# undef __NR_pread
+# define __NR_pread __NR_pread64
+#endif
+
 #include 
 
 #ifdef __NR_pread
@@ -51,6 +56,11 @@ weak_alias(__libc_pread64,pread64)
 
 #endif /* __NR_pread */
 
+#ifdef __NR_pwrite64 /* Newer kernels renamed but it's the same.  
*/
+# undef __NR_pwrite
+# define __NR_pwrite __NR_pwrite64
+#endif
+
 #ifdef __NR_pwrite
 
 # define __NR___syscall_pwrite __NR_pwrite
diff --git a/libc/sysdeps/linux/powerpc/pread_write.c 
b/libc/sysdeps/linux/powerpc/pread_write.c
index 7f988d3..23f256f 100644
--- a/libc/sysdeps/linux/powerpc/pread_write.c
+++ b/libc/sysdeps/linux/powerpc/pread_write.c
@@ -20,6 +20,13 @@
 # define off64_t off_t
 #endif
 
+#ifdef __NR_pread64 /* Newer kernels renamed but it's the same.  */
+# ifdef __NR_pread
+#  error "__NR_pread and __NR_pread64 both defined???"
+# endif
+# define __NR_pread __NR_pread64
+#endif
+
 #ifdef __NR_pread
 extern __typeof(pread) __libc_pread;
 # define __NR___syscall_pread __NR_pread
@@ -42,6 +49,12 @@ weak_alias(__libc_pread64,pread64)
 # endif /* __UCLIBC_HAS_LFS__  */
 #endif /* __NR_pread */
 
+#ifdef __NR_pwrite64/* Newer kernels renamed but it's the same.  */
+# ifdef __NR_pwrite
+#  error "__NR_pwrite and __NR_pwrite64 both defined???"
+# endif
+# define __NR_pwrite __NR_pwrite64
+#endif
 
 #ifdef __NR_pwrite
 extern __typeof(pwrite) __libc_pwrite;
diff --git a/libc/sysdeps/linux/xtensa/pread_write.c 
b/libc/sysdeps/linux/xtensa/pread_write.c
index 71ba22b..bcf7dee 100644
--- a/libc/sysdeps/linux/xtensa/pread_write.c
+++ b/libc/sysdeps/linux/xtensa/pread_write.c
@@ -27,6 +27,13 @@ extern __typeof(pwrite64) __libc_pwrite64;
 
 #include 
 
+#ifdef __NR_pread64 /* Newer kernels renamed but it's the same.  */
+# ifdef __NR_pread
+#  error "__NR_pread and __NR_pread64 both defined???"
+# endif
+# define __NR_pread __NR_pread64
+#endif
+
 #ifdef __NR_pread
 
 # define __NR___syscall_pread __NR_pread
@@ -52,6 +59,13 @@ weak_alias(__libc_pread64,pread64)
 
 #endif /* __NR_pread */
 
+#ifdef __NR_pwrite64/* Newer kernels renamed but it's the same.  */
+# ifdef __NR_pwrite
+#  error "__NR_pwrite and __NR_pwrite64 both defined???"
+# endif
+# define __NR_pwrite __NR_pwrite64
+#endif
+
 #ifdef __NR_pwrite
 
 # define __NR___syscall_pwrite __NR_pwrite
-- 
1.7.12

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 0.9.33 5/7] add cancellation to generic pread_write

2012-08-29 Thread Natanael Copa 
From: "Peter S. Mazinger" 

Prepare the file to be used in all arch specific files

Signed-off-by: Peter S. Mazinger 
Signed-off-by: Bernhard Reutner-Fischer 
(cherry picked from commit 61198b43ee8a639544622d0e666b972418c9c383)
---
 libc/sysdeps/linux/common/pread_write.c | 100 
 1 file changed, 51 insertions(+), 49 deletions(-)

diff --git a/libc/sysdeps/linux/common/pread_write.c 
b/libc/sysdeps/linux/common/pread_write.c
index 48fe7dd..3d04bb7 100644
--- a/libc/sysdeps/linux/common/pread_write.c
+++ b/libc/sysdeps/linux/common/pread_write.c
@@ -15,71 +15,73 @@
 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
-extern __typeof(pread) __libc_pread;
-extern __typeof(pwrite) __libc_pwrite;
-#ifdef __UCLIBC_HAS_LFS__
-extern __typeof(pread64) __libc_pread64;
-extern __typeof(pwrite64) __libc_pwrite64;
-#endif
-
-#ifdef __NR_pread64 /* Newer kernels renamed but it's the same.  */
+#ifdef __NR_pread64
 # undef __NR_pread
 # define __NR_pread __NR_pread64
 #endif
+#ifdef __NR_pwrite64
+# undef __NR_pwrite
+# define __NR_pwrite __NR_pwrite64
+#endif
 
-#include 
-
-#ifdef __NR_pread
+#ifndef MY_PREAD
+# ifdef __NR_pread
+#  define __NR___syscall_pread __NR_pread
+static _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf,
+size_t, count, off_t, offset_hi, off_t, offset_lo)
+#  define MY_PREAD(fd, buf, count, offset) __syscall_pread(fd, buf, count, 
OFF_HI_LO(offset))
+#  define MY_PREAD64(fd, buf, count, offset) __syscall_pread(fd, buf, count, 
OFF64_HI_LO(offset))
+#endif
 
-# define __NR___syscall_pread __NR_pread
-static __inline__ _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf,
-   size_t, count, off_t, offset_hi, off_t, offset_lo)
+#ifndef MY_PWRITE
+# ifdef __NR_pwrite
+#  define __NR___syscall_pwrite __NR_pwrite
+static _syscall5(ssize_t, __syscall_pwrite, int, fd, const void *, buf,
+size_t, count, off_t, offset_hi, off_t, offset_lo)
+#  define MY_PWRITE(fd, buf, count, offset) __syscall_pwrite(fd, buf, count, 
OFF_HI_LO(offset))
+#  define MY_PWRITE64(fd, buf, count, offset) __syscall_pwrite(fd, buf, count, 
OFF64_HI_LO(offset))
+#endif
 
-ssize_t __libc_pread(int fd, void *buf, size_t count, off_t offset)
+static ssize_t __NC(pread)(int fd, void *buf, size_t count, off_t offset)
 {
-   return __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(offset >> 31, 
offset));
+   return MY_PREAD(fd, buf, count, offset);
 }
-weak_alias(__libc_pread,pread)
+CANCELLABLE_SYSCALL(ssize_t, pread, (int fd, void *buf, size_t count, off_t 
offset),
+   (fd, buf, count, offset))
 
-# ifdef __UCLIBC_HAS_LFS__
-ssize_t __libc_pread64(int fd, void *buf, size_t count, off64_t offset)
+static ssize_t __NC(pwrite)(int fd, const void *buf, size_t count, off_t 
offset)
 {
-   uint32_t low = offset & 0x;
-   uint32_t high = offset >> 32;
-   return __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(high, low));
+   return MY_PWRITE(fd, buf, count, offset);
 }
-weak_alias(__libc_pread64,pread64)
-# endif /* __UCLIBC_HAS_LFS__  */
+CANCELLABLE_SYSCALL(ssize_t, pwrite, (int fd, const void *buf, size_t count, 
off_t offset),
+   (fd, buf, count, offset))
 
-#endif /* __NR_pread */
-
-#ifdef __NR_pwrite64 /* Newer kernels renamed but it's the same.  
*/
-# undef __NR_pwrite
-# define __NR_pwrite __NR_pwrite64
-#endif
-
-#ifdef __NR_pwrite
-
-# define __NR___syscall_pwrite __NR_pwrite
-static __inline__ _syscall5(ssize_t, __syscall_pwrite, int, fd, const void *, 
buf,
-   size_t, count, off_t, offset_hi, off_t, offset_lo)
-
-ssize_t __libc_pwrite(int fd, const void *buf, size_t count, off_t offset)
+#ifdef __UCLIBC_HAS_LFS__
+# if __WORDSIZE == 32
+static ssize_t __NC(pread64)(int fd, void *buf, size_t count, off64_t offset)
 {
-   return __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(offset >> 31, 
offset));
+   return MY_PREAD64(fd, buf, count, offset);
 }
-weak_alias(__libc_pwrite,pwrite)
+CANCELLABLE_SYSCALL(ssize_t, pread64, (int fd, void *buf, size_t count, 
off64_t offset),
+   (fd, buf, count, offset))
 
-# ifdef __UCLIBC_HAS_LFS__
-ssize_t __libc_pwrite64(int fd, const void *buf, size_t count, off64_t offset)
+static ssize_t __NC(pwrite64)(int fd, const void *buf, size_t count, off64_t 
offset)
 {
-   uint32_t low = offset & 0x;
-   uint32_t high = offset >> 32;
-   return __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(high, low));
+   return MY_PWRITE64(fd, buf, count, offset);
 }
-weak_alias(__libc_pwrite64,pwrite64)
-# endif /* __UCLIBC_HAS_LFS__  */
-#endif /* __NR_pwrite */
+CANCELLABLE_SYSCALL(ssize_t, pwrite64, (int fd, const void *buf, size_t count, 
off64_t offset),
+   (fd, buf, count, offset))
+# else
+#  ifdef __LINUXTHREADS_OLD__
+weak_alias(pread,pread64)
+weak_alias(pwrite,pwrite64)
+#  else
+strong_alias_untyped(pread,pread64)
+strong_alia

[PATCH 0.9.33 1/7] Revert "pread/pwrite: backport fix"

2012-08-29 Thread Natanael Copa 
This backport breaks x86_64 badly.

This reverts commit 342a3d861fde5651ee53486addbacddcec6a0a58.

Signed-off-by: Natanael Copa 
---
 libc/sysdeps/linux/common/pread_write.c | 143 +++-
 1 file changed, 124 insertions(+), 19 deletions(-)

diff --git a/libc/sysdeps/linux/common/pread_write.c 
b/libc/sysdeps/linux/common/pread_write.c
index baf8691..88e6957 100644
--- a/libc/sysdeps/linux/common/pread_write.c
+++ b/libc/sysdeps/linux/common/pread_write.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 
 extern __typeof(pread) __libc_pread;
 extern __typeof(pwrite) __libc_pwrite;
@@ -28,17 +27,15 @@ extern __typeof(pwrite64) __libc_pwrite64;
 
 #include 
 
-# define __NR___syscall_pread __NR_pread64
+#ifdef __NR_pread
+
+# define __NR___syscall_pread __NR_pread
 static __inline__ _syscall5(ssize_t, __syscall_pread, int, fd, void *, buf,
size_t, count, off_t, offset_hi, off_t, offset_lo)
 
 ssize_t __libc_pread(int fd, void *buf, size_t count, off_t offset)
 {
-   int oldtype = LIBC_CANCEL_ASYNC ();
-   int result = __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(offset >> 
31, offset));
-   LIBC_CANCEL_RESET (oldtype);
-   return result;
-
+   return __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(offset >> 31, 
offset));
 }
 weak_alias(__libc_pread,pread)
 
@@ -47,24 +44,22 @@ ssize_t __libc_pread64(int fd, void *buf, size_t count, 
off64_t offset)
 {
uint32_t low = offset & 0x;
uint32_t high = offset >> 32;
-   int oldtype = LIBC_CANCEL_ASYNC ();
-   int result = __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(high, 
low));
-   LIBC_CANCEL_RESET (oldtype);
-   return result;
+   return __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(high, low));
 }
 weak_alias(__libc_pread64,pread64)
 # endif /* __UCLIBC_HAS_LFS__  */
 
-# define __NR___syscall_pwrite __NR_pwrite64
+#endif /* __NR_pread */
+
+#ifdef __NR_pwrite
+
+# define __NR___syscall_pwrite __NR_pwrite
 static __inline__ _syscall5(ssize_t, __syscall_pwrite, int, fd, const void *, 
buf,
size_t, count, off_t, offset_hi, off_t, offset_lo)
 
 ssize_t __libc_pwrite(int fd, const void *buf, size_t count, off_t offset)
 {
-   int oldtype = LIBC_CANCEL_ASYNC ();
-   int result = __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(offset 
>> 31, offset));
-   LIBC_CANCEL_RESET (oldtype);
-   return result;
+   return __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(offset >> 31, 
offset));
 }
 weak_alias(__libc_pwrite,pwrite)
 
@@ -73,10 +68,120 @@ ssize_t __libc_pwrite64(int fd, const void *buf, size_t 
count, off64_t offset)
 {
uint32_t low = offset & 0x;
uint32_t high = offset >> 32;
-   int oldtype = LIBC_CANCEL_ASYNC ();
-   int result = __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(high, 
low));
-   LIBC_CANCEL_RESET (oldtype);
+   return __syscall_pwrite(fd, buf, count, __LONG_LONG_PAIR(high, low));
+}
+weak_alias(__libc_pwrite64,pwrite64)
+# endif /* __UCLIBC_HAS_LFS__  */
+#endif /* __NR_pwrite */
+
+#if ! defined __NR_pread || ! defined __NR_pwrite
+
+static ssize_t __fake_pread_write(int fd, void *buf,
+   size_t count, off_t offset, int do_pwrite)
+{
+   int save_errno;
+   ssize_t result;
+   off_t old_offset;
+
+   /* Since we must not change the file pointer preserve the
+* value so that we can restore it later.  */
+   if ((old_offset=lseek(fd, 0, SEEK_CUR)) == (off_t) -1)
+   return -1;
+
+   /* Set to wanted position.  */
+   if (lseek(fd, offset, SEEK_SET) == (off_t) -1)
+   return -1;
+
+   if (do_pwrite == 1) {
+   /* Write the data.  */
+   result = write(fd, buf, count);
+   } else {
+   /* Read the data.  */
+   result = read(fd, buf, count);
+   }
+
+   /* Now we have to restore the position.  If this fails we
+* have to return this as an error.  */
+   save_errno = errno;
+   if (lseek(fd, old_offset, SEEK_SET) == (off_t) -1)
+   {
+   if (result == -1)
+   __set_errno(save_errno);
+   return -1;
+   }
+   __set_errno(save_errno);
+   return(result);
+}
+
+# ifdef __UCLIBC_HAS_LFS__
+
+static ssize_t __fake_pread_write64(int fd, void *buf,
+   size_t count, off64_t offset, int do_pwrite)
+{
+   int save_errno;
+   ssize_t result;
+   off64_t old_offset;
+
+   /* Since we must not change the file pointer preserve the
+* value so that we can restore it later.  */
+   if ((old_offset=lseek64(fd, 0, SEEK_CUR)) == (off64_t) -1)
+   return -1;
+
+   /* Set to wanted position.  */
+   if (lseek64(fd, offset, SEEK_SET) == (off64_t) -1)
+   return -1;
+
+   if (do_pwrite == 1) {
+   /* Write the data

[PATCH 0.9.33 0/7] Backport pread/pwrite fixes from master

2012-08-29 Thread Natanael Copa 
I previously sent a bug report for pread/pwrite with a link to a
patch that i hacked up quick and dirty. This showed up to be severly
broken on x86_64 and corrupted several qemu disks images for me.

I see that this bad patch made it into 0.9.33 stabel tree. I think it
should be reverted and instead use cherry-picks from master. This is
what we currently use with success in Alpine Linux.

Tested on x86_64 and x86.


Mike Frysinger (2):
  pread/pwrite: handle renamed syscalls in common/ppc/xtensa code
  pread/pwrite: drop fallback funcs

Natanael Copa (1):
  Revert "pread/pwrite: backport fix"

Peter S. Mazinger (4):
  cancel.h: add generic file to ease cancellation support
  add cancellation to generic pread_write
  pread_write.c: make all archs use common code
  endian.h: add some handy macros to be used in syscalls

 Makefile.in  |   1 +
 include/cancel.h | 101 
 include/endian.h |  11 ++
 libc/sysdeps/linux/c6x/Makefile.arch |   3 +-
 libc/sysdeps/linux/c6x/pread_write.c | 103 
 libc/sysdeps/linux/common/pread_write.c  | 103 
 libc/sysdeps/linux/mips/pread_write.c| 116 ++
 libc/sysdeps/linux/powerpc/pread_write.c | 192 +-
 libc/sysdeps/linux/sh/pread_write.c  | 109 +++--
 libc/sysdeps/linux/xtensa/pread_write.c  | 195 +--
 10 files changed, 272 insertions(+), 662 deletions(-)
 create mode 100644 include/cancel.h
 delete mode 100644 libc/sysdeps/linux/c6x/pread_write.c

-- 
1.7.12

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Implementing {get,set,make,swap}context routines for ARM

2012-08-20 Thread Natanael Copa 
On Sun, Aug 19, 2012 at 1:51 AM, Mike Frysinger  wrote:
> On Tuesday 26 June 2012 05:29:29 Timon ter Braak wrote:
>> I am trying to build a gccgo (go language) cross compiler targetting an
>> ARM system. Go uses the context control routines for coorperative
>> multithreading. uClibc however does not implement them, so I am trying
>> to port the functions to uClibc.
>>
>> The routines are available in glibc and eglibc, and for other
>> architectures [1]. My port builds correctly, but segfaults while running.
>>
>> I noticed that (for example) the getcontext routine is quite different
>> from the setjmp routine shipped with uClibc. Can anybody give me some
>> pointers in what should be altered?
>>
>> A patch of my attempt is attached.
>
> you'll need to make them depend on UCLIBC_SUSV3_LEGACY as these functions have
> been removed from the latest POSIX spec and shouldn't be enabled/built by
> default

I'd like to have this too for mongrel2 but I would actually prefer to
see this implemented as a standalone library, similar to
argp-standalone.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] i386/bits/syscalls.h: allow immediate values as 6th syscall arg

2012-07-05 Thread Natanael Copa 
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.

Signed-off-by: Natanael Copa 
---
 libc/sysdeps/linux/i386/bits/syscalls.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libc/sysdeps/linux/i386/bits/syscalls.h 
b/libc/sysdeps/linux/i386/bits/syscalls.h
index 9fb4f35..566b5ac 100644
--- a/libc/sysdeps/linux/i386/bits/syscalls.h
+++ b/libc/sysdeps/linux/i386/bits/syscalls.h
@@ -136,7 +136,7 @@ __asm__ (
 #define ASMFMT_5(arg1, arg2, arg3, arg4, arg5) \
, "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5)
 #define ASMFMT_6(arg1, arg2, arg3, arg4, arg5, arg6) \
-   , "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5), "m" (arg6)
+   , "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5), "g" (arg6)
 
 #else /* !PIC */
 
-- 
1.7.11.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] i386/bits/syscalls.h: allow immediate values as 6th syscall arg

2012-07-05 Thread Natanael Copa 
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.
---
 libc/sysdeps/linux/i386/bits/syscalls.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libc/sysdeps/linux/i386/bits/syscalls.h 
b/libc/sysdeps/linux/i386/bits/syscalls.h
index 9fb4f35..566b5ac 100644
--- a/libc/sysdeps/linux/i386/bits/syscalls.h
+++ b/libc/sysdeps/linux/i386/bits/syscalls.h
@@ -136,7 +136,7 @@ __asm__ (
 #define ASMFMT_5(arg1, arg2, arg3, arg4, arg5) \
, "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5)
 #define ASMFMT_6(arg1, arg2, arg3, arg4, arg5, arg6) \
-   , "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5), "m" (arg6)
+   , "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5), "g" (arg6)
 
 #else /* !PIC */
 
-- 
1.7.11.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH,CFT] libc: add posix_fallocate()

2012-07-05 Thread Natanael Copa 
On Tue, Jun 19, 2012 at 12:05 PM, Natanael Copa  wrote:
> On Mon, Jun 18, 2012 at 5:27 PM, Bernhard Reutner-Fischer
>  wrote:
>> On 18 April 2012 14:45, Bernhard Reutner-Fischer  
>> wrote:
>>> On 17 April 2012 23:18, Khem Raj  wrote:
>>>> On Tue, Apr 17, 2012 at 12:30 AM, Bernhard Reutner-Fischer
>>>>  wrote:
>>>>> Signed-off-by: Bernhard Reutner-Fischer 
>>>>> ---
>>>>>  include/fcntl.h  |4 +-
>>>>>  libc/sysdeps/linux/common/Makefile.in|3 +-
>>>>>  libc/sysdeps/linux/common/bits/kernel-features.h |8 ++
>>>>>  libc/sysdeps/linux/common/posix_fallocate.c  |   43 
>>>>>  libc/sysdeps/linux/common/posix_fallocate64.c|   39 +++
>>>>>  libc/sysdeps/linux/common/stubs.c|4 +
>>>>>  test/.gitignore  |1 +
>>>>>  test/unistd/Makefile.in  |3 +
>>>>>  test/unistd/tst-posix_fallocate.c|  121 
>>>>> ++
>>>>>  9 files changed, 222 insertions(+), 4 deletions(-)
>>>>>  create mode 100644 libc/sysdeps/linux/common/posix_fallocate.c
>>>>>  create mode 100644 libc/sysdeps/linux/common/posix_fallocate64.c
>>>>>  create mode 100644 test/unistd/tst-posix_fallocate.c
>>>>>
>>>>
>>>> Looks ok to me. Did you test it on a 32bit and a 64 bit arch ?
>>>
>>> I compiled it on x86 and x86_64 where it generated reasonably looking code.
>>> No runtime-tests performed yet, thus Call For Testers..
>>>
>>>> mips would be interesting.
>>>
>>> mips and e.g. ppc* variants of bitness and endianess would indeed be
>>> interresting, yes.
>>
>> Anyone? :)
>
> I have it backported to 0.9.33.2.
>
>
> Works on x86_64 (the test case passes)
>
>
> on x86:
>
> The output of failed test is:
> 1st posix_fallocate call failed
>
> The error code appears to be "no such file or directory"
>
> I have a vauge memory about syscalls with N args (6?) beeing broken.

I have looked into this a bit. The generated assembly code is broke.
ebp should be set to zero but it is not. It looks like gcc gets
confused in referring to the local variable called "zero". Not sure if
its a gcc bug or why it happens.

Dump of assembler code for function posix_fallocate:
   0x4bdf2bb8 <+0>: push   %edi
   0x4bdf2bb9 <+1>: push   %esi
   0x4bdf2bba <+2>: push   %ecx
   0x4bdf2bbb <+3>: movl   $0x0,(%esp)# zero = 0
   0x4bdf2bc2 <+10>:xor%ecx,%ecx
   0x4bdf2bc4 <+12>:mov0x18(%esp),%edi
   0x4bdf2bc8 <+16>:mov0x14(%esp),%edx
   0x4bdf2bcc <+20>:mov0x10(%esp),%eax
   0x4bdf2bd0 <+24>:mov%ecx,%esi
   0x4bdf2bd2 <+26>:push   %ebx
   0x4bdf2bd3 <+27>:mov%eax,%ebx
   0x4bdf2bd5 <+29>:push   %ebp
   0x4bdf2bd6 <+30>:mov(%esp),%ebp
^^
I think it goes wrong here. Due to the previous push ebx, (%esp) no
longer points to the "zero" variable. and a bad value gets stored into
ebp. Syscall fails with "File too large".

I stepped myself here with gdb and setting ebp = 0 made the syscall
exit with success.

   0x4bdf2bd9 <+33>:mov$0x144,%eax
   0x4bdf2bde <+38>:int$0x80
   0x4bdf2be0 <+40>:pop%ebp
   0x4bdf2be1 <+41>:pop%ebx
   0x4bdf2be2 <+42>:cmp$0xf000,%eax
   0x4bdf2be7 <+47>:jbe0x4bdf2bed 
   0x4bdf2be9 <+49>:mov%eax,%esi
   0x4bdf2beb <+51>:neg%esi
   0x4bdf2bed <+53>:mov%esi,%eax
   0x4bdf2bef <+55>:pop%edx
   0x4bdf2bf0 <+56>:pop%esi
   0x4bdf2bf1 <+57>:pop%edi
   0x4bdf2bf2 <+58>:ret
End of assembler dump.

It is possible to work around it by allowing the 6th syscall arg be an
immediate value rather than force it to be a memory reference. I'd say
this is a good idea anyways.

diff --git a/libc/sysdeps/linux/i386/bits/syscalls.h b/libc/sysdeps/linux/i386/
bits/syscalls.h
index 9fb4f35..566b5ac 100644
--- a/libc/sysdeps/linux/i386/bits/syscalls.h
+++ b/libc/sysdeps/linux/i386/bits/syscalls.h
@@ -136,7 +136,7 @@ __asm__ (
 #define ASMFMT_5(arg1, arg2, arg3, arg4, arg5) \
, "a" (arg1), "c" (arg2), "d" (arg3), "S" (arg4), "D" (arg5)
 #define ASMFMT_6(arg1, arg2, arg3, arg4, arg5, arg6) \
-   , "a" (arg1), "c" (arg2), "d" (arg3), &q

backport pread/pwrite fix for 0.9.33 branch?

2012-06-27 Thread Natanael Copa 
Hi,

git-1.7.11 broke badly and I traced it to this:
https://bugs.busybox.net/show_bug.cgi?id=5258

I wonder if it might be an idea to (properly) backport the fix for 0.9.33.

I have a hackish patch here which seems to fix the issue for x86 atleast:
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/pread.patch?id=57e08ebf665e034d75ff86bbd92bcd3b71ca3869

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH,CFT] libc: add posix_fallocate()

2012-06-19 Thread Natanael Copa 
On Mon, Jun 18, 2012 at 5:27 PM, Bernhard Reutner-Fischer
 wrote:
> On 18 April 2012 14:45, Bernhard Reutner-Fischer  
> wrote:
>> On 17 April 2012 23:18, Khem Raj  wrote:
>>> On Tue, Apr 17, 2012 at 12:30 AM, Bernhard Reutner-Fischer
>>>  wrote:
>>>> Signed-off-by: Bernhard Reutner-Fischer 
>>>> ---
>>>>  include/fcntl.h                                  |    4 +-
>>>>  libc/sysdeps/linux/common/Makefile.in            |    3 +-
>>>>  libc/sysdeps/linux/common/bits/kernel-features.h |    8 ++
>>>>  libc/sysdeps/linux/common/posix_fallocate.c      |   43 
>>>>  libc/sysdeps/linux/common/posix_fallocate64.c    |   39 +++
>>>>  libc/sysdeps/linux/common/stubs.c                |    4 +
>>>>  test/.gitignore                                  |    1 +
>>>>  test/unistd/Makefile.in                          |    3 +
>>>>  test/unistd/tst-posix_fallocate.c                |  121 
>>>> ++
>>>>  9 files changed, 222 insertions(+), 4 deletions(-)
>>>>  create mode 100644 libc/sysdeps/linux/common/posix_fallocate.c
>>>>  create mode 100644 libc/sysdeps/linux/common/posix_fallocate64.c
>>>>  create mode 100644 test/unistd/tst-posix_fallocate.c
>>>>
>>>
>>> Looks ok to me. Did you test it on a 32bit and a 64 bit arch ?
>>
>> I compiled it on x86 and x86_64 where it generated reasonably looking code.
>> No runtime-tests performed yet, thus Call For Testers..
>>
>>> mips would be interesting.
>>
>> mips and e.g. ppc* variants of bitness and endianess would indeed be
>> interresting, yes.
>
> Anyone? :)

(resending since I forgot CC uclibc list)

I have it backported to 0.9.33.2.


Works on x86_64 (the test case passes)


on x86:

The output of failed test is:
1st posix_fallocate call failed

The error code appears to be "no such file or directory"

I have a vauge memory about syscalls with N args (6?) beeing broken.

Appears that posix_fallocate is the only syscall that uses all 6 args.


I wonder if it might be due to our syscalls.h patch for stack
unwinding, but I doubt that.
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/0007-libc-x86-fix-stack-unwinding-and-backtrace-informati.patch

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Incorrect/incomplete eventfd implementation?

2012-05-16 Thread Natanael Copa 
On Wed, May 16, 2012 at 3:55 PM, Natanael Copa  wrote:

>> I believe the implementation of eventfd recently added to uClibc (s. [1],
>> [2]) is incorrect.
..
> I think you are absolutely right. We bumped into this issue when
> upgrading to glib-2.32.

I should probably mention that all glib applications will hang in the
glib mainloop due to this eventfd issue with glib-2.32.

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Incorrect/incomplete eventfd implementation?

2012-05-16 Thread Natanael Copa 
On Wed, May 16, 2012 at 2:50 PM, Eugene Rudoy  wrote:
> Hi,
>
> I believe the implementation of eventfd recently added to uClibc (s. [1],
> [2]) is incorrect. It incorrectly assumes eventfd takes two arguments
> whereas in reality it expects just one. It's eventfd2 which expects two
> arguments. Furthermore it doesn't properly support kernel versions which do
> provide eventfd but don't provide eventfd2 (s. [3]). glibc seems to support
> all possible cases (s. [4]).

I think you are absolutely right. We bumped into this issue when
upgrading to glib-2.32.

I pasted our IRC discussion in our commit message. It explains a bit
why it is this way.

http://git.alpinelinux.org/cgit/aports/commit/main/libc0.9.32/eventfd.patch?id=3161576d06aa52a0dfbfdc13a539fa6d14100855

I suggest this patch but it will require kernel2.6.27+ kernel:
diff --git a/libc/sysdeps/linux/common/eventfd.c
b/libc/sysdeps/linux/common/eventfd.c
index cc3f3f0..06a26ee 100644
--- a/libc/sysdeps/linux/common/eventfd.c
+++ b/libc/sysdeps/linux/common/eventfd.c
@@ -14,5 +14,9 @@
  * eventfd()
  */
 #ifdef __NR_eventfd
+#ifdef __NR_eventfd2
+#undef  __NR_eventfd
+#define __NR_eventfd __NR_eventfd2
+#endif
 _syscall2(int, eventfd, int, count, int, flags)
 #endif


> Best regards,
> Gene
>
> [1]
> http://git.uclibc.org/uClibc/commit/?id=9ed163dc0eaebe8734c35b356c406e9eb1c68d76
> [2] http://lists.uclibc.org/pipermail/uclibc/2011-October/045877.html
> [3]
> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/kernel-features.h;h=1090f8a809d7d14986722f796f96a75df4f7074d;hb=HEAD#l452
> [4]
> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/eventfd.c;h=4a0e8bc0caa676cdbb5f80a06e43129a0e72;hb=HEAD
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: gentoo once again

2012-04-27 Thread Natanael Copa 
On Thu, Apr 26, 2012 at 10:48 PM, Mike Frysinger  wrote:
> On Thursday 26 April 2012 16:17:11 Piotr Gluszenia Slawinski wrote:
>
>> also glib is set hard masked in profile even though uclibc can have locale
>> now, but this is minor compared to udev..
>
> that's a much bigger can-o-worms

Maybe have a look at Alpine Linux if youre on x86 or x86_64 and want
uclibc+glib.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Issue with group limit

2012-04-24 Thread Natanael Copa 
Hi,

I have setup a new build server for the upcoming Alpine Linux v2.4
release and bumped into an issue with a limit (or bug?) in uclibc.

The build failed when trying to add a user called "postgrey". From the
build log:

>>> postgrey: Creating user postgrey
adduser: unknown group nogroup

The group "nogroup" is there have have worked up til now.

>From the /etc/groups:
nogroup:x:65533:asterisk,clamav,ldap,dovecot,dovenull,freeswitch,kamailio,vlc,radiusd,icecast,ircservices,mpd,nagios,nsd,ntop,pdnsd

Checking what groups asterisk belongs to:

$ groups asterisk
65533groups: unknown ID 65533
 dialout

So i think this happens due to the way the /etc/group is parsed. When
the line passes a limit (128 chars?) the parser will simply skip this
group.

Was reported earlier:
http://bugs.alpinelinux.org/issues/733

I suppose I could patch uclibc to extend the line buffer length
__UCLIBC_PWD_BUFFER_SIZE__ for now. Where is it defined?

Any ideas how to fix it properly?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: mdadm bulit with uClibc always fail on '--assemble --scan' (-1 EINVAL (Invalid argument)), the glibc one works.

2012-03-16 Thread Natanael Copa 
On Fri, Mar 16, 2012 at 6:33 PM, Piotr Karbowski
 wrote:
> On 03/16/2012 06:15 PM, Natanael Copa wrote:
>>
>> On Thu, Mar 15, 2012 at 2:55 PM, Piotr Karbowski
>>   wrote:
>>
>> We have not had any issues with mdadm on Alpine Linux. We had issues
>> due to a bug in mdadm a year ago or so but that was not related uclibc
>> at all. I use mdadm on my work desktop and various servers. Both x86
>> and x86_64.
>>
>> Is your uclibc configured with large file support?
>
>
> Indeed it is. Can you check the 'mdadm --assemble --scan' on initramfs
> level?

Not at the office atm.

This happens everytime I boot:
http://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in#n201

You can download and test your self if you want. The mini iso should
be less than 60MB.

http://alpinelinux.org/downloads


> Or maybe can you provide me a 32bit static mdadm so I can test in my
> vm if it fail or not. Seems like the binary does work when running on
> 'regular' system, with udev running.

I don't start udev in initramfs. I only have dynamically linked.
You can unpack the alpine linux packages with tar -zxf if you want
test yourself.
http://dl-2.alpinelinux.org/alpine/edge/main/x86/


>
> -- Piotr.
>



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: mdadm bulit with uClibc always fail on '--assemble --scan' (-1 EINVAL (Invalid argument)), the glibc one works.

2012-03-16 Thread Natanael Copa 
On Thu, Mar 15, 2012 at 2:55 PM, Piotr Karbowski
 wrote:
> On 03/13/2012 05:55 PM, Piotr Karbowski wrote:
>> [cut]
>
> I just tested version 2.6.9 which is included in buildroot - the same issue.
> However I bulit the 2.6.9 with dietlibc and it does work which suggest that
> the problem lays deep inside uclibc.

We have not had any issues with mdadm on Alpine Linux. We had issues
due to a bug in mdadm a year ago or so but that was not related uclibc
at all. I use mdadm on my work desktop and various servers. Both x86
and x86_64.

Is your uclibc configured with large file support?


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: tar-1.26 not unpacking archives with symlinks?

2012-03-14 Thread Natanael Copa 
(resending due to uclibc blocked the uncompressed config.log)

On Wed, Mar 14, 2012 at 3:44 AM, Mike Frysinger  wrote:
> On Tuesday 13 March 2012 17:40:38 Natanael Copa wrote:
>> I have seen this too and it only happens when the symlink is extracted
>> before the file it points to.
>>
>> To reproduce:
>>   touch myfile
>>   ln -s myfile mylink
>>   tar -cf testcase1.tar mylink myfile
>
> i vaguely recall seeing this before and the issue came down to tar not
> detecting the right features.  might want to compare the config.log output
> between glibc and uclibc to see how they differ.

I don't have an glibc box handy available. Attached is the config.log
when building with uclibc on 84_64.

-- 
Natanael Copa


config.log.bz2
Description: BZip2 compressed data
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: tar-1.26 not unpacking archives with symlinks?

2012-03-13 Thread Natanael Copa 
On Thu, Mar 1, 2012 at 5:45 PM, Bernhard Reutner-Fischer
 wrote:
> On Feb 29, 2012 6:33 PM, "Ed W"  wrote:
>>
>> Hi, I'm hitting an error when trying to unpack archives with the recently
> unmasked tar-1.26.  Basically any symlinks in the archive trigger an
> "unknown file" error.  This prevents me using emerge -k amongst other things
>>
>> I only see this on uclibc-0.9.33 based system, not on the build host
> which uses glibc amd64
>>
>> Can anyone else repro this and shed any light on what the problem might
> be?  Problem in tar or uclibc?
>>
>
> Can you provide a tarbalk with one file that exhibits the problem, plus an
> strafe of the attempt to unpack it?

I have seen this too and it only happens when the symlink is extracted
before the file it points to.

To reproduce:
  touch myfile
  ln -s myfile mylink
  tar -cf testcase1.tar mylink myfile

If the file comes first (tar -cf testcase2.tar myfile mylink) it will work.

The eopen("../testcase.tar", O_RDONLY|O_LARGEFILE) = 3
read(3, "mylink\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
10240) = 10240
fstat64(3, {st_mode=S_IFREG|0644, st_size=10240, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=10240, ...}) = 0
clock_gettime(CLOCK_REALTIME, {1331674689, 93257}) = 0
open("/etc/passwd", O_RDONLY)   = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, 0x5e47954c) = -1 ENOTTY (Inappropriate ioctl for device)
brk(0x14e71000) = 0x14e71000
read(4, "root:x:0:0:root:/root:/bin/ash\nb"..., 8192) = 2853
close(4)= 0
open("/etc/group", O_RDONLY)= 4
ioctl(4, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, 0x5e47954c) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "root:x:0:root\nbin:x:1:root,bin,d"..., 8192) = 1158
close(4)= 0
symlinkat("myfile", AT_FDCWD, "mylink") = 0
fstatat64(AT_FDCWD, "mylink", {st_mode=S_IFLNK|0777, st_size=6, ...},
AT_SYMLINK_NOFOLLOW) = 0
utimensat(AT_FDCWD, "mylink", {{1331674689, 930453230}, {1331674345,
0}}, AT_SYMLINK_NOFOLLOW) = 0
fstatat64(AT_FDCWD, "mylink", {st_mode=S_IFLNK|0777, st_size=6, ...},
AT_SYMLINK_NOFOLLOW) = 0
fchmodat(AT_FDCWD, "mylink", 0755)  = -1 ENOENT (No such file or directory)
write(2, "tar", 3tar)  = 3
write(2, ": ", 2: )   = 2
write(2, "mylink", 6mylink)   = 6
write(2, ": Cannot change mode to ", 24: Cannot change mode to ) = 24
write(2, "rwxr-xr-x", 9rwxr-xr-x)= 9
write(2, ": ", 2: )   = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
)   = 1
openat(AT_FDCWD, "myfile",
O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC,
0644) = 4
dup2(4, 4)  = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
utimensat(4, NULL, {{1331674689, 933786545}, {1331674327, 0}}, 0) = 0
close(4)= 0
clock_gettime(CLOCK_REALTIME, {1331674689, 938422399}) = 0
clock_gettime(CLOCK_REALTIME, {1331674689, 938497339}) = 0
close(3)= 0
write(2, "tar", 3tar)  = 3
write(2, ": ", 2: )   = 2
write(2, "Exiting with failure status due "..., 50Exiting with failure
status due to previous errors) = 50
write(2, "\n", 1
)   = 1
close(1)    = 0
close(2)= 0
exit_group(2)   = ?
rror message from tar:
tar: mylink: Cannot change mode to rwxr-xr-x: No such file or directory
tar: Exiting with failure status due to previous errors


It's the fchmodat() that fails which makes me wonder why it works on GNU libc.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: stdio.h and open_memstream()

2012-01-17 Thread Natanael Copa 
On Tue, Jan 17, 2012 at 10:31 AM, Natanael Copa  wrote:
> On Sat, Jan 14, 2012 at 12:36 AM, Khem Raj  wrote:
>> On Fri, Jan 13, 2012 at 2:24 PM, Natanael Copa  
>> wrote:
>>> uclibc-0.9.32.1
>>>
>>> dev32-edge:~/testcase$ cat open_memstream.c
>>> #include 
>>>
>>> int main()
>>> {
>>>        return open_memstream(NULL, 0);
>>> }
>>> dev32-edge:~/testcase$ gcc -Wall -Werror open_memstream.c
>>> open_memstream.c: In function 'main':
>>> open_memstream.c:5:2: error: implicit declaration of function
>>> 'open_memstream' [-Werror=implicit-function-declaration]
>>> cc1: all warnings being treated as errors
>>>
>>> Something is wrong. open_memstream should be defined in stdio.h
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/open_memstream.html
>>>
>>> from the config:
>>> UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
>>>
>>> and to be sure:
>>> $ nm -D /lib/libc.so.0.9.32 | grep open_memstream
>>> 00028feb T open_memstream
>>>
>>> So open_memstream() is really there - and it work without -Wall
>>> -Werror but stdio.h header or some other define appears to be wrong.
>>>
>>> This is needed to compile libdrm-2.4.30
>>
>> What happens if you add -D_GNU_SOURCE to compiler cmdline ?
>
> $ gcc -Wall -Werror -D_GNU_SOURCE open_memstream.c
> open_memstream.c: In function 'main':
> open_memstream.c:5:2: error: return makes integer from pointer without
> a cast [-Werror]
> cc1: all warnings being treated as errors

Bah... it helps to read the error message...

Yes, it seems to work with -D_GNU_SOURCE when typecasted.

Need to figure out what in libdrm disables it or if its my cflags that
removes -std=... or something.

Thanks!


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: stdio.h and open_memstream()

2012-01-17 Thread Natanael Copa 
On Sat, Jan 14, 2012 at 12:36 AM, Khem Raj  wrote:
> On Fri, Jan 13, 2012 at 2:24 PM, Natanael Copa  
> wrote:
>> uclibc-0.9.32.1
>>
>> dev32-edge:~/testcase$ cat open_memstream.c
>> #include 
>>
>> int main()
>> {
>>        return open_memstream(NULL, 0);
>> }
>> dev32-edge:~/testcase$ gcc -Wall -Werror open_memstream.c
>> open_memstream.c: In function 'main':
>> open_memstream.c:5:2: error: implicit declaration of function
>> 'open_memstream' [-Werror=implicit-function-declaration]
>> cc1: all warnings being treated as errors
>>
>> Something is wrong. open_memstream should be defined in stdio.h
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/open_memstream.html
>>
>> from the config:
>> UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
>>
>> and to be sure:
>> $ nm -D /lib/libc.so.0.9.32 | grep open_memstream
>> 00028feb T open_memstream
>>
>> So open_memstream() is really there - and it work without -Wall
>> -Werror but stdio.h header or some other define appears to be wrong.
>>
>> This is needed to compile libdrm-2.4.30
>
> What happens if you add -D_GNU_SOURCE to compiler cmdline ?

$ gcc -Wall -Werror -D_GNU_SOURCE open_memstream.c
open_memstream.c: In function 'main':
open_memstream.c:5:2: error: return makes integer from pointer without
a cast [-Werror]
cc1: all warnings being treated as errors


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

stdio.h and open_memstream()

2012-01-13 Thread Natanael Copa 
uclibc-0.9.32.1

dev32-edge:~/testcase$ cat open_memstream.c
#include 

int main()
{
return open_memstream(NULL, 0);
}
dev32-edge:~/testcase$ gcc -Wall -Werror open_memstream.c
open_memstream.c: In function 'main':
open_memstream.c:5:2: error: implicit declaration of function
'open_memstream' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors

Something is wrong. open_memstream should be defined in stdio.h
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open_memstream.html

from the config:
UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y

and to be sure:
$ nm -D /lib/libc.so.0.9.32 | grep open_memstream
00028feb T open_memstream

So open_memstream() is really there - and it work without -Wall
-Werror but stdio.h header or some other define appears to be wrong.

This is needed to compile libdrm-2.4.30

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] sys/queue.h: update to eglibc version

2011-12-16 Thread Natanael Copa 
Xen needs SIMPLEQ_* queue types which was not provided from the old
uclibc queue.h.

Use same implementation as eglibc.
Grabbed from: http://www.eglibc.org/svn/trunk/libc/misc/sys/queue.h

Signed-off-by: Natanael Copa 
---
 include/sys/queue.h |  842 ---
 1 files changed, 399 insertions(+), 443 deletions(-)

diff --git a/include/sys/queue.h b/include/sys/queue.h
index 0ea0c11..daf4553 100644
--- a/include/sys/queue.h
+++ b/include/sys/queue.h
@@ -1,4 +1,4 @@
-/*-
+/*
  * Copyright (c) 1991, 1993
  * The Regents of the University of California.  All rights reserved.
  *
@@ -10,7 +10,7 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
- * 4. Neither the name of the University nor the names of its contributors
+ * 3. Neither the name of the University nor the names of its contributors
  *may be used to endorse or promote products derived from this software
  *without specific prior written permission.
  *
@@ -27,38 +27,24 @@
  * SUCH DAMAGE.
  *
  * @(#)queue.h 8.5 (Berkeley) 8/20/94
- * $FreeBSD: src/sys/sys/queue.h,v 1.68 2006/10/24 11:20:29 ru Exp $
  */
 
-#ifndef _SYS_QUEUE_H_
+#ifndef_SYS_QUEUE_H_
 #define_SYS_QUEUE_H_
 
-#include 
-
 /*
- * This file defines four types of data structures: singly-linked lists,
- * singly-linked tail queues, lists and tail queues.
- *
- * A singly-linked list is headed by a single forward pointer. The elements
- * are singly linked for minimum space and pointer manipulation overhead at
- * the expense of O(n) removal for arbitrary elements. New elements can be
- * added to the list after an existing element or at the head of the list.
- * Elements being removed from the head of the list should use the explicit
- * macro for this purpose for optimum efficiency. A singly-linked list may
- * only be traversed in the forward direction.  Singly-linked lists are ideal
- * for applications with large datasets and few or no removals or for
- * implementing a LIFO queue.
+ * This file defines five types of data structures: singly-linked lists,
+ * lists, simple queues, tail queues, and circular queues.
  *
- * A singly-linked tail queue is headed by a pair of pointers, one to the
- * head of the list and the other to the tail of the list. The elements are
- * singly linked for minimum space and pointer manipulation overhead at the
- * expense of O(n) removal for arbitrary elements. New elements can be added
- * to the list after an existing element, at the head of the list, or at the
- * end of the list. Elements being removed from the head of the tail queue
- * should use the explicit macro for this purpose for optimum efficiency.
- * A singly-linked tail queue may only be traversed in the forward direction.
- * Singly-linked tail queues are ideal for applications with large datasets
- * and few or no removals or for implementing a FIFO queue.
+ * A singly-linked list is headed by a single forward pointer. The
+ * elements are singly linked for minimum space and pointer manipulation
+ * overhead at the expense of O(n) removal for arbitrary elements. New
+ * elements can be added to the list after an existing element or at the
+ * head of the list.  Elements being removed from the head of the list
+ * should use the explicit macro for this purpose for optimum
+ * efficiency. A singly-linked list may only be traversed in the forward
+ * direction.  Singly-linked lists are ideal for applications with large
+ * datasets and few or no removals or for implementing a LIFO queue.
  *
  * A list is headed by a single forward pointer (or an array of forward
  * pointers for a hash table header). The elements are doubly linked
@@ -67,6 +53,13 @@
  * or after an existing element or at the head of the list. A list
  * may only be traversed in the forward direction.
  *
+ * A simple queue is headed by a pair of pointers, one the head of the
+ * list and the other to the tail of the list. The elements are singly
+ * linked to save space, so elements can only be removed from the
+ * head of the list. New elements can be added to the list after
+ * an existing element, at the head of the list, or at the end of the
+ * list. A simple queue may only be traversed in the forward direction.
+ *
  * A tail queue is headed by a pair of pointers, one to the head of the
  * list and the other to the tail of the list. The elements are doubly
  * linked so that an arbitrary element can be removed without a need to
@@ -74,67 +67,85 @@
  * after an existing element, at the head of the list, or at the end of
  * the list. A tail queue may be traversed in either direction.
  *
- * For details on the use of these macros, see the queue(3) manual page.
- *
- *
- * SLIST   LISTSTAILQ  TAILQ
- * _HEAD

Re: [PATCH] sys/queue.h: update to eglibc version

2011-12-16 Thread Natanael Copa 
On Fri, Dec 16, 2011 at 10:53 AM, Natanael Copa  wrote:
> Xen needs SIMPLEQ_* queue types which was not provided from the old
> uclibc queue.h.
>
> Use same implementation as eglibc.
> Grabbed from: http://www.eglibc.org/svn/trunk/libc/misc/sys/queue.h

Forgot signed-off. sorry.

Will resend.

(Is there some way to add always-signed-off to .git/config?)

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] sys/queue.h: update to eglibc version

2011-12-16 Thread Natanael Copa 
Xen needs SIMPLEQ_* queue types which was not provided from the old
uclibc queue.h.

Use same implementation as eglibc.
Grabbed from: http://www.eglibc.org/svn/trunk/libc/misc/sys/queue.h
---
 include/sys/queue.h |  842 ---
 1 files changed, 399 insertions(+), 443 deletions(-)

diff --git a/include/sys/queue.h b/include/sys/queue.h
index 0ea0c11..daf4553 100644
--- a/include/sys/queue.h
+++ b/include/sys/queue.h
@@ -1,4 +1,4 @@
-/*-
+/*
  * Copyright (c) 1991, 1993
  * The Regents of the University of California.  All rights reserved.
  *
@@ -10,7 +10,7 @@
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
- * 4. Neither the name of the University nor the names of its contributors
+ * 3. Neither the name of the University nor the names of its contributors
  *may be used to endorse or promote products derived from this software
  *without specific prior written permission.
  *
@@ -27,38 +27,24 @@
  * SUCH DAMAGE.
  *
  * @(#)queue.h 8.5 (Berkeley) 8/20/94
- * $FreeBSD: src/sys/sys/queue.h,v 1.68 2006/10/24 11:20:29 ru Exp $
  */
 
-#ifndef _SYS_QUEUE_H_
+#ifndef_SYS_QUEUE_H_
 #define_SYS_QUEUE_H_
 
-#include 
-
 /*
- * This file defines four types of data structures: singly-linked lists,
- * singly-linked tail queues, lists and tail queues.
- *
- * A singly-linked list is headed by a single forward pointer. The elements
- * are singly linked for minimum space and pointer manipulation overhead at
- * the expense of O(n) removal for arbitrary elements. New elements can be
- * added to the list after an existing element or at the head of the list.
- * Elements being removed from the head of the list should use the explicit
- * macro for this purpose for optimum efficiency. A singly-linked list may
- * only be traversed in the forward direction.  Singly-linked lists are ideal
- * for applications with large datasets and few or no removals or for
- * implementing a LIFO queue.
+ * This file defines five types of data structures: singly-linked lists,
+ * lists, simple queues, tail queues, and circular queues.
  *
- * A singly-linked tail queue is headed by a pair of pointers, one to the
- * head of the list and the other to the tail of the list. The elements are
- * singly linked for minimum space and pointer manipulation overhead at the
- * expense of O(n) removal for arbitrary elements. New elements can be added
- * to the list after an existing element, at the head of the list, or at the
- * end of the list. Elements being removed from the head of the tail queue
- * should use the explicit macro for this purpose for optimum efficiency.
- * A singly-linked tail queue may only be traversed in the forward direction.
- * Singly-linked tail queues are ideal for applications with large datasets
- * and few or no removals or for implementing a FIFO queue.
+ * A singly-linked list is headed by a single forward pointer. The
+ * elements are singly linked for minimum space and pointer manipulation
+ * overhead at the expense of O(n) removal for arbitrary elements. New
+ * elements can be added to the list after an existing element or at the
+ * head of the list.  Elements being removed from the head of the list
+ * should use the explicit macro for this purpose for optimum
+ * efficiency. A singly-linked list may only be traversed in the forward
+ * direction.  Singly-linked lists are ideal for applications with large
+ * datasets and few or no removals or for implementing a LIFO queue.
  *
  * A list is headed by a single forward pointer (or an array of forward
  * pointers for a hash table header). The elements are doubly linked
@@ -67,6 +53,13 @@
  * or after an existing element or at the head of the list. A list
  * may only be traversed in the forward direction.
  *
+ * A simple queue is headed by a pair of pointers, one the head of the
+ * list and the other to the tail of the list. The elements are singly
+ * linked to save space, so elements can only be removed from the
+ * head of the list. New elements can be added to the list after
+ * an existing element, at the head of the list, or at the end of the
+ * list. A simple queue may only be traversed in the forward direction.
+ *
  * A tail queue is headed by a pair of pointers, one to the head of the
  * list and the other to the tail of the list. The elements are doubly
  * linked so that an arbitrary element can be removed without a need to
@@ -74,67 +67,85 @@
  * after an existing element, at the head of the list, or at the end of
  * the list. A tail queue may be traversed in either direction.
  *
- * For details on the use of these macros, see the queue(3) manual page.
- *
- *
- * SLIST   LISTSTAILQ  TAILQ
- * _HEAD   +   +   +   +
- * _HEAD

Re: How about 0.9.32.1

2011-10-05 Thread Natanael Copa 
On Fri, Sep 2, 2011 at 5:03 PM, Bernhard Reutner-Fischer
 wrote:
>
> On Sep 1, 2011 9:17 AM, "Natanael Copa"  wrote:
>>
>> Hi,
>>
>> It seems like the 0.9.32 branch has been stabilized a bit. No commits
>> since 2011-06-29.
>>
>> How about just tag it as 0.9.32.1 and create a new release?
>
> There are some commits to master that should be cherry-picked into the
> branch before.

Whats the status here?

Still no commits in 0.9.32 branch since 2011-06-29. I still think its
better to just release what you have - even if its not perfect. It
would just mean that you need manually patch "some" commits rather
than 16 + "some" commits.

So since nobody has time to do the few commits from master I suggest
you just release what you have for 0.9.32.1 and save the others for
0.9.32.2

At some point you need to shoot the engineer and just release the product.

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

How about 0.9.32.1

2011-09-01 Thread Natanael Copa 
Hi,

It seems like the 0.9.32 branch has been stabilized a bit. No commits
since 2011-06-29.

How about just tag it as 0.9.32.1 and create a new release?

Thanks!

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] getaddrinfo: allow numeric service without any hints

2011-06-08 Thread Natanael Copa 
This appears to correspond to what glibc does and this fixes an
issue with iptables-1.4.11 with udp and raw port numbers.

(see http://bugzilla.netfilter.org/show_bug.cgi?id=721)

This fixes #3841
https://bugs.busybox.net/show_bug.cgi?id=3841
---
 libc/inet/getaddrinfo.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/libc/inet/getaddrinfo.c b/libc/inet/getaddrinfo.c
index 1a77c51..e7511f6 100644
--- a/libc/inet/getaddrinfo.c
+++ b/libc/inet/getaddrinfo.c
@@ -820,13 +820,6 @@ getaddrinfo(const char *name, const char *service,
if (hints->ai_flags & AI_NUMERICSERV)
return EAI_NONAME;
gaih_service.num = -1;
-   } else {
-   /*
-* Can't specify a numerical socket unless a protocol
-* family was given.
-*/
-   if (hints->ai_socktype == 0 && hints->ai_protocol == 0)
-   return EAI_SERVICE;
}
pservice = &gaih_service;
} else
-- 
1.7.5.4

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: A modest proposal: call it 1.0

2011-02-12 Thread Natanael Copa 
On Fri, Feb 11, 2011 at 9:37 PM, Khem Raj  wrote:

> Its just not number IMHO. Its a statement which reflects our progress and
> stating 1.0 is right at present. We have had major feature in form of nptl 
> and I have
> always been suggesting that we call it 1.0 when we release nptl.
>
> TODO list can be adjusted to be part of 1.2 for SuS compatibility

+1

NTPL itself definitively qualifies an 1.0, even if it was only
supported for 1 arch.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 4/5] Add protected symbols support for all architectures

2011-01-13 Thread Natanael Copa 
On Wed, Jan 12, 2011 at 4:48 PM, Carmelo AMOROSO  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/12/2011 4:31 PM, Natanael Copa wrote:
>>
>> this didnt apply against current git master?
...
> Hi you need to apply also the patch 1,2 and 3 that revert the arch
> specific implementation (sh, asrm i386).

I did.

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 4/5] Add protected symbols support for all architectures

2011-01-12 Thread Natanael Copa 
On Wed, Jan 12, 2011 at 12:22 PM, Carmelo AMOROSO
 wrote:
> From: Salvatore Cro 
>
> Protected symbols are global symbols for which interposition is not allowed.
> We manage them in generic _dl_lookup_hash function. To handle protected 
> symbols
> we need to get a reference to the module that defines the symbol itself.
> So we pass a new parameter 'struct symbol_ref' to the __dl_lookup_hash
> that is defined as below:
>
> struct symbol_ref {
>  const ElfW(Sym) *sym;
>  struct elf_resolve *tpnt;
> };
>
> The tpnt field is used as an ouput parameter and refers to the module which 
> defines
> the protected symbol.
> Further it can be used as output parameter for TLS relocations and FDPIC case.
> The sym field is instead used as an input parameter to detect the visibility 
> of the
> symbol we are looking-up.
> In this way we get rid of different signatures for _dl_lookup_hash, allowing 
> to remove
> the _dl_find_hash wrapper.
> This new structure is also suitable for prelink integration.
>
> Signed-off-by: Salvatore Cro 
> Signed-off-by: Carmelo Amoroso 
> ---
>  ldso/include/dl-hash.h        |   16 
>  ldso/ldso/arm/elfinterp.c     |    6 +-
>  ldso/ldso/avr32/elfinterp.c   |   13 +++--
>  ldso/ldso/bfin/elfinterp.c    |   18 --
>  ldso/ldso/cris/elfinterp.c    |    5 -
>  ldso/ldso/dl-hash.c           |   20 
>  ldso/ldso/i386/elfinterp.c    |    6 +-
>  ldso/ldso/m68k/elfinterp.c    |   15 ---
>  ldso/ldso/mips/elfinterp.c    |    6 +-
>  ldso/ldso/powerpc/elfinterp.c |   20 +++-
>  ldso/ldso/sh/elfinterp.c      |   10 +++---
>  ldso/ldso/sh64/elfinterp.c    |    7 +--
>  ldso/ldso/sparc/elfinterp.c   |   24 +---
>  ldso/ldso/x86_64/elfinterp.c  |   20 +++-
>  ldso/ldso/xtensa/elfinterp.c  |   11 ++-
>  ldso/libdl/libdl.c            |    7 ---
>  16 files changed, 123 insertions(+), 81 deletions(-)

this didnt apply against current git master?

maybe needs a rebase?

-nc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] libm/x86_64: implement fesetround

2010-12-09 Thread Natanael Copa 
sorry late reply.

On Thu, Dec 2, 2010 at 12:25 AM, Bernhard Reutner-Fischer
 wrote:
> On Sun, Nov 28, 2010 at 07:20:04PM +0000, Natanael Copa wrote:
>>from glibc
>
> mhm. I've ripped out SSE support for i386. I'd much prefer to have the
> complete set of fenv for x86_64, not just fesetround. I think it should
> be possible to support both i386 and x86_64 with the same sources. Could
> you have a look?

So far I have only seen the need for fenv() (qemu needs it) and we
have compiled almost all alpine linux packages for x86_64.

I can look at it eventually if you want, but it wont be anytime soon.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

2010-11-29 Thread Natanael Copa 
On Mon, Nov 29, 2010 at 8:58 AM, Michael Deutschmann
 wrote:
> Is this going to be an ABI-breaking release?
>
> (I'm prepared either way.  My 0.9.30.3 to 0.9.31 rollover went just fine.)

Switching to NPTL will break ABI.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] libm/x86_64: implement fesetround

2010-11-28 Thread Natanael Copa 
from glibc

Signed-off-by: Natanael Copa 
---
 libm/x86_64/Makefile.arch |   24 +++
 libm/x86_64/fesetround.c  |   46 +
 2 files changed, 70 insertions(+), 0 deletions(-)
 create mode 100644 libm/x86_64/Makefile.arch
 create mode 100644 libm/x86_64/fesetround.c

diff --git a/libm/x86_64/Makefile.arch b/libm/x86_64/Makefile.arch
new file mode 100644
index 000..e1be961
--- /dev/null
+++ b/libm/x86_64/Makefile.arch
@@ -0,0 +1,24 @@
+# Makefile for uClibc
+#
+# Copyright (C) 2000-2008 Erik Andersen 
+#
+# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
+#
+# The routines included in this math library are derived from
+# glibc's libm.
+#
+
+ifeq ($(UCLIBC_HAS_FENV),y)
+libm_ARCH_SRC:=$(wildcard $(libm_ARCH_DIR)/*.c)
+libm_ARCH_OBJ:=$(patsubst 
$(libm_ARCH_DIR)/%.c,$(libm_ARCH_OUT)/%.o,$(libm_ARCH_SRC))
+endif
+
+libm_ARCH_OBJS:=$(libm_ARCH_OBJ)
+
+ifeq ($(DOPIC),y)
+libm-a-y+=$(libm_ARCH_OBJS:.o=.os)
+else
+libm-a-y+=$(libm_ARCH_OBJS)
+endif
+libm-so-y+=$(libm_ARCH_OBJS:.o=.os)
+
diff --git a/libm/x86_64/fesetround.c b/libm/x86_64/fesetround.c
new file mode 100644
index 000..3d2ef4c
--- /dev/null
+++ b/libm/x86_64/fesetround.c
@@ -0,0 +1,46 @@
+/* Set current rounding direction.
+   Copyright (C) 2001, 2005 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#include 
+
+int
+fesetround (int round)
+{
+  unsigned short int cw;
+  int mxcsr;
+
+  if ((round & ~0xc00) != 0)
+/* ROUND is no valid rounding mode.  */
+return 1;
+
+  /* First set the x87 FPU.  */
+  __asm__ ("fnstcw %0" : "=m" (*&cw));
+  cw &= ~0xc00;
+  cw |= round;
+  __asm__ ("fldcw %0" : : "m" (*&cw));
+
+  /* And now the MSCSR register for SSE, the precision is at different bit
+ positions in the different units, we need to shift it 3 bits.  */
+  __asm__ ("stmxcsr %0" : "=m" (*&mxcsr));
+  mxcsr &= ~ 0x6000;
+  mxcsr |= round << 3;
+  __asm__ ("ldmxcsr %0" : : "m" (*&mxcsr));
+
+  return 0;
+}
-- 
1.7.3.2

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

2010-11-28 Thread Natanael Copa 
On Sun, Nov 28, 2010 at 12:34 AM, Bernhard Reutner-Fischer
 wrote:
> Hi,
>
> I will have a look at the strtoq ASAP. Feel free to test current master
> which is what RC1 will essentially be.

I would like to have the 2 patches in here
https://bugs.busybox.net/show_bug.cgi?id=2713 too.

I will *try* allocate some time to take a closer look at the protected
symbol cleanup next week. I looked at it abit and it seems to be more
complicated than I first thought.

I have also a fesetround() for x86_64 comming up. Its needed for building qemu.

Thanks!

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] libc: fix strtoq

2010-11-26 Thread Natanael Copa 
strtoq should always return a quad_t and be an alias of strtol on
64 bit and strtoll on 32 bit.

Signed-off-by: Natanael Copa 
---
 include/stdlib.h |2 +-
 libc/stdlib/stdlib.c |3 +++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/include/stdlib.h b/include/stdlib.h
index ce92ccd..300edf0 100644
--- a/include/stdlib.h
+++ b/include/stdlib.h
@@ -214,7 +214,7 @@ __END_NAMESPACE_STD
 
 /* Convert a string to a quadword integer.  */
 __extension__
-extern long long int strtoq (__const char *__restrict __nptr,
+extern quad_t strtoq (__const char *__restrict __nptr,
 char **__restrict __endptr, int __base)
  __THROW __nonnull ((1)) __wur;
 /* Convert a string to an unsigned quadword integer.  */
diff --git a/libc/stdlib/stdlib.c b/libc/stdlib/stdlib.c
index ad0c4aa..4d608ee 100644
--- a/libc/stdlib/stdlib.c
+++ b/libc/stdlib/stdlib.c
@@ -342,6 +342,9 @@ extern __typeof(__XL_NPP(strtol)) __XL_NPP(strtoll);
 libc_hidden_proto(__XL_NPP(strtoll))
 strong_alias(__XL_NPP(strtol),__XL_NPP(strtoll))
 libc_hidden_def(__XL_NPP(strtoll))
+#if !defined(L_strtol_l)
+strong_alias(strtol,strtoq)
+#endif
 #endif
 
 #endif
-- 
1.7.3.2

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

strtoq on x86_64

2010-11-26 Thread Natanael Copa 
Hi,

We are working on porting Alpine Linux to x86_64 (with nptl). In
addition to __GI___chk_fail fix[1] and protected symbols
"workaround"[2] we have so far bumped into an issue with strtoq. pcre
fails to build during linking on missing symbol strtoq. The configure
script only did a compile check when testing for strtoq() and not link
test. Changing[3] the configure script to do link test makes it build
successfully.

Second issue is asterisk, which also seems to be related to strtoq.

   [CC] chan_sip.c -> chan_sip.o
In file included from
/home/ncopa/aports/main/asterisk/src/asterisk-1.8.0/include/asterisk.h:27:0,
 from chan_sip.c:209:
/home/ncopa/aports/main/asterisk/src/asterisk-1.8.0/include/asterisk/compat.h:129:10:
error: conflicting types for 'strtoq'
/usr/include/stdlib.h:211:22: note: previous declaration of 'strtoq' was here
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

strtoq seems to be a strong alias to strtoll

This testcase works on x86 but not x86_64:

$ cat strtoq.c
int main() { char* e; return strtoq("100", &e, 10); }
$ gcc strtoq.c
/tmp/ccEh3NhS.o: In function `main':
strtoq.c:(.text+0x30): undefined reference to `strtoq'
collect2: ld returned 1 exit status

Doing the same with strtoll works though.

There are some ifdefs in libc/stdlib.c[4] that prevents the strtoq
alias be made. Exactly why i dont know really, but i think we either
need to create a correct alias for x86_64 or remove the strtoq def in
the header file.

-- 
Natanael Copa

[1] https://bugs.busybox.net/show_bug.cgi?id=2713
[2] http://lists.uclibc.org/pipermail/uclibc/2010-April/043935.html
[3] http://git.alpinelinux.org/cgit/aports/tree/main/pcre/uclibc-strtoq.patch
[4] http://git.uclibc.org/uClibc/tree/libc/stdlib/stdlib.c#n348
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: build fails on native x86_64 on utxent

2010-11-17 Thread Natanael Copa 
On Tue, Nov 16, 2010 at 9:10 PM, Carmelo Amoroso  wrote:
> On 16/11/10 13:16, Natanael Copa wrote:
>> Hi,
>>
>> I'm trying to bootstrap a native uclibc x86_64 environment. Seems like
>> the recent utmpx commits breaks 64 bit.
>>
>>   CC libc/misc/utmp/utxent.os
>> libc/misc/utmp/utxent.c: In function 'getutmp':
>> libc/misc/utmp/utxent.c:74:14: error: incompatible types when
>> assigning to type 'struct ' from type 'const struct
>> '
>> libc/misc/utmp/utxent.c: In function 'getutmpx':
>> libc/misc/utmp/utxent.c:100:15: error: incompatible types when
>> assigning to type 'struct ' from type 'const struct
>> '
>> make: *** [libc/misc/utmp/utxent.os] Error 1
>>
>>
>
>
> Hi Natanael,
> I'll have a look asap.
>
> Could you try disabling the support and see how it goes ?

Then it compiles successfully.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

build fails on native x86_64 on utxent

2010-11-16 Thread Natanael Copa 
Hi,

I'm trying to bootstrap a native uclibc x86_64 environment. Seems like
the recent utmpx commits breaks 64 bit.

  CC libc/misc/utmp/utxent.os
libc/misc/utmp/utxent.c: In function 'getutmp':
libc/misc/utmp/utxent.c:74:14: error: incompatible types when
assigning to type 'struct ' from type 'const struct
'
libc/misc/utmp/utxent.c: In function 'getutmpx':
libc/misc/utmp/utxent.c:100:15: error: incompatible types when
assigning to type 'struct ' from type 'const struct
'
make: *** [libc/misc/utmp/utxent.os] Error 1


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] ntpl: fix static linking by not leaking SSP_ALL_CFLAGS

2010-11-11 Thread Natanael Copa 
The SSP_ALL_CFLAGS in nptl arch CFLAGS leaks out and forces things
like dl-support.c, brk.c, sbrk.c memcpy, etc to be built with
-fstack-protector-all. This is bad when linking statically since
initializing TLS will call those functions before SSP is initialized.

The libpthread itself will still be built with -fstack-protector-all
due to CFLAGS-nptl has SSP_ALL_CFLAGS in libpthread/nptl/Makefile.in

Thanks to Timo Teras for helping with this.
---
 libpthread/nptl/sysdeps/arm/Makefile.arch  |1 -
 libpthread/nptl/sysdeps/generic/Makefile.in|2 --
 libpthread/nptl/sysdeps/i386/Makefile.arch |1 -
 libpthread/nptl/sysdeps/mips/Makefile.arch |1 -
 libpthread/nptl/sysdeps/powerpc/Makefile.arch  |1 -
 libpthread/nptl/sysdeps/sh/Makefile.arch   |1 -
 libpthread/nptl/sysdeps/sparc/Makefile.arch|1 -
 .../nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch |1 -
 .../sysdeps/unix/sysv/linux/i386/Makefile.arch |1 -
 .../sysdeps/unix/sysv/linux/mips/Makefile.arch |1 -
 .../sysdeps/unix/sysv/linux/powerpc/Makefile.arch  |1 -
 .../nptl/sysdeps/unix/sysv/linux/sh/Makefile.arch  |1 -
 .../sysdeps/unix/sysv/linux/sparc/Makefile.arch|1 -
 .../sysdeps/unix/sysv/linux/x86_64/Makefile.arch   |1 -
 libpthread/nptl/sysdeps/x86_64/Makefile.arch   |1 -
 15 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/libpthread/nptl/sysdeps/arm/Makefile.arch 
b/libpthread/nptl/sysdeps/arm/Makefile.arch
index b7a9295..a8bc1aa 100644
--- a/libpthread/nptl/sysdeps/arm/Makefile.arch
+++ b/libpthread/nptl/sysdeps/arm/Makefile.arch
@@ -15,4 +15,3 @@ ASFLAGS-pthread_spin_lock.S = -DNOT_IN_libc -DIS_IN_libpthread
 ASFLAGS-pthread_spin_trylock.S = -DNOT_IN_libc -DIS_IN_libpthread
 ASFLAGS-aeabi_read_tp.S = -DNOT_IN_libc=1
 
-CFLAGS-arm = $(SSP_ALL_CFLAGS)
diff --git a/libpthread/nptl/sysdeps/generic/Makefile.in 
b/libpthread/nptl/sysdeps/generic/Makefile.in
index 890fe05..eb656ee 100644
--- a/libpthread/nptl/sysdeps/generic/Makefile.in
+++ b/libpthread/nptl/sysdeps/generic/Makefile.in
@@ -19,8 +19,6 @@ libpthread_generic_libc_a_OBJS = 
$(libpthread_generic_libc_a_COBJ)
 libpthread_ld_tls_CSRC = dl-tls.c
 libpthread_ld_tls_COBJ = $(patsubst 
%.c,$(libpthread_generic_OUT)/%.o,$(libpthread_ld_tls_CSRC))
 
-CFLAGS-generic = $(SSP_ALL_CFLAGS)
-
 objclean-y += CLEAN_libpthread/nptl/sysdeps/generic
 
 CLEAN_libpthread/nptl/sysdeps/generic:
diff --git a/libpthread/nptl/sysdeps/i386/Makefile.arch 
b/libpthread/nptl/sysdeps/i386/Makefile.arch
index 89962f7..9572303 100644
--- a/libpthread/nptl/sysdeps/i386/Makefile.arch
+++ b/libpthread/nptl/sysdeps/i386/Makefile.arch
@@ -8,4 +8,3 @@
 CFLAGS-pthread_spin_lock.c += -D_GNU_SOURCE
 CFLAGS-pthread_create.c += -mpreferred-stack-boundary=4
 
-CFLAGS-i386 = $(SSP_ALL_CFLAGS)
diff --git a/libpthread/nptl/sysdeps/mips/Makefile.arch 
b/libpthread/nptl/sysdeps/mips/Makefile.arch
index 6085ec8..2762a2f 100644
--- a/libpthread/nptl/sysdeps/mips/Makefile.arch
+++ b/libpthread/nptl/sysdeps/mips/Makefile.arch
@@ -15,4 +15,3 @@ ASFLAGS-nptl-sysdep.S = -DNOT_IN_libc -DIS_IN_libpthread  
\
 
 libc_arch_a_CSRC = libc-tls.c
 
-CFLAGS-mips = $(SSP_ALL_CFLAGS)
diff --git a/libpthread/nptl/sysdeps/powerpc/Makefile.arch 
b/libpthread/nptl/sysdeps/powerpc/Makefile.arch
index edf3f4b..18ddc28 100644
--- a/libpthread/nptl/sysdeps/powerpc/Makefile.arch
+++ b/libpthread/nptl/sysdeps/powerpc/Makefile.arch
@@ -5,4 +5,3 @@
 # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
 #
 
-CFLAGS-powerpc = $(SSP_ALL_CFLAGS)
diff --git a/libpthread/nptl/sysdeps/sh/Makefile.arch 
b/libpthread/nptl/sysdeps/sh/Makefile.arch
index eb4db68..3cb58ec 100644
--- a/libpthread/nptl/sysdeps/sh/Makefile.arch
+++ b/libpthread/nptl/sysdeps/sh/Makefile.arch
@@ -10,5 +10,4 @@ ASFLAGS-pthread_spin_trylock.S = -DNOT_IN_libc 
-DIS_IN_libpthread
 
 CFLAGS-pthread_spin_lock.c += -D_GNU_SOURCE
 
-CFLAGS-sh = $(SSP_ALL_CFLAGS)
 
diff --git a/libpthread/nptl/sysdeps/sparc/Makefile.arch 
b/libpthread/nptl/sysdeps/sparc/Makefile.arch
index 4494935..52ac6db 100644
--- a/libpthread/nptl/sysdeps/sparc/Makefile.arch
+++ b/libpthread/nptl/sysdeps/sparc/Makefile.arch
@@ -8,5 +8,4 @@ subdirs += 
libpthread/nptl/sysdeps/$(TARGET_ARCH)/$(TARGET_SUBARCH)/sparv9
 
 CFLAGS-pthread_spin_lock.c += -D_GNU_SOURCE
 
-CFLAGS-sparc = $(SSP_ALL_CFLAGS)
 
diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch 
b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
index 2385d8d..329d8a9 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
@@ -14,7 +14,6 @@ libc_linux_arch_CSRC = fork.c libc-lowlevellock.c
 libc_linux_arch_SSRC = clone.S vfork.S
 libc_linux_arch_SSRC-OMIT = waitpid.S
 
-CFLAGS += $(SSP_ALL_CFLAGS)
 
 CFLAGS-pthread_once.c = -DNOT_IN_libc -DIS_IN_libpthread
 CFLAGS-pt-__syscall_rt_sigaction.c = -DNOT_IN_libc -DIS_IN_libpthread
d

release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

2010-11-01 Thread Natanael Copa 
On Sun, Oct 31, 2010 at 11:37 PM, Rob Landley  wrote:
> I hate to bring up the word "release" on this list, but is there any chance of
> integrating this patch actually meaning something in the forseeable future?

I wonder the same.

I am about to create the second release of Alpine Linux based off a
git snapshot of uclibc. Atleast for x86 the git master with NPTL have
been very stable recently, infact better than any previous release.

What are the big show stoppers for next uclibc release?

--
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: CIFS mounted drive issue

2010-10-25 Thread Natanael Copa 
On Mon, Oct 25, 2010 at 11:11 PM, Khem Raj  wrote:
> On (18/10/10 15:09), Natanael Copa wrote:
>> I (or an Alpine linux user) got bitten by the issue below too.
>> http://redmine.alpinelinux.org/issues/show/445
>>
>> So I started to dig around a bit. Here is what i have come up with:
>> * it happens with busybox ls and coreutils ls.
>> * it works on 32bit (e)glibc systems. ie ubuntu.
>>
>> So I compared the straces and as expected, the difference is stat()
>> and stat64().
>>
>> >From uclibc:
>> open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
>> fstat(3, 0xb148)                    = -1 EOVERFLOW (Value too
>> large for defined data type)
>>
>> >From ubuntu/eglibc:
>> open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
>> fstat64(3, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
>>
>> Then i thought that there are probably some flag that is supposed to
>> do so fstat = fstat64 or something, and if i know those GNU people
>> correctly, they check this in a configure script. this turned out to
>> be correct. In the configure output I see this when compiling
>> coreutils:
>>
>> checking for _LARGEFILE_SOURCE value needed for large files... no
>> ...
>> checking for _FILE_OFFSET_BITS value needed for large files... 64
>> ...
>>
>> So, I think uclibc is not doing what expected at some place.
>> Where or how, I don't know.

>
> Do you have large file support turned on in uclibc config ?

I have.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Problems with pthreads in a chroot?

2010-10-19 Thread Natanael Copa 
On Mon, Oct 18, 2010 at 9:40 PM, Ed W  wrote:
>  Hi Natanael

Hi,

>
> Thanks for responding
>
>> Or you could just use Alpine Linux[2]. After all, x86 uclibc +
>> grsecurity kernel (including pax) is our main focus ;)
>
> Sure - actually my current project uses very similar to your alpine linux
> installation, only starting with a gentoo overlay.  I would very happily
> share any improvements I make however, normally you are ahead of me and I
> usually find the solutions to most uclibc questions are in your tree!

We used to use gentoo for building alpine. Now we stand on our own legs.

> I think I would struggle to switch to using your build tool at present
> because I'm trying to build a modular setup rather like slax.  The idea is
> target a low ram target (which I think rules out running from ramdisk) and
> use aufs to build a modular installation where we have a base installation,
> but overlay more functionality for instances where it's needed. This would
> make for a very simple "package manager".  Please tell me that this would be
> straightforward to build using Alpine and we should talk more off-list?

I think it should be fairly straightforward to get that working. We
have someone working on a similar project to yours, with unionfs - but
he wants use eglibc instead of uclibc.

Might be we need some patches for supporting aufs in initramfs to
mounting up the root, but I think thats gonna be trivial.

You are welcome to freenode #alpine-devel or #alpine-linux to discuss details.

>  Last time I looked you pretty much mandated building an installation which
> only ran from ram?

We support installing on disk. I run Alpine Linux on my netbook as a
traditional disk install.

> However, your git tree suggests that you compile your uclibc without SSP?
>  Can you comment on whether SSP works for you?

I thought we enable SSP? hum... looks like i need to fix the gcc
apkbuild. SSP should work though. We used it for gcc-4.4 and i'm
fixing gcc-4.5 as we speak.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Problems with pthreads in a chroot?

2010-10-18 Thread Natanael Copa 
Hi Ed,

I assume you are using x86 uclibc.

On Mon, Oct 18, 2010 at 6:16 PM, Ed W  wrote:

> It's taken me a little time to figure this out, but my build machine is
> 2.6.32 with pax 2.2 - I'm reasonably sure this used to work previously with
> an earlier pax patch.  The kernel which was working on the final device was
> a 2.6.33 + pax 2.1, I just updated it to 2.6.35 + pax 2.2 and now I see
> exactly the same failure to create threads there
>
> Is it possible that someone smarter than me can please help me make uclibc
> 0.9.31 work with pax 2.2 patches?  At least some pointers on how to debug
> and find the lines of code which are triggering the failure would be
> helpful?

I can share our Alpine Linux experiences with x86 uclibc and threading.

We started with oldthreads, bumped into some bugs that was difficult
to solve, switched to linuxthreads.new which worked more or less ok.

You could have a look at the uclibc patches[1] alpine linux used for
0.9.30. We skipped the 0.9.31 release and jumped directly to git
master/NPTL.

Or you could just use Alpine Linux[2]. After all, x86 uclibc +
grsecurity kernel (including pax) is our main focus ;)

...

> (Alternatively, how close are we to seeing 0.9.32 and nptl get out of the
> door? Seems like it's within spitting distance?)

fwiw, for us the nptl from git have been better/more stable than any
other threading implementation before. Infact, for x86, uclibc git
master have been better than any previous release, ever. (at least up
to the point config parser stuff got committed - but i think those
issues are fixed to now)

-- 
Natanael Copa

[1] http://git.alpinelinux.org/cgit/aports/tree/main/uclibc?h=1.10-stable
[2] http://alpinelinux.org
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: CIFS mounted drive issue

2010-10-18 Thread Natanael Copa 
I (or an Alpine linux user) got bitten by the issue below too.
http://redmine.alpinelinux.org/issues/show/445

So I started to dig around a bit. Here is what i have come up with:
* it happens with busybox ls and coreutils ls.
* it works on 32bit (e)glibc systems. ie ubuntu.

So I compared the straces and as expected, the difference is stat()
and stat64().

>From uclibc:
open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, 0xb148)= -1 EOVERFLOW (Value too
large for defined data type)

>From ubuntu/eglibc:
open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0

Then i thought that there are probably some flag that is supposed to
do so fstat = fstat64 or something, and if i know those GNU people
correctly, they check this in a configure script. this turned out to
be correct. In the configure output I see this when compiling
coreutils:

checking for _LARGEFILE_SOURCE value needed for large files... no
...
checking for _FILE_OFFSET_BITS value needed for large files... 64
...

So, I think uclibc is not doing what expected at some place.
Where or how, I don't know.

Any ideas?

On Fri, Apr 30, 2010 at 12:22 PM, J. Schneider  wrote:
> Hi all,
>
> as Yegor wrote last month I go the same behavior on openwrt r21196 and
> tested on mips (ar7161 routerboard 450G) with:
>
> kernel 2.6.3.32.12 and 2.6.33.3
> uclibc 0.9.30.x and 0.9.31
>
> After mounting a w2k3 or w2k8 share with mount.cifs, ls -la breaks with:
> ls: can't open '/mnt': Value too large for defined data type
> r...@openwrt:/tmp# strace ls -al
> ..
> stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=20708, ...}) = 0
> mprotect(0x2ab7b000, 4096, PROT_READ)   = 0
> mprotect(0x2aabc000, 4096, PROT_READ)   = 0
> ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> getuid()                                = 0
> time([1272618468])                      = 1272618468
> ioctl(0, 0x40087468, 0x7fe1d3f8)        = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> lstat64(0x7fe1deeb, 0x7fe1d2d8)         = 0
> brk(0)                                  = 0x47f000
> brk(0x48)                           = 0x48
> open("/mnt", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
> fstat(3, 0x7fe1d250)                    = -1 EOVERFLOW (Value too large for
> defined data type)
> close(3)                                = 0
> brk(0x481000)                           = 0x481000
> ioctl(2147483647, TIOCNXCL, 0x7fe1d1d8) = -1 EBADF (Bad file descriptor)
> brk(0x482000)                           = 0x482000
> write(2, "ls: can't open '/mnt': Value too"..., 61ls: can't open '/mnt':
> Value too large for defined data type
> ) = 61
> exit(1)                                 = ?
>
>
> A samba share from a centos5 machine works fine.
> r...@openwrt:/tmp# strace ls -al /mnt
> ..
> stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=20708, ...}) = 0
> mprotect(0x2ab7b000, 4096, PROT_READ)   = 0
> mprotect(0x2aabc000, 4096, PROT_READ)   = 0
> ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> getuid()                                = 0
> time([1272621607])                      = 1272621607
> ioctl(0, 0x40087468, 0x7f9c90c8)        = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> lstat64(0x463488, 0x7f9c8fa8)           = 0
> brk(0)                                  = 0x47f000
> brk(0x48)                           = 0x48
> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
> fstat(3, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=340, ...}) = 0
> fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
> brk(0x481000)                           = 0x481000
> getdents64(3, /* 17 entries */, 4096)   = 488
> brk(0x482000)                           = 0x482000
>
>
> I'm happy for any hints
>
> Many Thanks
> Joerg
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] create DEVEL_PREFIX/MULTILIB_DIR dir rather than DEVEL_PREFIX/lib

2010-10-16 Thread Natanael Copa 
Could someone please commit/push this patch to git master? Currently
'make install DESTDIR=$someplace' does not work with gnu make 3.82

Thanks!

On Tue, Aug 24, 2010 at 8:19 AM, Natanael Copa  wrote:
> This fixes issue with GNU Make 3.82 when running:
>
>  make install DESTDIR=$someplace
>
> Signed-off-by: Natanael Copa 
> ---
>  Makefile.in |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile.in b/Makefile.in
> index 1c0e305..bffe998 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -289,10 +289,10 @@ HEADERS_RM-$(UCLIBC_SUSV4_LEGACY)            += utime.h
>        ### ucontext.h
>
>  ifneq ($(findstring install,$(MAKECMDGOALS)),)
> -$(addprefix $(PREFIX)$(DEVEL_PREFIX),include lib):
> +$(addprefix $(PREFIX)$(DEVEL_PREFIX),include $(MULTILIB_DIR)):
>        $(do_mkdir)
>  # avoid warning about duplicate targets in rule or overrides
> -ifneq ($(abspath $(RUNTIME_PREFIX)$(MULTILIB_DIR)),$(abspath 
> $(DEVEL_PREFIX)lib))
> +ifneq ($(abspath $(RUNTIME_PREFIX)$(MULTILIB_DIR)),$(abspath 
> $(DEVEL_PREFIX)$(MULTILIB_DIR)))
>  $(PREFIX)$(RUNTIME_PREFIX)$(MULTILIB_DIR):
>        $(do_mkdir)
>  endif
> --
> 1.7.2.2
>
>



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 3/4] getnet: simplify alias handling and reduce MAXALIASES

2010-10-13 Thread Natanael Copa 
Reduce MAXALIASES to something lower. There will probably never be
need for more than 1 alias but we allow a few extra.

While here we alos fix segfault when there are too many aliases.
---
 libc/inet/getnet.c |   25 -
 1 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/libc/inet/getnet.c b/libc/inet/getnet.c
index c604b63..9049f97 100644
--- a/libc/inet/getnet.c
+++ b/libc/inet/getnet.c
@@ -27,9 +27,11 @@ aliases: case sensitive optional space or tab separated list 
of other names
 #include 
 __UCLIBC_MUTEX_STATIC(mylock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
 
-#defineMAXALIASES  35
-#define BUFSZ  (80) /* one line */
-#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXALIASES))
+#define MINTOKENS  2
+#defineMAXALIASES  8
+#define MAXTOKENS  (MINTOKENS + MAXALIASES + 1)
+#define BUFSZ  (255) /* one line */
+#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXTOKENS))
 
 static parser_t *netp = NULL;
 static struct netent nete;
@@ -65,10 +67,8 @@ int getnetent_r(struct netent *result_buf,
int *h_errnop
 )
 {
-   char **alias, *cp = NULL;
-   char **net_aliases;
char **tok = NULL;
-   const size_t aliaslen = sizeof(*net_aliases) * MAXALIASES;
+   const size_t aliaslen = sizeof(char *) * MAXTOKENS;
int ret = ERANGE;
 
*result = NULL;
@@ -86,7 +86,7 @@ int getnetent_r(struct netent *result_buf,
netp->data_len = aliaslen;
netp->line_len = buflen - aliaslen;
/* [[:space:]][[:space:]][] */
-   if (!config_read(netp, &tok, 3, 2, "# \t/", PARSE_NORMAL)) {
+   if (!config_read(netp, &tok, MAXTOKENS-1, MINTOKENS, "# \t/", 
PARSE_NORMAL)) {
goto DONE;
}
result_buf->n_name = *(tok++);
@@ -110,16 +110,7 @@ int getnetent_r(struct netent *result_buf,
sa4_to_uint32(addri->ai_addr);
freeaddrinfo(addri);
}
-   result_buf->n_aliases = alias = net_aliases = tok;
-   cp = *alias;
-   while (cp && *cp) {
-   if (alias < &net_aliases[MAXALIASES - 1])
-   *alias++ = cp;
-   cp = strpbrk(cp, " \t");
-   if (cp != NULL)
-   *cp++ = '\0';
-   }
-   *alias = NULL;
+   result_buf->n_aliases = tok;
*result = result_buf;
ret = 0;
  DONE:
-- 
1.7.3.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 4/4] getproto: increase line buffer size, simlify and fix alias handling

2010-10-13 Thread Natanael Copa 
We increase line buffer size, reduce MAXALIASES and make sure we don't
segfault when there are too manuy aliases in /etc/protocols.
---
 libc/inet/getproto.c |   25 -
 1 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/libc/inet/getproto.c b/libc/inet/getproto.c
index bcf507b..c59da7e 100644
--- a/libc/inet/getproto.c
+++ b/libc/inet/getproto.c
@@ -27,9 +27,11 @@ aliases: case sensitive optional space or tab separated list 
of other names
 #include 
 __UCLIBC_MUTEX_STATIC(mylock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
 
-#defineMAXALIASES  35
-#define BUFSZ  (80) /* one line */
-#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXALIASES))
+#define MINTOKENS  2
+#defineMAXALIASES  8 /* will probably never be more than one */
+#define MAXTOKENS  (MINTOKENS + MAXALIASES + 1)
+#define BUFSZ  (255) /* one line */
+#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXTOKENS))
 
 static parser_t *protop = NULL;
 static struct protoent protoe;
@@ -63,10 +65,8 @@ libc_hidden_def(endprotoent)
 int getprotoent_r(struct protoent *result_buf,
 char *buf, size_t buflen, struct protoent 
**result)
 {
-   char **alias, *cp = NULL;
-   char **proto_aliases;
char **tok = NULL;
-   const size_t aliaslen = sizeof(*proto_aliases) * MAXALIASES;
+   const size_t aliaslen = sizeof(char *) * MAXTOKENS;
int ret = ERANGE;
 
*result = NULL;
@@ -85,21 +85,12 @@ int getprotoent_r(struct protoent *result_buf,
protop->data_len = aliaslen;
protop->line_len = buflen - aliaslen;
/* [[:space:]][[:space:]][] */
-   if (!config_read(protop, &tok, 3, 2, "# \t/", PARSE_NORMAL)) {
+   if (!config_read(protop, &tok, MAXTOKENS - 1, MINTOKENS, "# \t/", 
PARSE_NORMAL)) {
goto DONE;
}
result_buf->p_name = *(tok++);
result_buf->p_proto = atoi(*(tok++));
-   result_buf->p_aliases = alias = proto_aliases = tok;
-   cp = *alias;
-   while (cp && *cp) {
-   if (alias < &proto_aliases[MAXALIASES - 1])
-   *alias++ = cp;
-   cp = strpbrk(cp, " \t");
-   if (cp != NULL)
-   *cp++ = '\0';
-   }
-   *alias = NULL;
+   result_buf->p_aliases = tok;
*result = result_buf;
ret = 0;
  DONE:
-- 
1.7.3.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 2/4] getservice: fix handling of long lines

2010-10-13 Thread Natanael Copa 
Don't try to be smart by dynamically realloc buffersize as it doesn't
work. Instead, be simple and allocate a buffer big enough.

This fixes a memory leak when calling getserv{ent,byname,byport}
multiple times.

To save memory we reduce number of max aliases. We seldomly will need
more than 1 anyways. While here, fix segfault that happened if there
were too many aliases.
---
 libc/inet/getservice.c |   38 --
 1 files changed, 16 insertions(+), 22 deletions(-)

diff --git a/libc/inet/getservice.c b/libc/inet/getservice.c
index c38ff80..183099f 100644
--- a/libc/inet/getservice.c
+++ b/libc/inet/getservice.c
@@ -28,9 +28,11 @@ aliases: case sensitive optional space or tab separated list 
of other names
 #include 
 __UCLIBC_MUTEX_STATIC(mylock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
 
-#defineMAXALIASES  35
-#define BUFSZ  (80) /* one line */
-#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXALIASES))
+#define MINTOKENS  3
+#defineMAXALIASES  8   /* we seldomly need more than 1 alias */
+#define MAXTOKENS  (MINTOKENS + MAXALIASES + 1)
+#define BUFSZ  (255)   /* one line */
+#define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXTOKENS))
 
 static parser_t *servp = NULL;
 static struct servent serve;
@@ -65,10 +67,8 @@ libc_hidden_def(endservent)
 int getservent_r(struct servent *result_buf,
 char *buf, size_t buflen, struct servent 
**result)
 {
-   char **alias;
-   char **serv_aliases;
char **tok = NULL;
-   const size_t aliaslen = sizeof(*serv_aliases) * MAXALIASES;
+   const size_t aliaslen = sizeof(char *) * MAXTOKENS;
int ret = ERANGE;
 
*result = NULL;
@@ -87,13 +87,13 @@ int getservent_r(struct servent *result_buf,
servp->data_len = aliaslen;
servp->line_len = buflen - aliaslen;
/* [[:space:]]/[[:space:]][] */
-   if (!config_read(servp, &tok, MAXALIASES, 3, "# \t/", PARSE_NORMAL)) {
+   if (!config_read(servp, &tok, MAXTOKENS - 1, MINTOKENS, "# \t/", 
PARSE_NORMAL)) {
goto DONE;
}
result_buf->s_name = *(tok++);
result_buf->s_port = htons((u_short) atoi(*(tok++)));
result_buf->s_proto = *(tok++);
-   result_buf->s_aliases = alias = serv_aliases = tok;
+   result_buf->s_aliases = tok;
*result = result_buf;
ret = 0;
  DONE:
@@ -106,9 +106,8 @@ libc_hidden_def(getservent_r)
 
 static void __initbuf(void)
 {
-   if (servbuf)
-   servbuf_sz += BUFSZ;
-   servbuf = realloc(servbuf, servbuf_sz);
+   if (!servbuf)
+   servbuf = malloc(SBUFSIZE);
if (!servbuf)
abort();
 }
@@ -117,9 +116,8 @@ struct servent *getservent(void)
 {
struct servent *result;
 
-   do {
-   __initbuf();
-   } while (getservent_r(&serve, servbuf, servbuf_sz, &result) == ERANGE);
+   __initbuf();
+   getservent_r(&serve, servbuf, servbuf_sz, &result);
return result;
 }
 
@@ -154,10 +152,8 @@ struct servent *getservbyname(const char *name, const char 
*proto)
 {
struct servent *result;
 
-   do {
-   __initbuf();
-   } while (getservbyname_r(name, proto, &serve, servbuf, servbuf_sz, 
&result)
-== ERANGE);
+   __initbuf();
+   getservbyname_r(name, proto, &serve, servbuf, servbuf_sz, &result);
return result;
 }
 
@@ -187,10 +183,8 @@ struct servent *getservbyport(int port, const char *proto)
 {
struct servent *result;
 
-   do {
-   __initbuf();
-   } while (getservbyport_r(port, proto, &serve, servbuf, servbuf_sz, 
&result)
-== ERANGE);
+   __initbuf();
+   getservbyport_r(port, proto, &serve, servbuf, servbuf_sz, &result);
return result;
 }
 libc_hidden_def(getservbyport)
-- 
1.7.3.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH 1/4] parse_config: discard rest of incomplete line

2010-10-13 Thread Natanael Copa 
If line is longer then size of given buffer and buffer is not allocated by
the config parser itself, then discard rest of line.
---
 libc/misc/internals/parse_config.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/libc/misc/internals/parse_config.c 
b/libc/misc/internals/parse_config.c
index 6d3b6f4..c17d255 100644
--- a/libc/misc/internals/parse_config.c
+++ b/libc/misc/internals/parse_config.c
@@ -79,6 +79,13 @@ static off_t bb_get_chunk_with_continuation(parser_t* parsr)
 parsr->data = realloc(parsr->data,
   
parsr->data_len + parsr->line_len);
parsr->line = parsr->data + parsr->data_len;
+   } else {
+   /* discard rest of line if not enough space in buffer */
+   int c;
+   do {
+   c = fgetc(parsr->fp);
+   } while (c != EOF && c != '\n');
+   break;
}
}
return pos;
-- 
1.7.3.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Fix config parser and netdb

2010-10-13 Thread Natanael Copa 
Hi,

Here are a set of patches which should be applied upon the 3 previous
ones i sent to list.

Those patches fixes getserv{ent,byname,byport}, getnet{ent,byname,byaddr}
and getproto{ent,byname,bynumber} funcs to properly handle long lines.

Rather than try dynamically reallocate the buffer it just takes 256 chars
+ space for token array. I also reduced MAXALIASES from 35 to 8, but I
don't think that will cause any problems. I have never seen anything use
more than 1 alias.

It is possible to reduce the linebuffer size to something lower due to
first patch, but I think it should be more than 80.

Thanks!

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

getservent, getservbyname and getservbyport and config parser

2010-10-11 Thread Natanael Copa 
Hi,

I have been looking at the config parser and i intend to fix it. It
looks like we have to drop the 80 char, dynamically increasing buffer.
I'll try explain why and using getserv* as example but everything here
applies to getproto* and getnet* funcs too.

As I understood, Berhard really wanted allocate 80 chars line buffer
by default and if lines in /etc/services are longer increase the
buffer size dynamically with realloc()[1]. The current git master is
broken with this, and it is *almost* possible to fix it. I'll try
explain the problem.

A too line that is too long, is detected by that there are no '\n'. If
the parser is using a buffer that was allocated by the parser itself,
then it is possible to do realloc from the
bb_get_chunk_with_continuation() function as it does here:
http://git.uclibc.org/uClibc/tree/libc/misc/internals/parse_config.c#n77

However, getserv* functions uses its own allocated buffer so
parser->allocated is not set, and therefore the buffer will not be
extended.

Currently the getservent_r() will always return ERANGE
(http://git.uclibc.org/uClibc/tree/libc/inet/getservice.c#n90)
on any error meaning that if you do getservevent("foo", "bar") you'll
end up with an eternal loop
(http://git.uclibc.org/uClibc/tree/libc/inet/getservice.c#n160)

This can be fixed by letting bb_get_chunk_with_continuation() return
-1 on EOF or -2 if no newline was found, and let config_read() either
0 for EOF, -ERANGE for not enough space for buf or a positive number
for number of seen tokens. This will make getservbyname() and
getservbyport() work. I have patches for this (and also a patch for
fixing the memleak that is currently there)

But...

That will not work for getservent(), since the line that caused the
ERANGE is already read and will be lost. So if you have a line in
/etc/services:

http  80/tcp  # world wide web, and some blablabla  bla bla
 line contines past by 80 chars

Then would running getservent() simply skip this line. getservent_r()
would return ERANGE and the loop
http://git.uclibc.org/uClibc/tree/libc/inet/getservice.c#n123 would
just skip it.

So basically, dynamic reallocation will not work for getservent(). If
we at any cost want keep 80 char buf size, then we need do some tricks
with letting config_read() do the allocation if getserv*_r() functions
passed NULL and then somehow prevent config_close() to free it.
I think it just not worth it.

Unless someone have some really strong arguments to keep the 80 char
bufsize, I'll just set static line bufsize to 256 chars and then just
let the config parser only ready the 256 first chars on each line and
ignore the rest.

-- 
Natanael Copa

 [1] http://lists.busybox.net/pipermail/uclibc/2010-August/044270.html
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC] git master broken due to config parser

2010-10-07 Thread Natanael Copa 
On Tue, Oct 5, 2010 at 11:44 AM, Carmelo AMOROSO  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/5/2010 10:14 AM, Natanael Copa wrote:
>> Hi,
>>
>
> Hi Natanael,

Hi, thanks for your response. I was hoping to close this issue this
week but incredible how time flies...

...
>> So, I have a few options I think we should evaluate:
>>
>> 1. Revert the config parser commits, create a feature branch and put
>> them there, where they can be debugged without stress.
>>
>> 2. Raise the line buffer size to 256 chars, which it seems to have
>> been before. (things that still break at that size would probably have
>> broken before too). Then rip out the code that tries to be smart by
>> doing realloc when line buffer is too small.
>>
>> 3. Keep line buffer to 80 chars and fix the realloc logic, now.
>>
>> Option #2 and #3 implies that the patches[1][2][3] gets applied.
>>
>
> I do not know "config_parser" at all, but I looked your patch times ago
> and was thinking to push them. I was busy with prelink stuff.
>
>> I have some ideas for option #3, but not sure yet if it will work. The
>> code will be somewhat complicated so I think the extra bytes saved
>> might get lost in the extra code.
>>
>> In any case, I think we should do something *soon*, since current git
>> master have been broken for too long. I can help but i need someone to
>> review (sign-off?) and someone with git push access to get the changes
>> in git master.
>>
>
> Honestly I'm not seeing any activities on uClibc in the last month.
> I would opt for option #2 and #3. If config_parse needs to be reworked,
> it can be done as well later.
>
> I agree with you to have master fixed asap.

Great. Lets rule out running the config parser in separate branch.
Then we should decide if we want stay simple and allways alloc 256
chars static, or try be smart and start with 80 and then dynamically
increase if needed. I think Bernhard wanted the latter.

I'll have a look at it.

> I can help pushing your patches [1][2] and [3].

That would be great. They don't make things worse at least.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[RFC] git master broken due to config parser

2010-10-05 Thread Natanael Copa 
Hi,

The git master have been more or less rock stable since NPTL branch
was merged in (at least for x86).

Until the config parser commits.

The problems are:
* memory corruption due to assuming realloc returns same address as
before. Patches was sent to this list. [1] [2]
* endless loop in getservbyname when service is not known. Patch was sent [3].
* lines in /etc/protocols and /etc/services (and others?) longer than
80 chars still gives "interesting" restults. The logic for the realloc
when buffer is too small in getserv*() and getproto*() is flawed and
just don't work. (i can give details if someone is interested)
* memory leaks when calling getservent(), getservbyname() and
getservbyport() multiple times. (fairly simple to fix)
* if you have comments with more than MAXALIASES words "interesting"
things might happen

Now, I think breaking git master temporary is ok. Its an acceptable
price to pay for progress. I think its also ok that developers gets
busy with other stuff and don't have time to give uclibc 100%
attention. That happens to all.

However, its not good that git master stays broken.

So, I have a few options I think we should evaluate:

1. Revert the config parser commits, create a feature branch and put
them there, where they can be debugged without stress.

2. Raise the line buffer size to 256 chars, which it seems to have
been before. (things that still break at that size would probably have
broken before too). Then rip out the code that tries to be smart by
doing realloc when line buffer is too small.

3. Keep line buffer to 80 chars and fix the realloc logic, now.

Option #2 and #3 implies that the patches[1][2][3] gets applied.

I have some ideas for option #3, but not sure yet if it will work. The
code will be somewhat complicated so I think the extra bytes saved
might get lost in the extra code.

In any case, I think we should do something *soon*, since current git
master have been broken for too long. I can help but i need someone to
review (sign-off?) and someone with git push access to get the changes
in git master.

Thanks!

-- 
Natanael Copa

[1] http://lists.uclibc.org/pipermail/uclibc/2010-September/044314.html
[2] http://lists.uclibc.org/pipermail/uclibc/2010-September/044317.html
[3] http://lists.uclibc.org/pipermail/uclibc/2010-September/044316.html
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] config parser: always initialize line pointer

2010-09-16 Thread Natanael Copa 
We must always initialize line pointer since data pointer might
have changed due to a realloc (in getserv.c for example).

Signed-off-by: Natanael Copa 
---
 libc/misc/internals/parse_config.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/libc/misc/internals/parse_config.c 
b/libc/misc/internals/parse_config.c
index 6734f35..6d3b6f4 100644
--- a/libc/misc/internals/parse_config.c
+++ b/libc/misc/internals/parse_config.c
@@ -192,8 +192,7 @@ again:
return 0;
parser->allocated |= 1;
} /* else { assert(parser->data_len > 0); } */
-   if (parser->line == NULL)
-   parser->line = parser->data + parser->data_len;
+   parser->line = parser->data + parser->data_len;
/*config_free_data(parser);*/
 
/* Read one line (handling continuations with backslash) */
-- 
1.7.2.3

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] getservice: getservent_r must return ERANGE when buffer is too small

2010-09-16 Thread Natanael Copa 
This fixes issue introduced by 72e1a1ce186c39f07282398e2af9eb0253e60f15

This should also fix the following testcase to exit with error rather
than cause an endless loop.

int main(void) {
if (getservbyname("non-existing", "udp") == NULL)
err(1, "getservbyname");
return 0;
}

Reported by Pirmin Walthert
http://lists.uclibc.org/pipermail/uclibc/2010-August/044277.html

Signed-off-by: Natanael Copa 
---
 libc/inet/getservice.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libc/inet/getservice.c b/libc/inet/getservice.c
index 1532df9..ccf9816 100644
--- a/libc/inet/getservice.c
+++ b/libc/inet/getservice.c
@@ -69,7 +69,7 @@ int getservent_r(struct servent *result_buf,
char **serv_aliases;
char **tok = NULL;
const size_t aliaslen = sizeof(*serv_aliases) * MAXALIASES;
-   int ret = ENOENT;
+   int ret = ERANGE;
 
*result = NULL;
if (buflen < aliaslen
@@ -77,7 +77,7 @@ int getservent_r(struct servent *result_buf,
goto DONE_NOUNLOCK;
 
__UCLIBC_MUTEX_LOCK(mylock);
-
+   ret = ENOENT;
if (servp == NULL)
setservent(serv_stayopen);
if (servp == NULL)
@@ -88,7 +88,6 @@ int getservent_r(struct servent *result_buf,
servp->line_len = buflen - aliaslen;
/* [[:space:]]/[[:space:]][] */
if (!config_read(servp, &tok, MAXALIASES, 3, "# \t/", PARSE_NORMAL)) {
-   ret = ERANGE;
goto DONE;
}
result_buf->s_name = *(tok++);
-- 
1.7.2.3

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] config parser: do not assume that realloc return same pointer

2010-09-16 Thread Natanael Copa 
We need to update the parser->line pointer on realloc and do not
initialize the token array til after the potensial realloc in
bb_get_chunk_with_continuation().

While here, also replace a realloc() with malloc() where pointer always
is NULL.

Signed-off-by: Natanael Copa 
---
 libc/misc/internals/parse_config.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/libc/misc/internals/parse_config.c 
b/libc/misc/internals/parse_config.c
index 8fa324e..6734f35 100644
--- a/libc/misc/internals/parse_config.c
+++ b/libc/misc/internals/parse_config.c
@@ -78,6 +78,7 @@ static off_t bb_get_chunk_with_continuation(parser_t* parsr)
 parsr->line_len += PAGE_SIZE;
 parsr->data = realloc(parsr->data,
   
parsr->data_len + parsr->line_len);
+   parsr->line = parsr->data + parsr->data_len;
}
}
return pos;
@@ -186,23 +187,21 @@ again:
parser->line_len = 81;
if (parser->data_len == 0)
parser->data_len += 1 + ntokens * sizeof(char *);
-   parser->data = realloc(parser->data,
-   
parser->data_len + parser->line_len);
+   parser->data = malloc(parser->data_len + parser->line_len);
if (parser->data == NULL)
return 0;
parser->allocated |= 1;
} /* else { assert(parser->data_len > 0); } */
if (parser->line == NULL)
parser->line = parser->data + parser->data_len;
-   if (*tokens == NULL)
-   *tokens = (char **) parser->data;
-   memset(*tokens, 0, sizeof(*tokens[0]) * ntokens);
/*config_free_data(parser);*/
 
/* Read one line (handling continuations with backslash) */
len = bb_get_chunk_with_continuation(parser);
if (len == -1)
return 0;
+   *tokens = (char **) parser->data;
+   memset(*tokens, 0, sizeof(*tokens[0]) * ntokens);
line = parser->line;
 
/* Skip multiple token-delimiters in the start of line? */
-- 
1.7.2.3

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: git (application) segfaults with current uclibc from git

2010-09-15 Thread Natanael Copa 
On Wed, Sep 15, 2010 at 2:52 PM, Natanael Copa  wrote:
> Hi,
>
> Current git (todays git commit) makes "git push" segfault:

I figured out what goes wrong after reading valgrind doc.

Its the config parser's realloc feature that assumes that the
reallocated pointer points to same location as old, which is a wrong
assumption. There is a parser->line pointer and a *token pointer that
needs to be updated after realloc.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

git (application) segfaults with current uclibc from git

2010-09-15 Thread Natanael Copa 
fig_read (parse_config.c:203)
==5191==by 0x4A0B79B: nprocessors_onln (sysconf.c:53)
==5191==by 0x4A0BCC7: sysconf (sysconf.c:749)
==5191==by 0x1FF245: ??? (in /usr/libexec/git-core/git)
==5191==
==5191== Invalid write of size 1
==5191==at 0x4813682: memset (mc_replace_strmem.c:586)
==5191==by 0x49B51BA: bb_get_chunk_with_continuation (parse_config.c:65)
==5191==by 0x49B5478: config_read (parse_config.c:203)
==5191==by 0x4A0B79B: nprocessors_onln (sysconf.c:53)
==5191==by 0x4A0BCC7: sysconf (sysconf.c:749)
==5191==by 0x1FF245: ??? (in /usr/libexec/git-core/git)
==5191==  Address 0x4ac2251 is 17 bytes inside a block of size 90 free'd
==5191==at 0x4811860: realloc (vg_replace_malloc.c:476)
==5191==by 0x49B5265: bb_get_chunk_with_continuation (parse_config.c:79)
==5191==by 0x49B5478: config_read (parse_config.c:203)
==5191==by 0x4A0B79B: nprocessors_onln (sysconf.c:53)
==5191==by 0x4A0BCC7: sysconf (sysconf.c:749)
==5191==by 0x1FF245: ??? (in /usr/libexec/git-core/git)
==5191==
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 291 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
==5191==
==5191== HEAP SUMMARY:
==5191== in use at exit: 284,983 bytes in 46 blocks
==5191==   total heap usage: 179 allocs, 133 frees, 1,484,325 bytes allocated
==5191==
==5191== LEAK SUMMARY:
==5191==definitely lost: 329 bytes in 3 blocks
==5191==indirectly lost: 8 bytes in 1 blocks
==5191==  possibly lost: 939 bytes in 14 blocks
==5191==still reachable: 283,707 bytes in 28 blocks
==5191== suppressed: 0 bytes in 0 blocks
==5191== Rerun with --leak-check=full to see details of leaked memory
==5191==
==5191== For counts of detected and suppressed errors, rerun with: -v
==5191== ERROR SUMMARY: 1425 errors from 32 contexts (suppressed: 0 from 0)



-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] nptl: fix static linking

2010-09-08 Thread Natanael Copa 
We need dl-tls.c for static libc or we will get missing symbols when
linking things like openssl static.

This issue was introduced in 9381d622e2411a35a5fd73a5a573eb269e2dd9c9
---
 libpthread/nptl/Makefile.in |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libpthread/nptl/Makefile.in b/libpthread/nptl/Makefile.in
index 99a726a..3e9676a 100644
--- a/libpthread/nptl/Makefile.in
+++ b/libpthread/nptl/Makefile.in
@@ -48,9 +48,9 @@ libc-shared-routines-y := $(addprefix 
$(libpthread_OUT)/,$(libc-shared-routines-
 libc-static-routines-y := $(addprefix 
$(libpthread_OUT)/,$(libc-static-routines-y:.c=.o))
 libc-shared-y += $(libc-shared-routines-y) $(libpthread_libc_OBJS:.o=.oS)
 ifeq ($(DOPIC),y)
-libc-static-y += $(libc-static-routines-y:.o=.os) 
$(libpthread_libc_a_OBJS:.o=.os) # $(libpthread_ld_tls_COBJ:.o=.os)
+libc-static-y += $(libc-static-routines-y:.o=.os) 
$(libpthread_libc_a_OBJS:.o=.os) $(libpthread_ld_tls_COBJ:.o=.os)
 else
-libc-static-y += $(libc-static-routines-y) $(libpthread_libc_a_OBJS) # 
$(libpthread_ld_tls_COBJ)
+libc-static-y += $(libc-static-routines-y) $(libpthread_libc_a_OBJS) 
$(libpthread_ld_tls_COBJ)
 endif
 
 librt-pt-routines-y := $(patsubst 
%.c,$(libpthread_pthread_OUT)/%.o,$(filter-out $(notdir 
$(libpthread_librt_OBJS:.o=.c)), $(librt-pt-routines-y)))
-- 
1.7.2.3

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

static linking is broken with -ldl

2010-09-08 Thread Natanael Copa 
Hi,

It seems like static linking is broken when -ldl is there:

ncdev:~/testcase$ cat dlopen-test.c
#include 
#include 

int main(int argc, char *argv[])
{
return dlopen(argv[1], RTLD_NOW) != NULL;
}
ncdev:~/testcase$ gcc -static  dlopen-test.c -ldl
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `_dl_load_elf_shared_library':
libdl.c:(.text._dl_load_elf_shared_library+0xa7c): undefined reference
to `_dl_next_tls_modid'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `dlopen':
libdl.c:(.text.dlopen+0x419): undefined reference to `_dl_add_to_slotinfo'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):(.text._dl_do_reloc+0x189):
undefined reference to `_dl_allocate_static_tls'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):(.text._dl_do_reloc+0x1a7):
undefined reference to `_dl_allocate_static_tls'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../../i486-alpine-linux-uclibc/bin/ld:
a.out: hidden symbol `_dl_allocate_static_tls' isn't defined
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../../i486-alpine-linux-uclibc/bin/ld:
final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

the missing symbols seems to be defined in
ldso/ldso/dl-tls.c

Ater grepping around in the source tree my first reaction was to do
something like:

diff --git a/ldso/libdl/libdl.c b/ldso/libdl/libdl.c
index 3957e84..d0cbfe8 100644
--- a/ldso/libdl/libdl.c
+++ b/ldso/libdl/libdl.c
@@ -117,6 +117,7 @@ struct r_debug *_dl_debug_addr = NULL;
  * static TLS area, see __libc_setup_tls (libc-tls.c).
  */
 size_t _dl_tls_static_size = 2048;
+#include "../ldso/dl-tls.c"
 # endif
 #include LDSO_ELFINTERP
 #include "../ldso/dl-hash.c"

But that gave lots of duplicate symbols when building apk-tools static
(alpine linux package manager)
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libc.a(libc-tls.os):
In function `_dl_tls_setup':
libc-tls.c:(.text._dl_tls_setup+0x0): multiple definition of `_dl_tls_setup'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):libdl.c:(.text._dl_tls_setup+0x0):
first defined here
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libc.a(sigaction.os):
In function `__libc_sigaction':
sigaction.c:(.text.__libc_sigaction+0x0): multiple definition of
`__libc_sigaction'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text.__libc_sigaction+0x0):
first defined here
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libc.a(sigaction.os):
In function `sigaction':
sigaction.c:(.text.__sigaction+0x0): multiple definition of `__sigaction'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text.__sigaction+0x0):
first defined here
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `_dl_deallocate_tls':
libdl.c:(.text._dl_deallocate_tls+0x49): undefined reference to
`_dl_initial_dtv'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `_dl_update_slotinfo':
libdl.c:(.text._dl_update_slotinfo+0xf5): undefined reference to
`_dl_initial_dtv'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `__tls_get_addr':
libdl.c:(.text.__tls_get_addr+0x80): undefined reference to `_dl_memalign'
/usr/lib/gcc/i486-alpine-linux-uclibc/4.4.4/../../../libdl.a(libdl.os):
In function `_dl_allocate_tls_storage':
libdl.c:(.text._dl_allocate_tls_storage+0x22): undefined reference to
`_dl_memalign'
collect2: ld returned 1 exit status

Anyone have idea what the proper fix is?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bug in ld.so when called via dlopen()

2010-08-27 Thread Natanael Copa 
On Fri, Aug 27, 2010 at 3:06 PM, Joakim Tjernlund
 wrote:
> Natanael Copa  wrote on 2010/08/27 14:39:50:
>>
>> On Fri, Aug 27, 2010 at 9:53 AM, Joakim Tjernlund
>>  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have an issue with lua and a lua binding to c-client[1], limap[2].
>> >> libc-client calls some callback functions supposed to be implemented
>> >> in the main application.
>> >>
>> >> So various mm_* functions are implemented in limap.c as callbacks, for
>> >> example mm_dlog().
>> >>
>> >> But when lua does dlopen() to load the module i get error:
>> >> lua: symbol 'mm_dlog': can't resolve symbol in lib 
>> >> '/usr/lib/libc-client.so.1'
>> >>
>> >> I have simplified testcase here:
>> >> wget -O - http://dev.alpinelinux.org/~ncopa/uclibc-dlopen-testcase.tar.gz
>> >> | tar -zxf
>> >>
>> >> Both bar and baz works with glibc and bar fails on uclibc. Might be i
>> >> do something wrong?
>> >
>> > Didn't look into your testcase but uClibc differs from glibc w.r.t 
>> > dependencies.
>> > You need to have corrected DT_NEEDED entries in your libs that reflect
>> > the true deps. At least it was like so when I impl. it but I have
>> > no idea if NPTL changes this.
>>
>> might be i'm doing it wrong since phps imap plugin seems to work, and
>> it is linked to c-client.
>>
>> > I think this is required in the specs. but glibc is more forgiving.
>>
>> how should the linker flags be then, in my examples?
>
> libfoo.so depends on foo_callback which is in plugin.so but
> libfoo.so does not depend on plugin.so so you need to add
> plugin.so in libfoo.so's DT_NEEDED

This means that c-client by design wont work with other .so files on
uclibc and the world needs a properly written imap client C library.
sigh...

I suppose i can use static c-client library for my lua module.

I wonder how php work around this since it seems to work there?

Thanks!

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bug in ld.so when called via dlopen()

2010-08-27 Thread Natanael Copa 
On Fri, Aug 27, 2010 at 9:53 AM, Joakim Tjernlund
 wrote:
>>
>> Hi,
>>
>> I have an issue with lua and a lua binding to c-client[1], limap[2].
>> libc-client calls some callback functions supposed to be implemented
>> in the main application.
>>
>> So various mm_* functions are implemented in limap.c as callbacks, for
>> example mm_dlog().
>>
>> But when lua does dlopen() to load the module i get error:
>> lua: symbol 'mm_dlog': can't resolve symbol in lib 
>> '/usr/lib/libc-client.so.1'
>>
>> I have simplified testcase here:
>> wget -O - http://dev.alpinelinux.org/~ncopa/uclibc-dlopen-testcase.tar.gz
>> | tar -zxf
>>
>> Both bar and baz works with glibc and bar fails on uclibc. Might be i
>> do something wrong?
>
> Didn't look into your testcase but uClibc differs from glibc w.r.t 
> dependencies.
> You need to have corrected DT_NEEDED entries in your libs that reflect
> the true deps. At least it was like so when I impl. it but I have
> no idea if NPTL changes this.

might be i'm doing it wrong since phps imap plugin seems to work, and
it is linked to c-client.

> I think this is required in the specs. but glibc is more forgiving.

how should the linker flags be then, in my examples?


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

bug in ld.so when called via dlopen()

2010-08-26 Thread Natanael Copa 
Hi,

I have an issue with lua and a lua binding to c-client[1], limap[2].
libc-client calls some callback functions supposed to be implemented
in the main application.

So various mm_* functions are implemented in limap.c as callbacks, for
example mm_dlog().

But when lua does dlopen() to load the module i get error:
lua: symbol 'mm_dlog': can't resolve symbol in lib '/usr/lib/libc-client.so.1'

I have simplified testcase here:
wget -O - http://dev.alpinelinux.org/~ncopa/uclibc-dlopen-testcase.tar.gz
| tar -zxf

Both bar and baz works with glibc and bar fails on uclibc. Might be i
do something wrong?


Pasted below:
# Makefile
run: bar baz plugin.so
LD_LIBRARY_PATH=. ./baz
LD_LIBRARY_PATH=. ./bar

bar_LDFLAGS= -ldl
bar: bar.c
$(CC) $($...@_cflags) -o $@ $($...@_ldflags) $^

baz: baz.c libfoo.so
$(CC) $($...@_cflags) -o $@ $($...@_ldflags) $^

plugin.so_LDFLAGS= -L. -lfoo
plugin.so: plugin.c libfoo.so
$(CC) $($...@_cflags) -fPIC -o $@ -shared $($...@_ldflags) $^

libfoo.so: foo.c
$(CC) $($...@_cflags) -fPIC -o $@ -rdynamic -shared
-Wl,-soname,libfoo.so $($...@_ldflags) $^

clean:
rm -f plugin.so libfoo.so bar baz
# eof

/* bar.c */
#include 
#include 

int main()
{
int (*run)(void) = NULL;
void *h = dlopen("./plugin.so", RTLD_NOW);
if (h == NULL)
return 1;

run = dlsym(h, "run");
return run();
}
/* eof */

/* baz.c */
#include 
int foo_run(void);

int foo_callback(void)
{
printf("Hello from baz foo_callback()\n");
return 0;
}

int main(void)
{
return foo_run();
}
/* eof */

/* foo.c */
#include 

int foo_callback(void);

int foo_run(void)
{
printf("running callback from foo_run()\n");
return foo_callback();
}
/* eof */

/* plugin.c */
#include 

int foo_run(void);

int foo_callback(void)
{
printf("Hello from plugin.so foo_callback()\n");
return 0;
}

int run(void) {
return foo_run();
}

int main(void)
{
return run();
}   
/* eof */


-- 
Natanael Copa

[1] http://www.washington.edu/imap/documentation/internal.txt.html
[2] http://www.raschke.pwp.blueyonder.co.uk/limap.c
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] create DEVEL_PREFIX/MULTILIB_DIR dir rather than DEVEL_PREFIX/lib

2010-08-24 Thread Natanael Copa 
This fixes issue with GNU Make 3.82 when running:

 make install DESTDIR=$someplace

Signed-off-by: Natanael Copa 
---
 Makefile.in |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 1c0e305..bffe998 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -289,10 +289,10 @@ HEADERS_RM-$(UCLIBC_SUSV4_LEGACY)+= utime.h
### ucontext.h
 
 ifneq ($(findstring install,$(MAKECMDGOALS)),)
-$(addprefix $(PREFIX)$(DEVEL_PREFIX),include lib):
+$(addprefix $(PREFIX)$(DEVEL_PREFIX),include $(MULTILIB_DIR)):
$(do_mkdir)
 # avoid warning about duplicate targets in rule or overrides
-ifneq ($(abspath $(RUNTIME_PREFIX)$(MULTILIB_DIR)),$(abspath 
$(DEVEL_PREFIX)lib))
+ifneq ($(abspath $(RUNTIME_PREFIX)$(MULTILIB_DIR)),$(abspath 
$(DEVEL_PREFIX)$(MULTILIB_DIR)))
 $(PREFIX)$(RUNTIME_PREFIX)$(MULTILIB_DIR):
$(do_mkdir)
 endif
-- 
1.7.2.2

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

make install DESTDIR=$something does not work with gnu make-3.82

2010-08-23 Thread Natanael Copa 
I get this error:

>>> libc0.9.32: Entering fakeroot...
  MKDIR /home/ncopa/aports/main/libc0.9.32/pkg/libc0.9.32/lib/
make: *** No rule to make target
`/home/ncopa/aports/main/libc0.9.32/pkg/libc0.9.32/usr/lib/', needed
by `install_dev'.  Stop.
make: *** Waiting for unfinished jobs
  HOSTCC extra/scripts/unifdef
  MKDIR /home/ncopa/aports/main/libc0.9.32/pkg/libc0.9.32/usr/include
make[1]: `lib/ld-uClibc.so' is up to date.

I also noticed there are various intentional compat breakage changes
in gnu make 3.82, so i'm not really surprised.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] netdb: increase line size for /etc/services

2010-08-19 Thread Natanael Copa 
On Thu, Aug 19, 2010 at 10:13 AM, Natanael Copa  wrote:
> On Wed, Aug 18, 2010 at 7:04 PM, Bernhard Reutner-Fischer
>  wrote:
>> On Wed, Aug 11, 2010 at 12:06:22PM +0000, Natanael Copa wrote:
>>>If /etc/services has lines longer than 80 will getservbyname() fail
>>>so we set it up to 160.
>>
>> I'd prefer something like the attached, does that fix your issue?
>> thanks,
>
> Yes, my testcase no longer exit with error.
>
> #include 
> #include 
>
> int main(void)
> {
>        if (getservbyname("ntp", "udp") == NULL)
>                err(1, "getservbyname");
>        return 0;
> }


but it does not seem to solve same issue with getprotobyame("gre") if
there are any comment longer than 80 chars in /etc/protocols.


-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] netdb: increase line size for /etc/services

2010-08-19 Thread Natanael Copa 
On Wed, Aug 18, 2010 at 7:04 PM, Bernhard Reutner-Fischer
 wrote:
> On Wed, Aug 11, 2010 at 12:06:22PM +0000, Natanael Copa wrote:
>>If /etc/services has lines longer than 80 will getservbyname() fail
>>so we set it up to 160.
>
> I'd prefer something like the attached, does that fix your issue?
> thanks,

Yes, my testcase no longer exit with error.

#include 
#include 

int main(void)
{
if (getservbyname("ntp", "udp") == NULL)
err(1, "getservbyname");
return 0;
}





-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] netdb: increase line size for /etc/services

2010-08-11 Thread Natanael Copa 
If /etc/services has lines longer than 80 will getservbyname() fail
so we set it up to 160.

Signed-off-by: Natanael Copa 
---
 libc/inet/getservice.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libc/inet/getservice.c b/libc/inet/getservice.c
index 03f5c29..8248f7a 100644
--- a/libc/inet/getservice.c
+++ b/libc/inet/getservice.c
@@ -29,7 +29,7 @@ aliases: case sensitive optional space or tab separated list 
of other names
 __UCLIBC_MUTEX_STATIC(mylock, PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP);
 
 #defineMAXALIASES  35
-#define BUFSZ  (80) /* one line */
+#define BUFSZ  (160) /* one line */
 #define SBUFSIZE   (BUFSZ + 1 + (sizeof(char *) * MAXALIASES))
 
 static parser_t *servp = NULL;
-- 
1.7.2.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Configure uClibc for maximum glibc compatibility

2010-08-05 Thread Natanael Copa 
On Thu, Aug 5, 2010 at 11:04 PM, Evan Kroske  wrote:
> I want to configure uClibc so that the vast majority of applications
> written for glibc compile correctly. Until now, I've been compiling
> applications, receiving compile errors, and flipping the necessary
> switches. Should I just `make allyesconfig` and disable the features I
> know I won't need, or is there a better way to ensure glibc
> compatibility? If someone has created a highly-compatible config file,
> I would like to see it. Thanks.

The Alpine Linux uClibc works with most apps. Could be a start for you:
http://git.alpinelinux.org/cgit/aports/tree/main/libc0.9.32/uclibcconfig.x86

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] nptl: do not define _POSIX_SPAWN since its not implemented

2010-07-30 Thread Natanael Copa 
From: Natanael Copa 

Building things like vlc checks if _POSIX_SPAWN is defined. Since
posix_spawn is not implemented we dont define it.
---
 .../nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h  |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h 
b/libpthread/nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h
index 2550355..6fbdbb7 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h
@@ -143,8 +143,10 @@
 /* We support spinlocks.  */
 #define _POSIX_SPIN_LOCKS  200809L
 
+#if 0
 /* The `spawn' function family is supported.  */
 #define _POSIX_SPAWN   200809L
+#endif
 
 /* We have POSIX timers.  */
 #define _POSIX_TIMERS  200809L
-- 
1.7.2

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: compiling libtirpc and rpcbind against uclibc-0.9.30.2

2010-07-07 Thread Natanael Copa 
On Wed, Feb 3, 2010 at 11:54 PM, Bernhard Reutner-Fischer
 wrote:
> On Tue, Feb 02, 2010 at 11:10:16AM +0100, Natanael Copa wrote:
>>Hi,
>>
>>I think the idea was to drop the rpc stuff from uclibc and rely on
>>libtirpc and rpcbind.
>
> indeed.
>>
>>I have been able to compile libgssglue, heimdal and libtirpc against
>>uclibc but i get a linker error when trying to compile rpcbind.
...
>>As I understand those are not implemented in uclibc, and never will
>>since we are supposed to rely on libtirpc and rpcbind.
>
> exactly.
>>
>>I would guess we have the following options:
>>
>>1. have libtirpc to use openssl for the crypto funcs
>>2. have libtirpc to use gnutls for the crypto funcs
>>3. implement key_encryptsession_pk, getnetname, cbc_crypt, ecb_crypt,
>>getpublickey and key_gendes in uclibc.
>
> I'd go for 1 or 2 (or vice versa).

Just wanted to share some progress here. It showed to be an issue with
libtircp and auth_des. By patching the makefile to libtirpc and simply
remove anything auth_des related things just worked.

Patches I needed are found here:
http://git.alpinelinux.org/cgit/aports/tree/main/libtirpc

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] bits/socket.h: add SOCK_CLOEXEC and SOCK_NONBLOCK support

2010-06-01 Thread Natanael Copa 
On Tue, Jun 1, 2010 at 4:02 PM, Vladimir Zapolskiy  wrote:
> This patch adds support for SOCK_CLOEXEC and SOCK_NONBLOCK socket
> descriptor flags, which are introduced since Linux 2.6.27

Nice! I was looking at this the other day but never had time to finish it.

Did you get (recent) udev working with those patches?

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: 1.0 release?

2010-05-11 Thread Natanael Copa 
On Mon, May 10, 2010 at 1:22 PM, Bernhard Reutner-Fischer
 wrote:
> On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote:
>>On (10/05/10 00:02), Rob Landley wrote:
>>> So now that NPTL is in, it sounds like the next release should be either 1.0
>>> or 1.0-pre.  It is more or less feature complete, isn't it?
>>
>>yeah I have mentioned it on IRC couple of times to have next release be 1.0
>
> the nptl addition would warrant bumping the version to 0.10.0, yes.
> I don't think messing around with the major version and thus
> UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers.

Its easy to keep the dynamic linker even if you bump major version:

diff --git a/Rules.mak b/Rules.mak
index fd0de49..8ff9f2d 100644
--- a/Rules.mak
+++ b/Rules.mak
@@ -108,7 +108,7 @@ MINOR_VERSION := 9
 SUBLEVEL  := 32
 EXTRAVERSION  :=-git
 VERSION   := $(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL)
-ABI_VERSION   := $(MAJOR_VERSION)
+ABI_VERSION   := 0
 ifneq ($(EXTRAVERSION),)
 VERSION   := $(VERSION)$(EXTRAVERSION)
 endif
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: 1.0 release?

2010-05-10 Thread Natanael Copa 
On Mon, May 10, 2010 at 1:22 PM, Bernhard Reutner-Fischer
 wrote:
> On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote:
>>On (10/05/10 00:02), Rob Landley wrote:
>>> So now that NPTL is in, it sounds like the next release should be either 1.0
>>> or 1.0-pre.  It is more or less feature complete, isn't it?
>>
>>yeah I have mentioned it on IRC couple of times to have next release be 1.0
>
> the nptl addition would warrant bumping the version to 0.10.0, yes.
> I don't think messing around with the major version and thus
> UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers.

Would be nice with a beta tag/release unless there are more new
features you want in there.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

2010-05-10 Thread Natanael Copa 
On Mon, May 10, 2010 at 6:28 AM, Rob Landley  wrote:

> It built with CPUS=1, but when I took that out and it autodetected an SMP
> build (it does real CPUs *1.5, thus make -j 3 in this case), the build died
> with:
>
>  CC libpthread/nptl/sysdeps/unix/sysv/linux/gen_lowlevelbarrier.s
> In file included from ./include/sys/syscall.h:24,
>                 from ./libc/sysdeps/linux/common/sysdep.h:20,
>                 from ./libc/sysdeps/linux/powerpc/sysdep.h:19,
>                 from libpthread/nptl/sysdeps/powerpc/tcb-offsets.c:1:
> ./include/features.h:187:33: error: bits/uClibc_config.h: No such file or
> directory

I got this too and worked around it with:

make -j 1 pregen
make -j $JOBS

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [OT] Re: alpine linux now officially uses uclibc with nptl

2010-05-06 Thread Natanael Copa 
2010/5/5 Rafael Diniz :

> And how about x86_64, is uclibc/nptl running fine? Will be an Alpine Linux
> x86_64?

Yes, sooner or later. Probably after alpine-2.0. Thanks to nptl this
is possible.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

alpine linux now officially uses uclibc with nptl

2010-05-05 Thread Natanael Copa 
Hi,

Last night we rebuild basicly all packages against uclibc with nptl
which means that alpine linux (x86) now officially run uclibc with
nptl. (first distro that does?)

Bootstrapping the toolchain required crosscompile but the runtime
environment upgrades was smooth.

So far it seems like uclibc/nptl works better than anything ever
worked before. (I'm writing this from my netbook running midori, xfce
powered by uclibc with nptl)

Time for an 0.9.32 alfa, beta or rc release?

Thanks alot for the hard work you are putting in uclibc.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

2010-05-03 Thread Natanael Copa 
On Mon, May 3, 2010 at 8:11 PM, Laurent Bercot  wrote:

>  That's fine, as long as the support for ABI_VERSION does not impact
> code that does not use it. If statically linked code is somehow made less
> efficient by adding dynamic ABI_VERSION support, not everyone's happy.
> If the libc.so dynamic code is somehow made bigger by adding dynamic
> ABI_VERSION support and users don't need it, not everyone's happy.

As I said: everyone is happy.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

2010-05-03 Thread Natanael Copa 
2010/5/3 Lennart Sorensen :
> On Mon, May 03, 2010 at 08:14:38AM +0300, Timo Teräs wrote:
>> Yes, static linking would be more bullet proof. But either the user, or
>> the package manager needs jump through hoops in this case. There needs to
>> be the static versions compiled, they need to get installed, then finally
>> replaced with dynamic versions, etc.
>
> Why would it need to be replaced with a dynamic version?  Why could the
> package manager not always be staticly linked and ust stay that way?

because you want avoid 10 times bigger binary? (alpine linux's
apk-tools is 90k dynamic and 900k static due to libcrypto for
hashing/signing)

Yes for upgrade, I'll probably recommend do that with static version
and maybe even tell people to manually replace /bin/busybox with
/bin/busybox.static.

Still i think beeing able to set ABI_VERSION is a good idea.

>> I'm not saying everyone needs to use this. I'm not asking support for this.
>> I'm not even recommending this for anyone.
>>
>> I only want to do it myself, because it solves my immediate problems
>> with less work and more user friendly way than static linking. The package
>> manager is there to handle the other issues.
>
> Well user friendly to who?  Less work for who?  It sounds like just
> linking the package manager and related tools staticly solves everything.
> Sounds like the least work of all.

But the price is that extra bloat for libcrypto, libz and uclibc dupe
code in there. I do understand that some people are willing to pay
that price. No problem. Current git is good. Everyone is happy. Lets
move on.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: merging nptl into master now

2010-04-24 Thread Natanael Copa 
On Fri, Apr 23, 2010 at 5:33 PM, Austin Foxley  wrote:
> On 04/23/2010 10:16 AM, Austin Foxley wrote:
>> Will send email when complete
>
> It's IN!
>
> Congratulations to everybody who has worked on this branch over the last
> _6_ years.

Wow! Congratulations!

> Now let's get it polished up and ready for a 0.9.32 release!

would it be an idea to make a beta or rc release?

We have compiled every package in Apline Linux against nptl branch
(x86). Next week I'll work more on the upgrade path and start doing
some serious runtime tests.

Thanks!

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] utils: fix install prefix for getconf

2010-04-22 Thread Natanael Copa 
So we don't get /usr/usr/bin/getconf when DEVEL_PREFIX="/usr"

Signed-off-by: Natanael Copa 
---
 utils/Makefile.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/utils/Makefile.in b/utils/Makefile.in
index 89cb800..8cb06a3 100644
--- a/utils/Makefile.in
+++ b/utils/Makefile.in
@@ -117,7 +117,7 @@ install-y += utils_install
 # This installs both utils and hostutils, so doesn't depend on either.
 
 utils_install: $(addsuffix $(DOTHOST), $(utils_OBJ) $(utils_LOCALE_OBJ))
-   $(Q)$(INSTALL) -D -m 755 $(utils_OUT)/getconf$(DOTHOST) 
$(PREFIX)$(DEVEL_PREFIX)usr/bin/getconf
+   $(Q)$(INSTALL) -D -m 755 $(utils_OUT)/getconf$(DOTHOST) 
$(PREFIX)$(DEVEL_PREFIX)bin/getconf
 ifeq ($(HAVE_SHARED),y)
$(Q)$(INSTALL) -D -m 755 $(utils_OUT)/ldd$(DOTHOST) 
$(PREFIX)$(DEVEL_PREFIX)bin/ldd
$(Q)$(INSTALL) -D -m 755 $(utils_OUT)/ldconfig$(DOTHOST) 
$(PREFIX)$(RUNTIME_PREFIX)sbin/ldconfig
-- 
1.7.0.5

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

2010-04-22 Thread Natanael Copa 
On Thu, Apr 22, 2010 at 12:10 PM, Michael Deutschmann
 wrote:
> On Thu, 22 Apr 2010, Natanael Copa wrote:
>> Do you have any better suggestions how to upgrade a running system?
>
> First, build the new uClibc, but don't install it yet.
>
> Build a customized ld-uclibc.so.0, from the previous uClibc source, that
> looks in a different place for shared libraries and ignores the
> /etc/ld.so.* files.  Install it under a different filename.
>
> Write a utility to modify the INTERP filename specified in an executable
> from "/lib/ld-uclibc.so.0" to the filename of the special ld.so.  (This is
> much simpler if the temporary ld.so filename is the same length as the
> original.)
>
> Hardlink the existing shared libraries into the alternate position, then
> hack every existing installed executable in this way.
>
> Then, delete all the old libraries in /usr/lib and the include files. The
> shared libraries will be preserved by the hardlink, while everything else
> is dispensible.  The system should still work for everything except
> compilation.
>
> Now, install the new uClibc.  Unless the ABI is so thoroughly broken as
> to invalidate the old specs or libgcc.a, you should now be able to compile
> new binaries.
>
> I intend to do something like this for my 0.9.30.3 to 0.9.31 rollover,
> but I haven't finished writing the necessary utilities yet.

I have hard time to understand how that is superior to change sonames:

old gcc-x.y-1 and old apps are linked to libc.so.0
compile libc.so.0.9.31 and upgrade (replace) developerment package and
install new libc runtime side-by side.

At this point all binaries/libs will work as excepted, just like with
your hardlink trick (except instead of hardlinking you use different
names) but new packages will be linked to libc.so.0.9.32.

with old gcc rebuild gcc-x.y-2 with libc.so.0.9.32 as dependency.
do the same with every other package in dependency order.

Package manager can safely keep track of what package it needs to work
properly. Thats what package managers are for and that is how most
distros handles abi changes in libraries.

Yes i know uclibc is not really targetting packagemanagers, but making
ABI_VERSION overrideable will make it work, even if other might prefer
ugly hacks with hardlinking and moving binaries.

-- 
Natanael Copa
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

  1   2   >