Re: Arm-linux-uclibcgnueabi/bin/as unrecognised option '-Qy'
On Thu, Aug 07, 2008 at 07:33:29PM +1200, Mark Easton wrote: Hi, I am getting the following error when I try to build BuildRoot for our arm Wrong list. Please see http://buildroot.uclibc.org/ device. It seems that the target version of as in build_arm/staging_dir/usr/arm-linux-uclibcgnueabi/bin/ does not recognize the option '-Q'. I see that my host version of /usr/bin/as does support this option. I cannot see where to fix this. I guess, either I need to modify a makefile somewhere or I need a new vesion of as to place in to build_arm/staging_dir/usr/arm-linux-uclibcgnueabi/bin/. Can anyone help me? You are trying to build a deprecated gcc version. Wipe your obj-tree and retry with the current, stable release. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: MIPS and gcc-4.3.1
On Wed, Aug 06, 2008 at 12:03:58AM +0200, Yann E. MORIN wrote: On Tuesday 05 August 2008 23:56:19 Yann E. MORIN wrote: OK. Here's one that turns all 'asm' and '__asm' into '__asm__'. Not many of them, there was. Woops... wrong patch... Here the correct one... Applied as r23060. Thanks! ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: SOCK_STREAM and SOCK_DGRAM for MIPS
On Tue, Aug 05, 2008 at 02:03:51PM +0200, Dongsu Park wrote: Hi, playing with OpenWRT 7.09 and uClibc 0.9.28.2 on MIPS architecture, I have just found an interesting fact about uClibc. In libc/sysdeps/linux/mips/bits/socket.h, SOCK_STREAM is defined as 2, SOCK_DGRAM as 1. But in bits/socket.h for any other architectures e.g alpha, sparc etc., SOCK_STREAM is 1 and SOCK_DGRAM is 2. Why are they different like that? Is there any reason that the socket constants should be defined differently only for MIPS architecture? ISTR that MIPS has this backwards for historical reasons. All is well. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: MIPS and gcc-4.3.1
On Tue, Aug 05, 2008 at 03:11:29PM +0200, Yann E. MORIN wrote: Hello again! Hi Yann, So I do not know where this '__typeof' comes from, but we'd be better using '__typeof__' instead, no? I'd go for __typeof__, yes. Did I miss something else? No, that's perfectly fine. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: MIPS and gcc-4.3.1
On Tue, Aug 05, 2008 at 03:11:29PM +0200, Yann E. MORIN wrote:
So I do not know where this '__typeof' comes from, but we'd be better using
'__typeof__' instead, no?
I was just about to apply it blindly (don't remember if you have
write-access), but you seem to be setup to actually test it :)
find ./ \( -name *.[ch] -o -name *.inc \) -exec \
sed -i -e /typeof[[:space:]]*(/s/[_]*typeof[_]*/__typeof__/; {} \;
I didn't look if comments would trigger, those should be omitted from
what gets applied.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: ifaddrs.h header not installed
On Tue, Aug 05, 2008 at 06:59:30PM +0200, Yann E. MORIN wrote: Hello Ricard and All! Heya Yann, On Tuesday 05 August 2008 16:57:54 Ricard Wanderlof wrote: include/ifaddrs.h was not the same as libc/inet/ifaddrs.h [--SNIP--] Yes, I've seen that. I was suggesting to go back to the situation prior to r22534, when ifaddrs.h was installed, and not reverting its content. Sorry for the confusion... since we didn't need it outside uclibc anyway. Well, I'm not quite confortable with that: it's dependent on a config option, we build it, it's in the libc.so, but noone should use it? Anyway, we've got one user at least: the Java frontend from gcc-4.3.1. However, I can't see a problem with making it globally accessible, so the change you propose So I moved ifaddrs.h back to the include/ directory, also changed back libc/inet/ifaddrs.c and libc/inet/getaddrinfo.c to #include ifaddrs.h (instead of ifaddrs.h), and the build completes. should be ok. Check that the whole shebang builds properly if UCLIBC_SUPPORT_AI_ADDRCONFIG is not defined. The whole .h file should be guarded with __UCLIBC_SUPPORT_AI_ADDRCONFIG__ and processed through unifdef to remove its content if uClibc is not configured as such. Or better yet, there are a bunch of includes that get removed at install time. Let's add one more. Exactly. Where was that thread again? yep: http://uclibc.org/lists/uclibc/2008-June/019653.html Ok with the following addition (or something to that effect): Thanks! Index: Makefile.in === --- Makefile.in (revision 23052) +++ Makefile.in (working copy) @@ -331,6 +331,10 @@ ifneq ($(UCLIBC_HAS_CRYPT),y) # Remove crypt.h since libcrypt was disabled upon request $(RM) $(PREFIX)$(DEVEL_PREFIX)include/crypt.h endif +ifneq ($(UCLIBC_SUPPORT_AI_ADDRCONFIG),y) + # Remove bits/ifaddrs.h.h since it was disabled upon request + $(RM) $(PREFIX)$(DEVEL_PREFIX)include/ifaddrs.h +endif # Installs development library links. install_dev: install_headers Index: uClibc/libc/inet/ifaddrs.c === --- uClibc/libc/inet/ifaddrs.c (revision 23002) +++ uClibc/libc/inet/ifaddrs.c (working copy) @@ -22,7 +22,7 @@ #include alloca.h #include assert.h #include errno.h -#include ifaddrs.h +#include ifaddrs.h #include net/if.h #include netinet/in.h #include netpacket/packet.h Index: uClibc/libc/inet/getaddrinfo.c === --- uClibc/libc/inet/getaddrinfo.c (revision 23002) +++ uClibc/libc/inet/getaddrinfo.c (working copy) @@ -68,7 +68,7 @@ #include sys/un.h #include sys/utsname.h #include net/if.h -#include ifaddrs.h +#include ifaddrs.h /* Experimentally off - libc_hidden_proto(memcpy) */ /* Experimentally off - libc_hidden_proto(memset) */ ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: MIPS and gcc-4.3.1
On Tue, Aug 05, 2008 at 07:48:52PM +0200, Yann E. MORIN wrote:
Heyda Bernhard and All!
$ svn blame Rules.mak
[--SNIP--
| 22868 aldot # Make sure that we can be built with non-C99 compilers,
too.
| 22868 aldot # Use __\1__ instead.
| 22868 aldot CFLAGS += $(call check_gcc,-fno-asm,)
The change is really recent:
$ svn log -r 22868
r22868 | aldot | 2008-07-17 18:54:31 +0200 (Thu, 17 Jul 2008) | 4 lines
- poison non-standard keywords:
Make sure that we can be built with non-C99 compilers, too.
Use __\1__ instead.
Hmmm. Who's 'aldot', by the way? I can't seem to remember... ;-) Hehe!
That'd be /me
We should audit the code for other keywords that ought to be replaced
with __\1__. We should also provide macros for those when we're not
using gcc. x86_64 bombed on me in libc/sysdeps/linux/x86_64/sigaction.c
at line 147:
[--SNIP--]
| #define RESTORE(name, syscall) RESTORE2 (name, syscall)
| # define RESTORE2(name, syscall) \
| asm \
drats. Yes the '(' on a separate line certainly escaped my sed, sorry.
| ( \
|.text\n \
|__ #name :\n \
|movq $ #syscall , %rax\n \
|syscall\n \
|);
| #ifdef __NR_rt_sigaction
| /* The return code for realtime-signals. */
| RESTORE (restore_rt, __NR_rt_sigreturn)
| #endif
| #ifdef __NR_sigreturn
| RESTORE (restore, __NR_sigreturn)
| #endif
Which expands to something like (with my .config):
| # 147 libc/sysdeps/linux/x86_64/sigaction.c
| asm ( .text\n __ restore_rt :\nmovq $ 15 , %rax\n
syscall\n );
From the gcc manual, we need to protect 'asm', 'inline', 'typeof', and
'restrict' (do we use the latest?) and use the alternate forms __\1__.
I think the restrict shouldn't bite (didn't bite me on ia32 and amd64,
at least -- YMMV).
I didn't look if comments would trigger, those should be omitted from
what gets applied.
OK, let me try... Will come back later with a patch.
TIA. The reasoning behind the no-asm is to be C89 compliant, FYI.
Although it is purely cosmetic, from a modern (GCC-)toolchain POV, it
certainly is something that i was bitten by at least while getting me a
comfortable setup on e.g. OSF/1. While this particular OS may be a bad
example since they dropped support for the HW i have access to, it's imo
a good thing to keep an eye on such janitorial tweaks. Sorry if this
caused any temporary grief for you, it was certainly not intended from
my part :)
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Microblaze - latest source
On Wed, Jul 30, 2008 at 02:46:04PM +0200, Michal Simek wrote: Hi everybody, I have some question about Microblaze support in uClibc. I look at Config.in and there is set BROKEN flags next to Microblaze label. Can someone explain me what does it mean? What is broken? $ svn log -r12209 extra/Configs/Config.in r12209 | vapier | 2005-11-11 04:06:13 +0100 (Fri, 11 Nov 2005) | 1 line mark all broken arches as such so people know not to expect too much Sounds like it's not actively maintained. Patches are welcome.. Microblaze community use 0.9.27 version and I would like to upgrade to latest version and fix all bugs which are in Microblaze part. and next question I have is about supporting *nat syscalls (openat, mknodat and others). Do you have any plan to add it? I do some changes on ancient 0.9.27 version and I do some test with it. I think uClibc should support them. And then I look at kernel source and compare it with libc declaration. I think that parameters should be the same. For example on mknod call. And others. Please correct me if I am wrong. static __inline__ _syscall3(int, __syscall_mknod, const char *, path, __kernel_mode_t, mode, __kernel_dev_t, dev); static __inline__ _syscall3(int, __syscall_mknod, const char *, path, __kernel_mode_t, mode, unsigned, dev); Please look at the current version of sysdeps/linux/common/mknod.c for details. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: ARM EABI / Thumb vs. gdb
On Thu, Jul 17, 2008 at 08:37:29AM -0700, Khem Raj wrote: Johannes Stezenbach wrote: Please consider merging this change into trunk. uclibc-nptl branch soon collapse into trunk so this changeset will make through. I've applied this to trunk as r22867: - pull fix for unwinding from the NPTL branch (Johannes Stezenbach) Repair C89 compliance and severe whitespace-defects while at it. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: ARM EABI / Thumb vs. gdb
On Thu, Jul 17, 2008 at 05:55:30PM +0200, Bernhard Fischer wrote: On Thu, Jul 17, 2008 at 08:37:29AM -0700, Khem Raj wrote: Johannes Stezenbach wrote: Please consider merging this change into trunk. uclibc-nptl branch soon collapse into trunk so this changeset will make through. I've applied this to trunk as r22867: - pull fix for unwinding from the NPTL branch (Johannes Stezenbach) Repair C89 compliance and severe whitespace-defects while at it. I'm tempted to apply something like the hunk below and disable it on release-branches. I've fixed i386 and alpha some time ago, but the other arches should also try to be gentle to people who are bootstrapping a comfortable environment for themselves (and thus may use non-C99 toolchains initially). Note that the version of ccc that i have access to doesn't even support the keyword volatile.. Index: include/features.h === --- include/features.h (revision 22866) +++ include/features.h (working copy) @@ -40,6 +40,17 @@ * a lot of expensive inlining... */ #define __OPTIMIZE_SIZE__ 1 +#ifdef _LIBC +/* make sure that we're gentle to oldish non-gcc: + asm - __asm__ + volatile - __volatile__ + */ +#undef asm +#define asm BUG_use__asm__instead +#undef volatile +#define volatile BUG_use__volatile_instead +#endif + /* These are defined by the user (or the compiler) to specify the desired environment: ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: 0.9.29 segfaulting.
On Mon, Jul 14, 2008 at 01:36:32AM -0500, Rob Landley wrote:
The gcc ./configure is compiling the following program and trying to run it:
main() {return 0;}
Dynamically linked, it works. Statically linked, running it segfaults
immediately, because __uClibc_init() is attempting to call _stdio_init() and
never making it. (If you add any function call to main, it works fine even
statically linked. Not sure why.)
Does it work on trunk? If so, which rev fixed it? (IIRC this was
fixed on trunk)
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: 0.9.29 segfaulting.
On Mon, Jul 14, 2008 at 07:24:11AM -0500, Rob Landley wrote:
On Monday 14 July 2008 03:05:27 Bernhard Fischer wrote:
On Mon, Jul 14, 2008 at 01:36:32AM -0500, Rob Landley wrote:
The gcc ./configure is compiling the following program and trying to run
it:
main() {return 0;}
Dynamically linked, it works. Statically linked, running it segfaults
immediately, because __uClibc_init() is attempting to call _stdio_init()
and never making it. (If you add any function call to main, it works
fine even statically linked. Not sure why.)
Does it work on trunk? If so, which rev fixed it? (IIRC this was
fixed on trunk)
After the previous build break, I did a make distclean and poked around in
The previous build-break is mine. Please turn on LINUX_SPECIFIC in the
Advanced menu for now. I'll fix that ASAP.
menuconfig a bit to make sure that the 0.9.29 miniconfig I was using was
sufficiently updated to current svn that I wasn't missing anything obvious.
Among other things, I enabled the build at once mode.
Now it's dying with:
libc/misc/internals/__errno_location.c:10: warning: asm declaration ignored
due to conflict with previous rename
libc/misc/internals/__errno_location.c:16: error: '__EI___errno_location'
aliased to undefined symbol '__GI___errno_location'
Yes, that's apparently coming from an allegedly incomplete merge from
mjn3 in the I/O layer. Dunno about details.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: 0.9.29 segfaulting.
On Mon, Jul 14, 2008 at 05:38:05AM -0500, Rob Landley wrote:
On Monday 14 July 2008 03:05:27 Bernhard Fischer wrote:
On Mon, Jul 14, 2008 at 01:36:32AM -0500, Rob Landley wrote:
The gcc ./configure is compiling the following program and trying to run
it:
main() {return 0;}
Dynamically linked, it works. Statically linked, running it segfaults
immediately, because __uClibc_init() is attempting to call _stdio_init()
and never making it. (If you add any function call to main, it works
fine even statically linked. Not sure why.)
Does it work on trunk?
No idea. Trunk hasn't built with my toolchain since svn 19932 broke it. I
thought I'd get around to fixing it when the next release came out, but it's
been 10 months since then and I've stopped waiting.
This was fixed without using iwithprefix a long time ago.
If so, which rev fixed it? (IIRC this was
fixed on trunk)
Is there likely to be another release in my lifetime? Perhaps a 0.9.29.1 with
bugfixes only?
You know that i don't play release-monkey, so i cannot answer this
question. I could point you to the archives for further details about
the release status, but i take it that you're well aware of it :P
Which trunk do you mean, anyway? The nptl branch that was supposedly going
There is one trunk and there may be branches, e.g. the nptl branch or
random other repos. I was referring to the official svn trunk.
to result in the next release? Or the one the web page links to when you
browse source? Or the one Peter Mazinger maintains? Or the one Gentoo's
using? Or the blackfin one that the project's maintainer works on at his day
job?
Rob
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/test: locale locale-mbwc
On Wed, Jul 09, 2008 at 05:08:40PM +0200, Carmelo AMOROSO wrote: Sounds like your revision 22684 broke the auto-testers since a plain $ make check doesn't work (anymore? Not sure if it worked before, i suspect it did). We need at least (Makefile.in): -test check: +test check: test_compile Also, the test dir has to pickup the correct flags, which it currently doesn't, i think. Care to have a look? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc...
On Thu, Jul 10, 2008 at 08:04:03AM -0700, Khem Raj wrote: On Thu, 2008-07-10 at 12:11 +0200, Carmelo AMOROSO wrote: Hi Khem, for my curiosity.. why did you need to add tls.h ? To get USE__TLS ISTR that this was a leftover from glibc, so perhaps we should put this into uClibc_config.h or get rid of it? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/libc: inet misc/sysvipc stdio sysdeps/linux/co etc...
On Thu, Jul 10, 2008 at 07:19:35PM +0200, Carmelo Amoroso wrote: 2008/7/10 Bernhard Fischer [EMAIL PROTECTED]: On Thu, Jul 10, 2008 at 08:04:03AM -0700, Khem Raj wrote: On Thu, 2008-07-10 at 12:11 +0200, Carmelo AMOROSO wrote: Hi Khem, for my curiosity.. why did you need to add tls.h ? To get USE__TLS ISTR that this was a leftover from glibc, so perhaps we should put this into uClibc_config.h or get rid of it? Indeed it was not required for me (sh4-nptl)... Khem may you check it again ? If it makes syncing easier, then we can keep them but in this case let's put it into uClibc_config.h with fiddle to pickup our notion of affairs. cheers, Bernhard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/test: locale locale-mbwc
On Wed, Jul 09, 2008 at 07:19:38AM -0700, [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-07-09 07:19:37 -0700 (Wed, 09 Jul 2008) New Revision: 22707 Log: Added new tests for 'locale' support- taken from glibc; added new part for testing UTF-8 encoding Added: branches/uClibc-nptl/test/locale-mbwc/ Shouldn't this also be added to trunk, i.e. would it have been better to add it to trunk and pull that addition into the branch? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: libc_hidden_proto removal en masse
On Tue, Jul 08, 2008 at 09:05:28AM +0200, Carmelo AMOROSO wrote: I'd like to highlight that we need to fix the testsuite build system. I've sent a patch recently putting together some suggestions by Bernard, Bernd and others. I'd like to have it reviewed so that it can be merged in. I remember that it looked reasonable but i admit that i didn't try it. If it works for you then please go ahead and install it. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] aio support for uClibc
On Fri, Jul 04, 2008 at 10:00:05PM +0200, Carmelo Amoroso wrote: Cristi Magherusan wrote: Hello, You can find attached the patch that adds into librt optional support for stubs of the aio functions, as I promised a few days ago. It's mostly a copy/paste from glibc, with a few modifications needed for it to compile, I hope I haven't missed anything and that there won't be license-related issues. Best regards, Cristi It may be worth running the open posix testsuite from the LTP, even only the AIO part just to verify that it is compliant and that all required interface are there. From a short glance, we want the exact opposite: No stubs but the real implementation. Also in my POV putting all the aio_*() into one librt/aio.c would be preferred, but that's just cosmetics, admittedly. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc aio support
On Mon, Jun 30, 2008 at 03:41:46PM +0300, Cristi Magherusan wrote: On Mon, 2008-06-30 at 15:06 +0300, Cristi Magherusan wrote: Are there any plans to include aio support in uClibc soon or should I do it myself? If so, which difficulty do you estimate for this task? I took a look at the code of uClibc and glibc and it seems trivial. yes. I'll soon make a patch for inclusion of aio in the official uClibc tree. Excellent. Just put it into the Advanced Library Settings (like e.g. epoll). Note that there are apparenly some (odd? leftover?) hunks for aio_cancel in hppa, alpha, sparc. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc aio support
On Mon, Jun 30, 2008 at 04:11:03PM +0300, Cristi Magherusan wrote: On Mon, 2008-06-30 at 14:45 +0200, Carmelo AMOROSO wrote: this will be appreciated. Please be sure that you will not get code from glibc licensed under GPLv3. The aio from glibc 2.8 is licensed under GPL 2.1 or later. Is that ok? uClibc is under LGPL-2.1, so yes (AFAIK). ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: extra/Configs include libc/inet
On Fri, Jun 27, 2008 at 02:08:45AM -0700, [EMAIL PROTECTED] wrote:
Author: ricardw
Date: 2008-06-27 02:08:44 -0700 (Fri, 27 Jun 2008)
New Revision: 22531
Log:
Added support for the AI_ADDRCONFIG flag in the hints-ai_flags parameter to
getaddrinfo(3).
Added: trunk/uClibc/include/ifaddrs.h
===
--- trunk/uClibc/include/ifaddrs.h (rev 0)
+++ trunk/uClibc/include/ifaddrs.h 2008-06-27 09:08:44 UTC (rev 22531)
@@ -0,0 +1,19 @@
+#ifndef _IFADDRS_H
+#include libc/inet/ifaddrs.h
I'm not convinced that the above will work well.
+#include stdbool.h
+#include stdint.h
+
+struct in6addrinfo
+{
+ enum {
+in6ai_deprecated = 1,
+in6ai_temporary = 2,
+in6ai_homeaddress = 4
+ } flags;
+ uint32_t addr[4];
+};
+
+extern void __check_pf (bool *seen_ipv4, bool *seen_ipv6)
Perhaps just use unsigned*seen as param.
+ attribute_hidden;
+
+#endif/* ifaddrs.h */
Modified: trunk/uClibc/libc/inet/Makefile.in
===
--- trunk/uClibc/libc/inet/Makefile.in 2008-06-27 04:30:48 UTC (rev 22530)
+++ trunk/uClibc/libc/inet/Makefile.in 2008-06-27 09:08:44 UTC (rev 22531)
@@ -14,7 +14,7 @@
ifneq ($(UCLIBC_HAS_IPV4)$(UCLIBC_HAS_IPV6),)
CSRC += getservice.c getproto.c hostid.c getnetent.c getnetbynm.c
getnetbyad.c \
inet_net.c herror.c if_index.c gai_strerror.c getaddrinfo.c \
- ether_addr.c ntohl.c ifaddrs.c ntop.c
+ ether_addr.c ntohl.c ifaddrs.c ntop.c check_pf.c
endif
ifeq ($(UCLIBC_HAS_IPV6),y)
CSRC += in6_addr.c
Added: trunk/uClibc/libc/inet/check_pf.c
===
--- trunk/uClibc/libc/inet/check_pf.c (rev 0)
+++ trunk/uClibc/libc/inet/check_pf.c 2008-06-27 09:08:44 UTC (rev 22531)
@@ -0,0 +1,65 @@
+/* Determine protocol families for which interfaces exist. Generic version.
+ Copyright (C) 2003, 2006 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 features.h
+#include ifaddrs.h
+#include netdb.h
+
+
+void
+attribute_hidden
+__check_pf (bool *seen_ipv4, bool *seen_ipv6)
+{
+ *seen_ipv4 = false;
+ *seen_ipv6 = false;
+#if __UCLIBC_SUPPORT_AI_ADDRCONFIG__
Turn it off and build with -Wundef, then fix it, please.
+ {
+/* Get the interface list via getifaddrs. */
+struct ifaddrs *ifa = NULL;
+struct ifaddrs *runp;
+if (getifaddrs (ifa) != 0)
+{
+ /* We cannot determine what interfaces are available. Be
+ optimistic. */
+ *seen_ipv4 = true;
No. Doesn't take __UCLIBC_HAS_IPV4__ into account.
+#if __UCLIBC_HAS_IPV6__
-Wundef
static int addrconfig (sa_family_t af)
{
int s;
int ret;
int saved_errno = errno;
-s = socket(af, SOCK_DGRAM, 0);
-if (s 0)
- ret = (errno == EMFILE) ? 1 : 0;
+bool seen_ipv4;
+bool seen_ipv6;
yea, no. one variable and mask them. Or, even better
unsigned __check_pf(void)
+
+__check_pf(seen_ipv4, seen_ipv6);
+if (af == AF_INET)
+ ret = (int)seen_ipv4;
+else if (af == AF_INET6)
+ ret = (int)seen_ipv6;
else
{
- close(s);
- ret = 1;
+ s = socket(af, SOCK_DGRAM, 0);
+ if (s 0)
+ ret = (errno == EMFILE) ? 1 : 0;
+ else
+ {
+ close(s);
+ ret = 1;
+ }
Why don't you just ret=1 and adjust ret later on accordingly?
Please look which one is smaller in this spot.
And please do not introduce warnings about using undefined preprocessor
tokens and also keep in mind that we ultimately want a libc that can be
configured as IPv6-only. Thanks.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Fix multiple DNS queries when negative results returned
On Fri, Jun 27, 2008 at 01:35:16PM +0200, Ricard Wanderlof wrote:
We had a problem whereby multiple DNS queries were being made against the
same host, even if a negative result was returned the first time. This
patch attempts to fix this by keeping track of which hosts returned
negative responses in the retry loop in__dns_lookup(). It can
significantly reduce corresponding network traffic in large networks.
Patch made against svn 22530 and included as an attachment as well as
inline for review.
/Ricard
Index: libc/inet/resolv.c
===
--- libc/inet/resolv.c(revision 22530)
+++ libc/inet/resolv.c(working copy)
@@ -757,6 +757,7 @@
#ifdef __UCLIBC_HAS_IPV4__
struct sockaddr_in sa;
#endif
+ bool negative_results[MAX_SEARCH + 1] = { 0 };
unsigned no_results;
if (got negative result)
no_results |= (1 variant)
Which one is smaller? size(1), please.
PS: Note that i personally think that the resolver code suffers from two
problems: 1) it's bloated 2) it doesn't work at all for IPv6-only.
and should thus be replaced by something that has neither of these
problems. ATM I don't have any sparetime to fix it.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: extra/Configs include libc/inet
On Fri, Jun 27, 2008 at 03:00:41PM +0200, Ricard Wanderlof wrote:
On Fri, 27 Jun 2008, Bernhard Fischer wrote:
Added: trunk/uClibc/include/ifaddrs.h
===
--- trunk/uClibc/include/ifaddrs.h (rev 0)
+++ trunk/uClibc/include/ifaddrs.h 2008-06-27 09:08:44 UTC (rev 22531)
@@ -0,0 +1,19 @@
+#ifndef _IFADDRS_H
+#include libc/inet/ifaddrs.h
I'm not convinced that the above will work well.
True, it won't work if ifaddrs.h is included outside uclibc (which we
wouldn't expect it to be).
I thought that we install everything from include/ on make install_dev,
except the headers that we explicitely wipe afterwards..
The bulk of this patch was stuff taken from glibc-2.7 , with the idea of
minimizing the amount of changes. A similar construct is used there, but
I'm not sure exactly how it works to be honest.
I propose to concatenate both include files to a single one and put it in
libc/inet, as the included definitions are only used there.
That sounds better since it's just a private header that should not be
installed, yes.
static int addrconfig (sa_family_t af)
{
int s;
int ret;
int saved_errno = errno;
-s = socket(af, SOCK_DGRAM, 0);
-if (s 0)
- ret = (errno == EMFILE) ? 1 : 0;
+bool seen_ipv4;
+bool seen_ipv6;
yea, no. one variable and mask them. Or, even better
unsigned __check_pf(void)
Again, the reason this function looks like it does is because it was
snitched from glibc. That is probably not a strong enough reason not to
change it though ... ?
I think that it's simple enough to provide a concise version that
has identical functionality.
+
+__check_pf(seen_ipv4, seen_ipv6);
+if (af == AF_INET)
+ ret = (int)seen_ipv4;
+else if (af == AF_INET6)
+ ret = (int)seen_ipv6;
else
{
- close(s);
- ret = 1;
+ s = socket(af, SOCK_DGRAM, 0);
+ if (s 0)
+ ret = (errno == EMFILE) ? 1 : 0;
+ else
+ {
+ close(s);
+ ret = 1;
+ }
Why don't you just ret=1 and adjust ret later on accordingly?
See above.
The diff looks confusing. In plain, the function looks like this:
static int addrconfig (sa_family_t af)
{
int s;
int ret;
int saved_errno = errno;
bool seen_ipv4;
bool seen_ipv6;
__check_pf(seen_ipv4, seen_ipv6);
if (af == AF_INET)
ret = (int)seen_ipv4;
else if (af == AF_INET6)
ret = (int)seen_ipv6;
else
{
s = socket(af, SOCK_DGRAM, 0);
if (s 0)
ret = (errno == EMFILE) ? 1 : 0;
else
{
close(s);
ret = 1;
}
}
__set_errno (saved_errno);
return ret;
}
I could change this to
static int addrconfig (sa_family_t af)
{
int s;
int ret = 1;
int saved_errno = errno;
bool seen_ipv4;
bool seen_ipv6;
__check_pf(seen_ipv4, seen_ipv6);
if (af == AF_INET)
ret = (int)seen_ipv4;
else if (af == AF_INET6)
ret = (int)seen_ipv6;
else
{
s = socket(af, SOCK_DGRAM, 0);
if (s 0) {
if (errno != EMFILE)
ret = 0;
}
else
close(s);
}
__set_errno (saved_errno);
return ret;
}
but the resulting code is a couple of bytes larger, and not as easy to
I would just try to set it to 1 in the else { s=socket() block, but it
doesn't matter much if you rewrite __check_pf to just return the
interresting bits.
In the end this addrconfig thing just tries to
static int addrconfig (sa_family_t af)
{
int tmp, ret, saved_errno = errno;
tmp = __check_pf();
#ifdef __UCLIBC_HAS_IPV4__
if (af == AF_INET)
ret = tmp SAW_IPv4;
else
#endif
#ifdef __UCLIBC_HAS_IPV6__
if (af == AF_INET6)
ret = tmp SAW_IPv6;
else
#endif
{
tmp = socket (af, SOCK_DGRAM, 0);
ret = 1; /* Assume PF_UNIX. */
if (tmp 0) {
if (errno != EMFILE)
ret = 0;
} else
close (tmp);
}
__set_errno (saved_errno);
return ret;
}
so the __check_pf should either be manually inlined into it or you
should try to inline it via keyword. I don't think it makes much sense
to put __check_pf into a separate file, but that's just a cosmetic
nitpick.
follow.
And please do not introduce warnings about using undefined preprocessor
tokens and also keep in mind that we ultimately want a libc that can be
configured as IPv6-only. Thanks.
I assume you are referring to your comments above, or were there more
places that you were thinking of?
Just the places above. Sorry if i was unclear.
___
uClibc mailing list
uClibc@uclibc.org
http
Re: [PATCH] Fix multiple DNS queries when negative results returned
On Fri, Jun 27, 2008 at 03:56:53PM +0200, Ricard Wanderlof wrote:
On Fri, 27 Jun 2008, Bernhard Fischer wrote:
Index: libc/inet/resolv.c
===
--- libc/inet/resolv.c(revision 22530)
+++ libc/inet/resolv.c(working copy)
@@ -757,6 +757,7 @@
#ifdef __UCLIBC_HAS_IPV4__
struct sockaddr_in sa;
#endif
+ bool negative_results[MAX_SEARCH + 1] = { 0 };
unsigned no_results;
if (got negative result)
no_results |= (1 variant)
Which one is smaller? size(1), please.
They are the same.
With my configuration, size lib/libuClibc-0.9.29.so returns:
textdata bss dec hex filename
2748735016 14376 294265 47d79 lib/libuClibc-0.9.29.so
no matter whether I apply the patch as submitted, or use a bitmapped
version. (Removing the off-the-end-of-the-array tests in the array
version yields 20 bytes less; these tests aren't needed in the bitmapped
version of course).
good, Thanks. Let's wait a little bit to hear if somebody objects to the
tweak in general.
cheers,
Bernhard
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: compile error when trying to use uClibc snapshots
On Tue, Jun 17, 2008 at 03:29:52PM +0200, Gaye Abdoulaye Walsimou wrote: Hello list, I'm trying to compile uClibc snapshots and have the following errors. Any suggestions? Thanks Regards ###Error output when trying to compile uClibc snapshots ### make -C /opt/LDE/user/buildroot-20060919-1/toolchain_build_mipsel/uClibc \ Assuming that your clock isn't wrong, you should really consider using something that is not _that_ stale. Anyway. double-check that your kernel-headers are set correctly and that you already install_dev'ed properly before that. Just retried to be sure and it works fine with my git tree, fwiw. HTH, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: daemon deadlock
On Thu, Jun 12, 2008 at 09:59:34AM +0200, Denys Vlasenko wrote: On Thursday 12 June 2008 00:05, [EMAIL PROTECTED] wrote: Hello, I am using a uClibc (version 0.9.29) to build a rootfs for a i586 target. The configuration file is joined to this mail. I am facing CROSS_COMPILER_PREFIX=./i586-linux-uclibcgnueabi- i586 + gnueabi. Last I remember, gnueabi was an ARM thing. ?! Although I am not an expert, maybe it's ok. No, it's not ok. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: missing function: pthread_mutexattr_setprotocol
On Thu, Jun 12, 2008 at 12:33:48PM +0200, Gaye Abdoulaye Walsimou wrote: Hello list, As described here: http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html pthread_mutexattr_setprotocol function is declared in pthread.h. Can somebody confirm me that this function is missing in uclibc? See docs/uClibc_vs_SuSv3.txt Perhaps you want to add them? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: *.dep file not cleaned
On Wed, Jun 11, 2008 at 09:33:17AM +0200, Carmelo AMOROSO wrote: Should be new *.dep files be cleaned when running 'make clean' ? I'd expect yes.. or am I wrong ? I think they should not be cleaned in clean. They are cleaned in realclean and distclean. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] remove duplicate interp from lib-so-y
On Wed, Jun 11, 2008 at 09:50:21AM +0200, Carmelo AMOROSO wrote: This doesn't happen on nptl branch that doesn' t include recent chanegs on build system ! Do you also see this without -C ? No, without -C it works fine as below Great. I didn't think about -C. I'll keep it in mind and will have a look ASAP, please refrain from -C for now then -- although it does no real harm but building certain stuff twice. Thanks for the heads-up! PS: Does somebody know, by chance, why everything except crtbeginT.o: uses $(objext)? This crtbeginT.o: is the only (wrongly, i assume) hardcoded user of .o in libgcc/Makefile.in ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: make realclean does clean twice
On Wed, Jun 11, 2008 at 09:39:39AM +0200, Carmelo AMOROSO wrote:
Hi,
I've seen that *.dep will be removed with 'realclean' target,
but when running it I've seen that make tries to clean files twice
as in the attached log.
I'm aware of this cosmetic issue, yes.
rm -f ./ldso/ldso/*.{o,os,oS,a} ./ldso/ldso/*/*.{o,os,oS}
The *clean targets also want to be adjusted not to use sh glob (which
may not work with all shells) but either explicitely
$(RM) $(patsubst the/dir/,*.o *.os *.oS *.a) or just use $(wildcard).
Please feel free to look into the realclean glitch and the sh pattern
fixup.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] remove duplicate interp from lib-so-y
On Wed, Jun 11, 2008 at 09:50:21AM +0200, Carmelo AMOROSO wrote: Bernhard Fischer wrote: On Wed, Jun 11, 2008 at 09:28:07AM +0200, Carmelo AMOROSO wrote: Hi, I don't have this problem... instead I'm seeing the the ld.so is linked You have to turn on domulti to see it. I'll try it. Note that you need a recent compiler for this to work (trunk from about rev 136500 works for me). I have a couple of patches that i need for building certain libs in this mode, grab them from my buildroot git repo if you encounter trouble: toolchain/gcc/4.4.0/999-4.4-pr36450.patch toolchain/gcc/4.4.0/998-gcc-4.3.0-fix-header.00.patch toolchain/gcc/4.4.0/gcc-4.3-pr31537.01.patch the fix-header is only needed for sh and will be obsoleted once this gets in: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00402.html HTH ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
facility and prioritynames _again_ [was: Re: svn commit: trunk/uClibc/include/sys]
On Thu, Jun 05, 2008 at 07:44:10PM -0700, [EMAIL PROTECTED] wrote:
Author: vda
Date: 2008-06-05 19:44:10 -0700 (Thu, 05 Jun 2008)
New Revision: 22241
Log:
Heed a warning: string was assigned to char*, changing that to const char*
Modified:
trunk/uClibc/include/sys/syslog.h
Changeset:
Modified: trunk/uClibc/include/sys/syslog.h
===
--- trunk/uClibc/include/sys/syslog.h 2008-06-06 02:42:57 UTC (rev 22240)
+++ trunk/uClibc/include/sys/syslog.h 2008-06-06 02:44:10 UTC (rev 22241)
@@ -67,8 +67,8 @@
/* mark facility */
#define INTERNAL_MARK LOG_MAKEPRI(LOG_NFACILITIES, 0)
typedef struct _code {
- char*c_name;
- int c_val;
+ const char *c_name;
+ int c_val;
} CODE;
In file included from
/there.pentium4/build_i686/staging_dir/usr/include/syslog.h:1,
from sysklogd/syslogd.c:19:
/there.pentium4/build_i686/staging_dir/usr/include/sys/syslog.h:77:
error: conflicting types for 'prioritynames'
sysklogd/logger.c:30: error: previous declaration of 'prioritynames' was
here
/there.pentium4/build_i686/staging_dir/usr/include/sys/syslog.h:128:
error: conflicting types for 'facilitynames'
sysklogd/logger.c:31: error: previous declaration of 'facilitynames' was
here
make[1]: *** [busybox_unstripped.o] Error 1
Please fix busybox/sysklogd/logger.c accordingly and make sure that this
works when compiling against the 0.9.29 release (which doesn't have the
change above).
thanks,
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Test build failed due to UCLIBC_INTERNAL header rework
On Wed, Jun 11, 2008 at 04:10:23PM +0200, Bernd Schmidt wrote: Daniel Jacobowitz wrote: I have no comment on the patch itself, but I like the approach - I've concluded before that this is the only sane way to test toolchain pieces, especially compiler or C library. We do all of our testing after installation here. My patch doesn't really create a full installation tree that looks identical to the one created by 'make install'; that might require somewhat more effort (unless we want to just $(MAKE) install DESTDIR=somewhere/in/tree for every make test). A better approach would be to just test-includes: test/include/bits/uClibc_config.h $(make) -C $(top_builddir) PREFIX=test/ RUNTIME_PREFIX=test/ \ DEVEL_PREFIX=/ \ HOSTCC=$(HOSTCC) \ eventual_flags_passing_here \ install_dev i.e. do a real, full install an no fakery. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] remove duplicate interp from lib-so-y
On Wed, Jun 11, 2008 at 10:02:33AM +0200, Bernhard Fischer wrote: On Wed, Jun 11, 2008 at 09:50:21AM +0200, Carmelo AMOROSO wrote: This doesn't happen on nptl branch that doesn' t include recent chanegs on build system ! Do you also see this without -C ? No, without -C it works fine as below Great. I didn't think about -C. I'll keep it in mind and will have a look ASAP, please refrain from -C for now then -- although it does no real harm but building certain stuff twice. Thanks for the heads-up! Please retry with r22293. PS: Does somebody know, by chance, why everything except crtbeginT.o: uses $(objext)? This crtbeginT.o: is the only (wrongly, i assume) hardcoded user of .o in libgcc/Makefile.in cruft, as is vis_hide in static-objects.mk. Fixed locally. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] remove duplicate interp from lib-so-y
On Wed, Jun 11, 2008 at 04:56:49PM +0200, Carmelo AMOROSO wrote: Bernhard Fischer wrote: On Wed, Jun 11, 2008 at 10:02:33AM +0200, Bernhard Fischer wrote: On Wed, Jun 11, 2008 at 09:50:21AM +0200, Carmelo AMOROSO wrote: This doesn't happen on nptl branch that doesn' t include recent chanegs on build system ! Do you also see this without -C ? No, without -C it works fine as below Great. I didn't think about -C. I'll keep it in mind and will have a look ASAP, please refrain from -C for now then -- although it does no real harm but building certain stuff twice. Thanks for the heads-up! Please retry with r22293. Yeah.. now that's fine ;-) No, it isn't, it seems. Try: $ make CC=gcc-mine $ make CC=gcc-mine -C ldso $ make CC=gcc-mine -C ldso $ make CC=gcc-mine Everything but the first invocation should say nothing to be done for all or something like that. Doesn't do that for me (see other mail i sent a few minutes ago). ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] fix 'make headers' when LOCALE is enabled
On Wed, Jun 11, 2008 at 07:51:09PM +0200, Carmelo AMOROSO wrote: Bernhard Fischer wrote: On Wed, Jun 11, 2008 at 07:01:27PM +0200, Carmelo AMOROSO wrote: Hi, when running 'make headers with LOCALE enabled there is a problem caused by a dependencies of extra/locale/gen_locale against sysnum.h that is generated by the pregen target So this patch solve it by moving the make -C locale_headers into the pregen target pregen is ment to generate the needed headers and only that. Can you instead try to remove the headers dep from pregen and make headers depend on pregen, i.e. exactly the other way around? Hi, if I make headers depending on pregen, that depends on sysnum.h, then 'make headers' will require the cross-compiler available. Doing so it will not be possible to run make install_headers that are required to build the cross-gcc by scratch. You need a cross-compiler to generate sysnum.h anyway. This is nothing new, really. ok, install_dev (to build a stage1 cross-compiler) just needs headers (and no locale stuff, at least in my setup). If you have a working cross-compiler you can pregen, so your patch is ok. Please install and accept my apologies for breaking it in the first place :) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] remove duplicate interp from lib-so-y
[I've already sent this some time ago and got no response] Hi, LD libuClibc-0.9.29.so ./lib/interp.os:(.interp+0x0): multiple definition of `__dl_ldso__' lib/interp.os:(.interp+0x0): first defined here - interp comes in via LIBs, remove erroneous duplicate prerequisite. I will apply this patch in a week from now unless somebody objects. thanks, Index: Makerules === --- Makerules (revision 22286) +++ Makerules (working copy) @@ -9,7 +9,7 @@ PHONY := FORCE ifeq ($(HAVE_SHARED),y) .LIBPATTERNS: lib%.so libs: $(lib-so-y) $(lib-a-y) -$(lib-so-y): $(interp) +$(lib-so-y): else .LIBPATTERNS: lib%.a ifeq ($(UCLIBC_FORMAT_SHARED_FLAT),y) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: __uc_malloc
On Mon, Jun 09, 2008 at 12:55:13PM +0200, Bernd Schmidt wrote: Denys Vlasenko wrote: This actually _improves_ our performance in near-OOM conditions. How? Going back to crypt(). If we will go back and reinstate static buffers there, busybox's data+bss size will jump from 8k to 80k - tenfold increase. On NOMMU, if you have N running busybox daemons, you already have additional N*72k bytes allocated and sitting there, totally unused. Well, wasting memory at run-time is inherent in the design of busybox. Have you considered that it might be busybox that is broken? That's exactly the reason why we have the option to build individual applets at the cost of some added complexity due to dynamic libraries and a bit of disk-space. I think it would be better to try to use (or add to libc, if really needed) _r functions in busybox to minimize the bss impact. I'm aware that there is no really cheap way out of this misery, but if bss of libbusybox is still too big, then we could split it into separate sub-libs for a given problem-domain. Just an idea.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: reentrant functions
On Sun, Jun 08, 2008 at 05:35:22PM +0200, Denys Vlasenko wrote: On Sunday 08 June 2008 16:21, Bernd Schmidt wrote: Denys Vlasenko wrote: Ok, this is a scenario: the user runs a passwd utility on NOMMU box. This utility has 20k of text and 80k of data. 70k of this data is occupied by des.c static buffer. At this moment the machine has only 90k RAM available, has no swap etc. It cannot satisfy load request for this application. So user gets some error message from the shell to this effect. If des.c buffer is not static but is __uc_malloc'ed, program will load succesfully, and then __uc_malloc will fail and exit with no memory! message. In both cases user's experience is essentially the same - [s]he cannot run the program because there is not enough memory. Except the program that called crypt may have left some state - temporary files, partial modifications in other files, whatever - because it did not expect to fail at this point. If this program wants to not be killed by OOM, it needs to install the handler for this situation. It is not difficult at all. The problem is that this is not the expected behaviour and is absolutely not standard confirming (in contrast, it breaks established standards and expectations silently). We can't do that. Essentially your argument comes down to it doesn't really matter what the documented interface is. No, my argument is twofold: 1. Minority of people who are careful enough to handle OOM coditions correctly will not be deterred by the need to have a tiny speck of uclibc-specific glue: Nobody cares (or should care) about impl details of a lib since the lib is supposed to serve *exactly* the thing/standard it implements. 2. Most of the programs do not handle OOM situation correctly anyway: - take any sufficiently big program and you will easily find a malloc call or new operator in C++ which is not checked for NULL. That is no excuse. - some people are more honest about it and they implement and document this behavior, rather than just being lazy and allowing their programs to segfault when malloc fails. For example, gtk/Gnome libraries do this. They have allocators which just exit on allocation error. Well, busybox uses xmalloc extensively. etc... Which prompted me to think about more realistic approach to this problem. Yes, from the POV of malloc (libc) author, lets return NULL on failure and let user deal with it. But for the user, it's not good enough. In many cases, user calls malloc deep inside the callchain, and it just HAS NO SANE WAY TO REACT TO OOM at that place! That's not the point. Call it something_which_acts_a_bit_like_foo() but if you disobey the expectations anybody puts on foo() it's just not foo() anymore. I think that there are not alot of users who want to use a something_which_acts_a_bit_like_##whatever() api, even if it could be ok for certain, very specific use-cases. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
reentrant functions
On Tue, Jun 03, 2008 at 11:30:04PM +0200, Bernd Schmidt wrote: Bernhard Fischer wrote: - adds several config-options to allow for turning off certain features This seems a good way to reduce size. One additional idea I had recently was to add a config option to turn off non-reentrant functions where a reentrant version exists (e.g. gethostbyname vs gethostbyname_r). That's because I still believe the uc_malloc trick comes at a reliability cost, so I'd rather revert that and provide a way for people to configure out the functions using static data. However, I don't know whether this is feasible, or if these functions are still very much in use. What do you guys think? Just to make sure i understand correctly: - If a reentrant function exists then you want the non-reentrant func to be optional (via a central knob). - If non-reentrant funcs are off then they are aliased to their reentrant counterpart. What about the reverse, i.e. dropping *_r()? Think about no threads, i don't really need *_r() at all there, i suppose. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/unistd
On Sat, Jun 07, 2008 at 07:39:54AM +0200, Denys Vlasenko wrote: On Friday 06 June 2008 14:50, Bernhard Fischer wrote: On Thu, Jun 05, 2008 at 08:24:45PM -0700, [EMAIL PROTECTED] wrote: Author: vda Date: 2008-06-05 20:24:45 -0700 (Thu, 05 Jun 2008) New Revision: 22242 Log: shrink getopt a bit by using smallints. Run tested (busybox testsuite) I still think that this route is wrong. I somewhat agree in a sense that smallints should not be *abused*. They should be used only in the following cases: * variables are not on stack but in data or bss, or in rare cases in a structure which is allocated many times (not typical for libc code, but happens a lot in bbox) * variables are bool flags or enum-like values; not much of arithmetic is done on them (+,-,bitshifts): on many arches arith ops on narrow ints are bigger and/or slower. (as opposed to loads/stores and bit tests. If on some arch even loads/stores and bit tests are bigger, it should use smallints which are just ordinary ints. I can commit a change which adds a comment with this text to codebase. Do you want me to do it? Not needed for me, so no but thanks. VRP knows the exact range of values a variable is in. -fnarrow-type should deal with this for us, really. As soon as someone will do flag++ as a bastardized flag = 1 or global_flag = bool_parameter_of_a_function, this will break. fnarrow-types Common Report Var(narrow_types,0) Optimization Narrow variables to use the smallest possible type Nice. if somebody would implement it, yes. This would (, for non-public variables) Many variables will be public for compiler since they will be touched from several .o files within uclibc. If they are hidden then they are not public, i think. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
possible problem with buffered stdio and linuxthreads.old
Hi, libc/stdio/fclose.c: In function 'fclose': libc/stdio/fclose.c:69: warning: declaration of '__infunc_pthread_cleanup_buffer' shadows a previous local libc/stdio/fclose.c:45: warning: shadowed declaration is here libc/stdio/freopen.c: In function 'freopen': libc/stdio/freopen.c:40: warning: declaration of '__infunc_pthread_cleanup_buffer' shadows a previous local libc/stdio/freopen.c:36: warning: shadowed declaration is here libc/stdio/freopen.c:58: warning: declaration of '__infunc_pthread_cleanup_buffer' shadows a previous local libc/stdio/freopen.c:36: warning: shadowed declaration is here This seems to come from the last stdio update from mjn3 applied by andersee in r16793 I'm attaching the config which triggered this for me. Can anyone confirm this? Any takers? # # Automatically generated make config: don't edit # Sat Jun 7 16:50:38 2008 # # TARGET_alpha is not set # TARGET_arm is not set # TARGET_avr32 is not set # TARGET_bfin is not set # TARGET_cris is not set # TARGET_e1 is not set # TARGET_frv is not set # TARGET_h8300 is not set # TARGET_hppa is not set TARGET_i386=y # TARGET_i960 is not set # TARGET_ia64 is not set # TARGET_m68k is not set # TARGET_microblaze is not set # TARGET_mips is not set # TARGET_nios is not set # TARGET_nios2 is not set # TARGET_powerpc is not set # TARGET_sh is not set # TARGET_sh64 is not set # TARGET_sparc is not set # TARGET_v850 is not set # TARGET_vax is not set # TARGET_x86_64 is not set # TARGET_xtensa is not set # # Target Architecture Features and Options # TARGET_ARCH=i386 FORCE_OPTIONS_FOR_ARCH=y CONFIG_GENERIC_386=y # CONFIG_386 is not set # CONFIG_486 is not set # CONFIG_586 is not set # CONFIG_586MMX is not set # CONFIG_686 is not set # CONFIG_PENTIUMII is not set # CONFIG_PENTIUMIII is not set # CONFIG_PENTIUM4 is not set # CONFIG_K6 is not set # CONFIG_K7 is not set # CONFIG_ELAN is not set # CONFIG_CRUSOE is not set # CONFIG_WINCHIPC6 is not set # CONFIG_WINCHIP2 is not set # CONFIG_CYRIXIII is not set # CONFIG_NEHEMIAH is not set TARGET_SUBARCH= # # Using ELF file format # ARCH_LITTLE_ENDIAN=y # # Using Little Endian # ARCH_HAS_MMU=y ARCH_USE_MMU=y UCLIBC_HAS_FLOATS=y UCLIBC_HAS_FPU=y DO_C99_MATH=y UCLIBC_HAS_FENV=y KERNEL_HEADERS=/there.pentium4/toolchain_build_i686/linux/include HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set DOPIC=y # ARCH_HAS_NO_SHARED is not set # ARCH_HAS_NO_LDSO is not set HAVE_SHARED=y FORCE_SHAREABLE_TEXT_SEGMENTS=y LDSO_LDD_SUPPORT=y LDSO_CACHE_SUPPORT=y # LDSO_PRELOAD_FILE_SUPPORT is not set LDSO_BASE_FILENAME=ld.so # UCLIBC_STATIC_LDCONFIG is not set # LDSO_RUNPATH is not set UCLIBC_CTOR_DTOR=y # LDSO_GNU_HASH_SUPPORT is not set # HAS_NO_THREADS is not set UCLIBC_HAS_THREADS=y # PTHREADS_DEBUG_SUPPORT is not set LINUXTHREADS_OLD=y UCLIBC_HAS_SYSLOG=y UCLIBC_HAS_LFS=y # MALLOC is not set # MALLOC_SIMPLE is not set MALLOC_STANDARD=y MALLOC_GLIBC_COMPAT=y UCLIBC_DYNAMIC_ATEXIT=y # COMPAT_ATEXIT is not set # UCLIBC_SUSV3_LEGACY is not set # UCLIBC_SUSV3_LEGACY_MACROS is not set UCLIBC_HAS_SHADOW=y # UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set UCLIBC_HAS_PTY=y ASSUME_DEVPTS=y # UNIX98PTY_ONLY is not set UCLIBC_HAS_GETPT=y UCLIBC_HAS_TM_EXTENSIONS=y UCLIBC_HAS_TZ_CACHING=y UCLIBC_HAS_TZ_FILE=y # UCLIBC_HAS_TZ_FILE_READ_MANY is not set UCLIBC_TZ_FILE_PATH=/etc/TZ # # Advanced Library Settings # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 # # Support various families of functions # UCLIBC_LINUX_MODULE_24=y UCLIBC_LINUX_SPECIFIC=y UCLIBC_HAS_GNU_ERROR=y UCLIBC_BSD_SPECIFIC=y UCLIBC_HAS_BSD_ERR=y # UCLIBC_HAS_OBSOLETE_BSD_SIGNAL is not set # UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL is not set # UCLIBC_NTP_LEGACY is not set # UCLIBC_SV4_DEPRECATED is not set UCLIBC_HAS_REALTIME=y UCLIBC_HAS_ADVANCED_REALTIME=y UCLIBC_HAS_EPOLL=y UCLIBC_HAS_XATTR=y UCLIBC_HAS_PROFILING=y UCLIBC_HAS_CRYPT_IMPL=y UCLIBC_HAS_CRYPT=y UCLIBC_HAS_NETWORK_SUPPORT=y UCLIBC_HAS_SOCKET=y UCLIBC_HAS_IPV4=y # UCLIBC_HAS_IPV6 is not set # UCLIBC_HAS_RPC is not set # UCLIBC_USE_NETLINK is not set # UCLIBC_HAS_BSD_RES_CLOSE is not set # # String and Stdio Support # UCLIBC_HAS_STRING_GENERIC_OPT=y UCLIBC_HAS_STRING_ARCH_OPT=y UCLIBC_HAS_CTYPE_TABLES=y UCLIBC_HAS_CTYPE_SIGNED=y # UCLIBC_HAS_CTYPE_UNSAFE is not set UCLIBC_HAS_CTYPE_CHECKED=y # UCLIBC_HAS_CTYPE_ENFORCED is not set UCLIBC_HAS_WCHAR=y # UCLIBC_HAS_LOCALE is not set UCLIBC_HAS_HEXADECIMAL_FLOATS=y UCLIBC_HAS_GLIBC_CUSTOM_PRINTF=y UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 UCLIBC_HAS_SCANF_GLIBC_A_FLAG=y # UCLIBC_HAS_STDIO_BUFSIZ_NONE is not set # UCLIBC_HAS_STDIO_BUFSIZ_256 is not set # UCLIBC_HAS_STDIO_BUFSIZ_512 is not set # UCLIBC_HAS_STDIO_BUFSIZ_1024 is not set # UCLIBC_HAS_STDIO_BUFSIZ_2048 is not set UCLIBC_HAS_STDIO_BUFSIZ_4096=y # UCLIBC_HAS_STDIO_BUFSIZ_8192 is not set UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_4 is not set # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_8 is not set # UCLIBC_HAS_STDIO_SHUTDOWN_ON_ABORT is not set #
Re: svn commit: trunk/uClibc/libc/inet
On Fri, Jun 06, 2008 at 12:49:33PM +0200, Carmelo AMOROSO wrote: Bernd Schmidt wrote: [EMAIL PROTECTED] wrote: Author: vda Date: 2008-06-06 00:25:12 -0700 (Fri, 06 Jun 2008) New Revision: 22244 Log: Use more natural way to return a value in __read_etc_hosts_r: hah. vda bashing! ;) No, serious: In file included from libc/inet/read_etc_hosts_r.c:8: libc/inet/resolv.c:1549: warning: 'visibility' attribute ignored on non-class types I think i did not see this before you recently touching that resolv mess. PS: You know that i usually do not blindly rewrite stuff, but the resolver code is really an ugly and bloated mess (and doesn't even work for IPv6-only), but this time i think it would be saner to write this thing from scratch and not try to beat it into shape. See ifenslave for an example if somebody beats something into shape. While the task itself is not really rocket-science and should fit in let's say 1.4kB _at_most_, the current crap uses 2.6kB, is ugly as hell and all around bad. Let's not do such stuff, please. There is no point in it and in the end, no benefit either to have something like that. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Tue, Jun 03, 2008 at 04:54:20PM +0200, Bernd Schmidt wrote:
Bernhard Fischer wrote:
I would prefer the attached, completely untested hunks.
Please apply if it works for you.
I'd drop the STRIP_FILES, as only STRIP_T_FILES really makes sense here.
Also, I noticed that libpthread isn't the only place that does this, so
we'll have to expand this a little :-/
Meanwhile i've adjusted those to strip the archives and not their
prerequisites.
I attach my corrent improvement WRT header dependencies, installation
and printing prettyness (prettiness? who knows):
1) There was a wrong dependency include/bits for the config targets
which tricked make into
-extra/config/conf extra/config/mconf: include/bits
-# TODO: this results in make[1]: `conf' is up to date printed
-# on every rebuild, because extra/config/conf is already built
-# on previous make run. Make it test -x $@ || ... (simple a bit wrong)
-# or make -q -C extra/config $(notdir $@) || ... (less readable)?
I've renamed it to $(suspicious_dependency) and set it to empty. We will
remove this later.
2) reasons to re-generate include/bits/uClibc_config.h
the script which generates it has to be a prereq, too.
Added a nice disp_gen while at it.
3) libc/sysdeps
mess.
libc/sysdeps/linux/{$(TARGET_ARCH,common}/ #excuse that sh+make slang
are linked to include/. _linked_. This means that make(1) will ignore
any symlink's timestamp unless
-L, --check-symlink-times
is specified. Since the sysdep headers are usually older than the
.config, we cannot make include/* depend on uClibc_config.h but do some
kind of indirection.
I solved this the easy (and friendly to eventually broken make(1)s) way
by saying that iff we have to regenerate uClibc_config.h then in this
very rule, we make headers-y.
This is IMHO the cleanest and simplest solution without relying on -L.
Several helper variables were added to Makefile.in that contain
ALL_HEADERS_*. These are in a helper variable target-headers-sysdep and
are added to headers-y (but that's obvious from the patch).
4) header symlinks
Somehow related to 3) above, add pretty-printing for LN
Provide explicit rules to symlink common, arch, subarch specific headers
into include/
This is the block in Makefile.in perusing do_ln
5) headers_clean
The links from 3) and 4) above are put on a prune-list scheduled for
removal. There is a small problem with threads in this respect, goto
EOM for details.
6) pregen and install_dev
pregen generates the stringently important sysnum.h
Versions up to and including 0.9.29-release needed
# older uClibc without the signum.h generation fix
set -x $(MAKE1) -C $(UCLIBC_DIR) \
PREFIX=$(TOOL_BUILD_DIR)/uClibc_dev/ \
DEVEL_PREFIX=/usr/ \
RUNTIME_PREFIX=$(TOOL_BUILD_DIR)/uClibc_dev/ \
HOSTCC=$(HOSTCC) \
BUILD_CFLAGS=$(HOST_CFLAGS) \
BUILD_LDFLAGS=$(HOST_LDFLAGS) \
UCLIBC_EXTRA_LDFLAGS=$(TARGET_LDFLAGS) \
UCLIBC_EXTRA_CFLAGS=$(TARGET_CFLAGS) \
pregen install_dev
Since a couple of hundred revisions that pregen is not needed anymore, a
simple install_dev will do.
This patch verified that the pure install_dev works fine so one can
build a proper stageN compiler with these headers.
7) other cosmetics
Preparation of do_unifdef, do_mkdir, do_ln
do_ln, disp_ln, cmd_ln could need a cosmetic cleanup to work with it's
arguments. The current patch leaves this as an exercise for the curious
reader (or helpful janitor) and works well otherwise.
I intend to apply this patch in the next few days since it seems
to be correct (afaics) but i'd be happy if somebody who uses powerpc or
bfin regularly could test it. There are two corner-cases that i couldn't
test and i wouldn't be surprised if they wouldn't work out of the box,
although they are supposed to.
-
The linuxthreads hickup (no pun intended WRT mythological NPTL ;)
Turning off threads doesn't wipe threads-headers from include/
This is a real problem but doesn't affect me since i'm not doing
threads. Nice, eh?
libpthread/Makefile should hardcode clean targets for all available
thread impls.
thanks for taking the time to read that far cheers,
Index: uClibc/Makefile.in
===
--- uClibc/Makefile.in (revision 22237)
+++ uClibc/Makefile.in (working copy)
@@ -15,6 +15,8 @@ noconfig_targets := menuconfig config ol
include $(top_builddir)Rules.mak
sub_headers := headers
+#suspicious_dependency:=include/bits
+
ifeq ($(HAVE_DOT_CONFIG),y)
all: pregen libs
@@ -36,11 +38,17 @@ include $(top_srcdir)extra/locale/Makefi
# last included to catch all the objects added by others (locales/threads)
include $(top_srcdir)libc/Makefile.in
-include/bits/uClibc_config.h: extra/config/conf .config
- $(Q)$(INSTALL) -d $(dir $@)
- $(Q)@$ -o $(top_srcdir)extra/Configs/Config.in
- $(top_srcdir)extra/scripts/conf-header.sh .config
Re: elf2flt questions
On Thu, Jun 05, 2008 at 01:00:39PM +0200, Denys Vlasenko wrote: On Thursday 05 June 2008 10:49, Mike Frysinger wrote: everyone-should-be-using-today: mktemp from coreutils great. They switched to git and didn't turn off CVS, and i bet CVS is not updated anymore since at least 20071210. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc
On Thu, Jun 05, 2008 at 02:37:13PM +0200, Bernd Schmidt wrote: [EMAIL PROTECTED] wrote: +libpthread/*/*.$(ext) libpthread/*/*/*.$(ext) \ +libpthread/*/*/*/*.$(ext) libpthread/*/*/*/*/*.$(ext) \ +libpthread/*/*/*/*/*/*.$(ext) libpthread/*/*/*/*/*/*/*.$(ext) \ +libpthread/*/*/*/*/*/*/*/*.$(ext)) Uh... is there another way of doing this? ok, that was a bit gross. Also, this really is supposed to be done by the make objclean-y step just below. we can unconditionally add all 4 variants as objclean-y in libpthread/Makefile.in ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[OT] Re: Compiling binutils 2.18.
On Tue, Jun 03, 2008 at 10:51:51PM +0200, Manuel Cano wrote: Hello. I've searched for this error but I haven't found an answer. This question is not really on topic here and this is an old issue that has been answered many, many times. http://repo.or.cz/w/buildroot.git?a=tree;f=toolchain/binutils/2.18;hb=HEAD ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote: Bernhard Fischer wrote: I hope i improved the situation a bit now (if you use r22158 and later). We honour both all our prerequisites (if your compiler groks what we mean to ask for in our gcc-ism) as well as the used CC and flags. I consider this fixed, issue closed, nothing to see here, please move on (or holler if i broke something) :) I've done a bit of digging, and found the cause of two problems. 1. So far, only libc-so-y and libc-a-y are tracked. This needs to be extended to handle all the other libraries, including ld.so. 2. The CFLAGS passed to the compiler have changed in some cases. Previously, when compiling ldso/libdl/libdl.c, $^ used to be ldso/libdl/libdl.c; it is now ldso/libdl/libdl.c FORCE, which means that $(CFLAGS-$(notdir $(^D)) no longer does the right thing: $(notdir $(^D)) is now libdl .. There's also $(CFLAGS-$(notdir $)) in the command line, which doesn't work for this case, since it expands to ldso/libdl/; note the prefix ldso/ and the trailing slash. We could fix this by using $(D) instead of $(^D) in the above. Also, maybe it makes sense to clean up the CFLAGS to always mention the full path without trailing slash. I see that you already took care of this, many thanks. We still have a problem, though. Consider HAVE_SHARED set (i.e. ldso is built) and also some thread variant selected. Build. Turn off thread-support. make clean make; bummer. Suddently there is no rule to make include/bits/pthreadtypes.h (anymore). We recorded this header as a prereq in the first build, but of course turning off thread-support breaks this horribly. A make realclean obviously would bypass this, but either we need dummy-rules for conditional headers like this or do something else to drop those now unavailable prerequisites. I'll think about this some more, but perhaps somebody has an opinion or an idea.. :) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: extra/Configs include include/netinet i etc...
On Tue, Jun 03, 2008 at 01:11:57AM -0700, [EMAIL PROTECTED] wrote:
Author: aldot
Date: 2008-06-03 01:11:56 -0700 (Tue, 03 Jun 2008)
New Revision: 22198
I'm thinking about rewriting the resolver-code (leaving the current one
as an .old alternative) because:
1) It's bloated.
2) It isn't designed to work for IPv6-only.
Iff i find the time to tackle this then i expect a first draft to be
thread-agnostic, of course.
As to the rest below, please CC me if you experience unexpected
problems.
thanks,
Bernhard
Log:
- adds several config-options to allow for turning off certain features
like
o UCLIBC_HAS_GNU_ERROR
o UCLIBC_HAS_BSD_ERR
o UCLIBC_HAS_PTY
o UCLIBC_HAS_GETPT (1)
o UCLIBC_SYSCALL_STUBS
o UCLIBC_SYSCALL_STUB_WARNING
o UCLIBC_LINUX_SPECIFIC (2)
o UCLIBC_BSD_SPECIFIC (3)
o UCLIBC_NTP_LEGACY (4)
o UCLIBC_SV4_DEPRECATED (5)
o UCLIBC_HAVE_REALTIME (6)
o UCLIBC_HAVE_ADVANCED_REALTIME (7)
o UCLIBC_HAVE_EPOLL (8)
o UCLIBC_HAVE_XATTR (9)
o UCLIBC_HAVE_PROFILING (10)
(1) make non-standard getpt optional and implement standard posix_openpt
(2) fstatfs(), inotify_*(), ioperm(), iopl(), madvise(), modify_ldt(),
personality()
ppoll(), setresuid()
(3) mincore(), getdomainname(), setdomainname()
(4) ntp_adjtime(), ntp_gettime() aliases
(5) ustat() [use statfs(2) in your code instead]
(6) All marked as (REALTIME) in SUSv3
(7) All marked as (ADVANCED REALTIME) in SUSv3
(8) epoll_create(), epoll_ctl(), epoll_wait()
(9) all Extended Attributes
(10) helpers for gcc's -finstrument-functions
- Fixes _dl_exit()
- Implements sleep(3) for !UCLIBC_HAVE_REALTIME
- Implements usleep(3) for !UCLIBC_HAVE_REALTIME
- adds #warning about incorrect posix_fadvise{,64}()
- removes unused and unwanted uselib()
Net outcome is that an allnoconfig with HAVE_SHARED is now about 88k instead
of formerly 130k.
Modified:
trunk/uClibc/Makefile.in
trunk/uClibc/TODO
trunk/uClibc/extra/Configs/Config.in
trunk/uClibc/include/fcntl.h
trunk/uClibc/include/mqueue.h
trunk/uClibc/include/netinet/in.h
trunk/uClibc/include/signal.h
trunk/uClibc/include/stdlib.h
trunk/uClibc/include/sys/mman.h
trunk/uClibc/include/sys/poll.h
trunk/uClibc/include/sys/statfs.h
trunk/uClibc/include/sys/timex.h
trunk/uClibc/include/time.h
trunk/uClibc/include/unistd.h
trunk/uClibc/ldso/include/dl-syscall.h
trunk/uClibc/libc/inet/Makefile.in
trunk/uClibc/libc/inet/getaddrinfo.c
trunk/uClibc/libc/inet/hostid.c
trunk/uClibc/libc/inet/if_index.c
trunk/uClibc/libc/inet/resolv.c
trunk/uClibc/libc/inet/socketcalls.c
trunk/uClibc/libc/misc/dirent/Makefile.in
trunk/uClibc/libc/misc/error/Makefile.in
trunk/uClibc/libc/misc/error/err.c
trunk/uClibc/libc/misc/statfs/fstatvfs.c
trunk/uClibc/libc/misc/statfs/statvfs.c
trunk/uClibc/libc/misc/syslog/Makefile.in
trunk/uClibc/libc/misc/sysvipc/sem.c
trunk/uClibc/libc/misc/time/Makefile.in
trunk/uClibc/libc/signal/Makefile.in
trunk/uClibc/libc/signal/sigwait.c
trunk/uClibc/libc/stdlib/Makefile.in
trunk/uClibc/libc/stdlib/_atexit.c
trunk/uClibc/libc/stdlib/bsd_getpt.c
trunk/uClibc/libc/stdlib/getpt.c
trunk/uClibc/libc/sysdeps/linux/common/Makefile.in
trunk/uClibc/libc/sysdeps/linux/common/adjtimex.c
trunk/uClibc/libc/sysdeps/linux/common/fstatfs.c
trunk/uClibc/libc/sysdeps/linux/common/getdomainname.c
trunk/uClibc/libc/sysdeps/linux/common/getdtablesize.c
trunk/uClibc/libc/sysdeps/linux/common/getpgid.c
trunk/uClibc/libc/sysdeps/linux/common/getpgrp.c
trunk/uClibc/libc/sysdeps/linux/common/getrlimit.c
trunk/uClibc/libc/sysdeps/linux/common/mincore.c
trunk/uClibc/libc/sysdeps/linux/common/mprotect.c
trunk/uClibc/libc/sysdeps/linux/common/msync.c
trunk/uClibc/libc/sysdeps/linux/common/munlockall.c
trunk/uClibc/libc/sysdeps/linux/common/nanosleep.c
trunk/uClibc/libc/sysdeps/linux/common/poll.c
trunk/uClibc/libc/sysdeps/linux/common/posix_fadvise.c
trunk/uClibc/libc/sysdeps/linux/common/posix_fadvise64.c
trunk/uClibc/libc/sysdeps/linux/common/ppoll.c
trunk/uClibc/libc/sysdeps/linux/common/ptrace.c
trunk/uClibc/libc/sysdeps/linux/common/quotactl.c
trunk/uClibc/libc/sysdeps/linux/common/sbrk.c
trunk/uClibc/libc/sysdeps/linux/common/select.c
trunk/uClibc/libc/sysdeps/linux/common/seteuid.c
trunk/uClibc/libc/sysdeps/linux/common/setpgid.c
trunk/uClibc/libc/sysdeps/linux/common/setresuid.c
trunk/uClibc/libc/sysdeps/linux/common/sigaltstack.c
trunk/uClibc/libc/sysdeps/linux/common/sigpending.c
trunk/uClibc/libc/sysdeps/linux/common/sigprocmask.c
trunk/uClibc/libc/sysdeps/linux/common/sigqueue.c
trunk/uClibc/libc/sysdeps/linux/common/sigsuspend.c
trunk/uClibc/libc/sysdeps/linux/common/statfs.c
trunk/uClibc/libc/sysdeps/linux/common/symlink.c
trunk/uClibc/libc/sysdeps/linux/common/sync.c
trunk/uClibc/libc/sysdeps/linux/common/sysctl.c
trunk/uClibc/libc/sysdeps/linux/common/sysfs.c
Re: [RFC] build system replacement
On Tue, Jun 03, 2008 at 10:39:15AM +0200, Peter Kjellerstedt wrote: We still have a problem, though. Consider HAVE_SHARED set (i.e. ldso is built) and also some thread variant selected. Build. Turn off thread-support. make clean make; bummer. Suddently there is no rule to make include/bits/pthreadtypes.h (anymore). We recorded this header as a prereq in the first build, but of course turning off thread-support breaks this horribly. A make realclean obviously would bypass this, but either we need dummy-rules for conditional headers like this or do something else to drop those now unavailable prerequisites. Something along what gcc's -MP option does? Yes. I initially had -MP but dropped it for reasons i don't remember offhand.. So let's just go back to using -MP. Thanks! ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] doubt in _dl_exit
On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote:
Bernhard Fischer wrote:
Could somebody who uses ldso please have a look if this breaks his
setup?
$ size ldso/ldso/ldso.oS*
text data bss dec hex filename
12424 12 72 1250830dc ldso/ldso/ldso.oS.old
12290 12 72 123743056 ldso/ldso/ldso.oS
@@ -59,7 +59,11 @@
dynamic linking at all, so we cannot return any error codes.
We just punt if there is an error. */
#define __NR__dl_exit __NR_exit
-static __always_inline _syscall1(void, _dl_exit, int, status);
+static __always_inline attribute_noreturn void _dl_exit(int status)
+{
+while (1)
+INLINE_SYSCALL(exit, 1, status);
+}
Hi Bernd,
I've just now the chance to update my repo and figured out that this
brakes sh4 build.
My you explain the rationale for this change ?
http://busybox.net/lists/uclibc/2008-May/019394.html
I'm not opposed to reverting that hunk but that explicit variant was
better, imho.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: There appears to be one additional problem. Sometimes I get the following cycle: [EMAIL PROTECTED] /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a AR cr lib/libpthread.a yea, that doesn't make sense to me. First create the archive, then strip it. [EMAIL PROTECTED] /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment libpthread/linuxthreads.old/libpthread_so.a AR cr libpthread/linuxthreads.old/libpthread_so.a LD libpthread-0.9.29.so [EMAIL PROTECTED] /local/src/uclibc/bernds/uClibc $ make make[1]: `conf' is up to date. STRIP -X --strip-debug -R .note -R .comment lib/libpthread.a AR cr lib/libpthread.a The patch below fixes it. Again, it's probably crude, since I'm not that familiar with all of make's tricks. I noticed you added some rules for .u which contain a strip step in the toplevel Makerules, but I'm not sure how to use these. Comments? I don't really like t_strip_d, let's honour STRIP_FLAGS-$@ instead. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] doubt in _dl_exit
On Tue, Jun 03, 2008 at 02:27:08PM +0200, Carmelo AMOROSO wrote:
Bernhard Fischer wrote:
On Tue, Jun 03, 2008 at 01:49:53PM +0200, Carmelo AMOROSO wrote:
Bernhard Fischer wrote:
Could somebody who uses ldso please have a look if this breaks his
setup?
$ size ldso/ldso/ldso.oS*
text data bss dec hex filename
12424 12 72 1250830dc ldso/ldso/ldso.oS.old
12290 12 72 123743056 ldso/ldso/ldso.oS
@@ -59,7 +59,11 @@
dynamic linking at all, so we cannot return any error codes.
We just punt if there is an error. */
#define __NR__dl_exit __NR_exit
-static __always_inline _syscall1(void, _dl_exit, int, status);
+static __always_inline attribute_noreturn void _dl_exit(int status)
+{
+ while (1)
+ INLINE_SYSCALL(exit, 1, status);
+}
Hi Bernd,
I've just now the chance to update my repo and figured out that this
brakes sh4 build.
My you explain the rationale for this change ?
http://busybox.net/lists/uclibc/2008-May/019394.html
I'm not opposed to reverting that hunk but that explicit variant was
better, imho.
Hi,
the problem is that it needs to update sh4/bits/syscall.h because it
doesn't define INLINE_SYSCALL macro.
I'll see to update this... so let's keep this.
ah, i should have looked if the other arches also do it by
INLINE_SYSCALL and not assume they do. I don't want to touch the other
arches right now, so i'll revert this hunk in the evening (in a couple
of hours).
At this point I support all other _syscall macro will be removed as well
to use the explicit variant ?
I didn't intend to look at ldso, no.
A janitorial thing somebody could do is make sure all arches are synced
so we can remove that errnoeous trailing ';' from
_syscall[[:digit:]][[:space:]]*(.*)
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: There appears to be one additional problem. Sometimes I get the following cycle: The patch below fixes it. Again, it's probably crude, since I'm not that familiar with all of make's tricks. I noticed you added some rules for .u which contain a strip step in the toplevel Makerules, but I'm not sure how to use these. Comments? I would prefer the attached, completely untested hunks. Please apply if it works for you. PS: seen that odd glitch with new pthreads and pthread_atfork.oS already? I'll look at it later.. Index: Makerules === --- Makerules (revision 22200) +++ Makerules (working copy) @@ -121,6 +121,8 @@ maybe_exec = $(if $(strip $(compare_flag @set -e; \ $(disp_$(1)); \ $(cmd_$(1)); \ + $(if $(strip $(filter $@,$(subst $(top_srcdir),,$(STRIP_T_FILES,$(disp_t_strip);$(cmd_t_strip);) \ + $(if $(strip $(filter $@,$(subst $(top_srcdir),,$(STRIP_FILES,$(disp_strip);$(cmd_strip);) \ echo 'cmd_$@ := $(cmd_$1)' $(dir $@).$(notdir $@).dep) CFLAGS_gen.dep = -MT $@ -MD -MP -MF $(dir $@).$(notdir $@).dep Index: libpthread/linuxthreads.old/Makefile.in === --- libpthread/linuxthreads.old/Makefile.in (revision 22200) +++ libpthread/linuxthreads.old/Makefile.in (working copy) @@ -83,13 +83,13 @@ $(top_builddir)lib/libpthread.so: $(libp # $(call linkm.so,$(libpthread_FULL_NAME),$(MAJOR_VERSION)) #endif -$(libpthread_OUT)/libpthread_so.a: $(libpthread-so-y) - $(Q)$(RM) $@ +STRIP_T_FILES+=$(libpthread_so-y) $(libpthread-a-y) ifeq ($(PTHREADS_DEBUG_SUPPORT),y) - $(do_strip:-x=-X --strip-debug) -else - $(do_strip) +$(libpthread_so-y) $(libpthread-a-y): STRIP_FLAGS=$(STRIP_FLAGS:-x=-X --strip-debug) endif + +$(libpthread_OUT)/libpthread_so.a: $(libpthread-so-y) + $(Q)$(RM) $@ $(do_ar) $(libpthread_OUT)/libpthread.oS: $(libpthread_SRC) $(libpthread_SPEC_SRC) @@ -104,11 +104,6 @@ endif $(top_builddir)lib/libpthread.a: $(libpthread-a-y) $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $@ -ifeq ($(PTHREADS_DEBUG_SUPPORT),y) - $(do_strip:-x=-X --strip-debug) -else - $(do_strip) -endif $(do_ar) linuxthreads_headers: Index: libpthread/linuxthreads/Makefile.in === --- libpthread/linuxthreads/Makefile.in (revision 22200) +++ libpthread/linuxthreads/Makefile.in (working copy) @@ -18,8 +18,10 @@ CFLAGS-libpthread/linuxthreads/sysdeps/p # and append -O1 if found #CFLAGS:=$(CFLAGS:-O0=-O1) +STRIP_T_FILES+=$(libpthread_so-y) $(libpthread-a-y) ifeq ($(PTHREADS_DEBUG_SUPPORT),y) LDFLAGS-libpthread.so := $(LDFLAGS_NOSTRIP) -Wl,-z,defs +$(libpthread_so-y) $(libpthread-a-y): STRIP_FLAGS=$(STRIP_FLAGS:-x=-X --strip-debug) else LDFLAGS-libpthread.so := $(LDFLAGS) endif @@ -98,11 +100,6 @@ $(top_builddir)lib/libpthread.so: $(libp $(libpthread_OUT)/libpthread_so.a: $(libpthread-so-y) $(Q)$(RM) $@ -ifeq ($(PTHREADS_DEBUG_SUPPORT),y) - $(do_strip:-x=-X --strip-debug) -else - $(do_strip) -endif $(do_ar) $(libpthread_OUT)/libpthread.oS: $(libpthread_SRC) @@ -117,11 +114,6 @@ endif $(top_builddir)lib/libpthread.a: $(libpthread-a-y) $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $@ -ifeq ($(PTHREADS_DEBUG_SUPPORT),y) - $(do_strip:-x=-X --strip-debug) -else - $(do_strip) -endif $(do_ar) linuxthreads_headers: ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Tue, Jun 03, 2008 at 11:36:21AM +0200, Bernd Schmidt wrote: Alright. The repeated superfluous rebuild of libpthread/linuxthreads/pthread_atfork.oS was due to a missing files.dep := $(libc-a-y) $(libc-so-y) $(libc-nonshared-y) $(libm-a-y) $(libm-so-y) -files.dep += $(libpthread-a-y) $(libpthread-so-y) $(libthread_db-a-y) $(libthread_db-so-y) +files.dep += $(libpthread-a-y) $(libpthread-so-y) $(libthread_db-a-y) $(libthread_db-so-y) $(libpthread-nonshared-y) files.dep += $(librt-a-y) $(librt-so-y) $(libresolv-a-y) $(libresolv-so-y) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/misc/syslog
On Tue, Jun 03, 2008 at 07:26:13AM -0700, [EMAIL PROTECTED] wrote: Author: vda Date: 2008-06-03 07:26:12 -0700 (Tue, 03 Jun 2008) New Revision: 22201 -static intLogFile = -1; /* fd for log */ -static smalluint connected; /* have done connect */ -static intLogStat = 0;/* status bits, set by openlog() */ -static const char *LogTag = syslog; /* string to tag the entry with */ -static intLogFacility = LOG_USER; /* default facility code */ -static intLogMask = 0xff; /* mask of priorities to be logged */ -static struct sockaddr SyslogAddr;/* AF_UNIX address of local logger */ +static int LogFile = -1; /* fd for log */ +static smalluint connected; /* have done connect */ +/* all bits in option argument for openlog() fit in 8 bits */ +static smalluint LogStat = 0; /* status bits, set by openlog() */ +static const char *LogTag = syslog; /* string to tag the entry with */ +/* this fits in 8 bits too (LOG_LOCAL7 = 233 = 184), + * but NB: LOG_FACMASK is bigger (= 0x03f8 = 1273) for some strange reason. + * Oh well. */ +static int LogFacility = LOG_USER;/* default facility code */ +/* bits mask of priorities (eight prios - 8 bits is enough) */ +static smalluint LogMask = 0xff;/* mask of priorities to be logged */ can't we just use different masks and just use one (let's say) static unsigned int _state; Even if this would not proove benefical in this very spot, there are quite some functions that can be shrinked by just masking several smaller state-vars (each only using a ver few bits) into one. Comments? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/ldso/ldso
On Fri, May 30, 2008 at 04:19:26PM +0200, Bernd Schmidt wrote:
[EMAIL PROTECTED] wrote:
-if (!(tpnt-init_flag RELOCS_DONE))
+if (!(tpnt-init_flag RELOCS_DONE)) {
_dl_if_debug_dprint(relocation processing: %s\n,
tpnt-libname);
-
+}
Seems to me it would be better to fix the macro than all of its callers?
Of course you're right.
So the only immediately annoying thing in ldso remains:
ldso/ldso/dl-elf.c: In function '_dl_load_shared_library':
ldso/ldso/dl-elf.c:201: warning: unused parameter 'tpnt'
If one has turned off RUNPATH support. Not sure if setting
TREE_USED(tpnt)=1 or dropping that parameter is better.
I take it that gcc does not drop dead parameters for obvious reasons,
so i'm leaning towards ifdef'ing it out. Cosmetics.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/ldso/ldso
On Fri, May 30, 2008 at 04:45:05PM +0200, Bernd Schmidt wrote: Bernhard Fischer wrote: So the only immediately annoying thing in ldso remains: ldso/ldso/dl-elf.c: In function '_dl_load_shared_library': ldso/ldso/dl-elf.c:201: warning: unused parameter 'tpnt' The solution in the gcc tree is to use __attribute__((unused)) for Yes, that's what i ment. anything that may be unused for certain configurations. Or one could just ignore the warning. I'll ignore it for now (and yes, i am). ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
improve config [was: Re: Stubbing out unavailable syscalls?]
On Thu, May 29, 2008 at 11:37:29PM +0200, Joakim Tjernlund wrote: -Original Message- From: Bernhard Fischer [mailto:[EMAIL PROTECTED] Sent: den 29 maj 2008 21:21 To: Joakim Tjernlund Cc: uclibc@uclibc.org Subject: Re: Stubbing out unavailable syscalls? On Tue, May 27, 2008 at 07:03:28PM +0200, Bernhard Fischer wrote: I can live with stubs behind a config option, default off. My motivations comes from being able to turn them off, so i fully agree. text data bss dec hex filename 14319 244 84 146473937 lib-4.4-HEAD/ld-uClibc.so 14200 244 84 1452838c0 new-4.4-HEAD/ld-uClibc.so 2108 188 02296 8f8 lib-4.4-HEAD/librt.so size: 'new-4.4-HEAD/librt.so': No such file 112684 8609988 123532 1e28c lib-4.4-HEAD/libuClibc-0.9.29.so 105024 8729956 115852 1c48c new-4.4-HEAD/libuClibc-0.9.29.so 2604 240 02844 b1c lib-4.4-HEAD/libutil.so 1720 220 01940 794 new-4.4-HEAD/libutil.so Don't see a patch in here, but I am good anyway as the default will be no stubs. Sorry, patch is here: uclibc.org/~aldot/uClibc/uClibc-0.9.29-optional-features.01p3.diff As said, i've dropped the syscall-stubs for now and just added config-knobs for stuff that should be optional. Allnoconfig (with termios support turned on since this is not yet finished) gives: textdata bss dec hex filename 78553 6489192 88393 15949 lib/libuClibc-0.9.29.so Which starts to be ok for me. TODOs: - fix turning off or give up on termios - make sure that IPv6-only works. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc...
On Mon, May 19, 2008 at 03:57:36PM -0700, [EMAIL PROTECTED] wrote: Author: vda Date: 2008-05-19 15:57:34 -0700 (Mon, 19 May 2008) New Revision: 22012 Log: Moving libc_hidden_proto's into #ifdef UCLIBC_INTERNAL block in string.h and strings.h. This caught unguarded string ops in libc/inet/ethers.c __ether_line_w() function. I will wait for fallout reports for a week or so, then continue converting more libc_hidden_proto's. CC libc/string/wcscasecmp.os libc/string/strcasecmp.c:45: error: '__EI_wcscasecmp' aliased to undefined symbol '__GI_wcscasecmp' ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] build system replacement
On Thu, May 29, 2008 at 07:31:04PM +0200, Bernd Schmidt wrote: Denys Vlasenko wrote: I noticed that uclibc build system is broken. After I touch a file, running make won't rebuild it. As far as I can tell, only files that go into libc.so and not into libc.a, such as forward.c from libpthread, are affected. This seems to have been broken by revision 12519, which changed some Makefiles to give rules to build lib/libc.so, but the target we're trying to build is still lib/libc.so.0. So I decided to replace build system, using my experience in replacing build system for busybox. We can't rewrite entire subsystems everytime we find a bug. Better to understand what's wrong: in this case the fix is quite simple. Try the patch below. We should also apply the hunk below, interp.os is getting linked in twice, otherwise. To me, it looks like we already properly have libc/Makefile.in:LIBS-libc.so := $(interp) $(ldso) $(top_builddir)lib/$(NONSHARED_LIBNAME) Rules.mak:LIBS := $(interp) -L$(top_builddir)lib $(libc:.$(MAJOR_VERSION)=) which is sufficient, AFAICS. Can you confirm this? Without the fix below, we end up with linking any .so with lib/interp.os ./lib/interp.os ./lib/ld-uClibc.so.0 (for linkm.so) which is too much. Oh, and more importantly we should find a more elegant solution for specifying the dependencies of multi-src files like i did yesterday in inet/Makefile.in (aka r22112). Index: Makerules === --- Makerules (revision 22127) +++ Makerules (working copy) @@ -8,7 +8,7 @@ ifeq ($(HAVE_SHARED),y) .LIBPATTERNS: lib%.so libs: $(lib-so-y) $(lib-a-y) -$(lib-so-y): $(interp) +$(lib-so-y): else .LIBPATTERNS: lib%.a ifeq ($(UCLIBC_FORMAT_SHARED_FLAT),y) ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Stubbing out unavailable syscalls?
On Tue, May 27, 2008 at 07:03:28PM +0200, Bernhard Fischer wrote: I can live with stubs behind a config option, default off. My motivations comes from being able to turn them off, so i fully agree. textdata bss dec hex filename 14319 244 84 146473937 lib-4.4-HEAD/ld-uClibc.so 14200 244 84 1452838c0 new-4.4-HEAD/ld-uClibc.so 2108 188 02296 8f8 lib-4.4-HEAD/librt.so size: 'new-4.4-HEAD/librt.so': No such file 112684 8609988 123532 1e28c lib-4.4-HEAD/libuClibc-0.9.29.so 105024 8729956 115852 1c48c new-4.4-HEAD/libuClibc-0.9.29.so 2604 240 02844 b1c lib-4.4-HEAD/libutil.so 1720 220 01940 794 new-4.4-HEAD/libutil.so The new- is with the following new options turned off: @@ -95,8 +95,8 @@ # UCLIBC_SUSV3_LEGACY_MACROS is not set # UCLIBC_HAS_SHADOW is not set # UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set -UNIX98PTY_ONLY=y -# ASSUME_DEVPTS is not set +# UCLIBC_HAS_GNU_ERROR is not set +# UCLIBC_HAS_PTY is not set # UCLIBC_HAS_TM_EXTENSIONS is not set # UCLIBC_HAS_TZ_CACHING is not set # UCLIBC_HAS_TZ_FILE is not set @@ -106,11 +106,25 @@ # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 +# UCLIBC_SYSCALL_STUBS is not set + +# +# Syscall availability +# # UCLIBC_LINUX_MODULE_24 is not set +# UCLIBC_LINUX_SPECIFIC is not set +# UCLIBC_BSD_SPECIFIC is not set +# UCLIBC_NTP_LEGACY is not set +# UCLIBC_SV4_DEPRECATED is not set +# UCLIBC_HAVE_REALTIME is not set +# UCLIBC_HAVE_EPOLL is not set +# UCLIBC_HAVE_XATTR is not set +# UCLIBC_HAVE_PROFILING is not set I'll drop the syscall stubs for now from this patch. It's not that much (10999 bytes) but ok for a start. What do you think? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Stubbing out unavailable syscalls?
On Tue, May 20, 2008 at 07:48:58PM +0200, Bernhard Fischer wrote: I'm attaching a proposal that allows for conveniently adding stubs by Updated patch: http://uclibc.org/~aldot/uClibc/uClibc-0.9.29.syscall-stubs.02p3.diff - adds several config-options to allow for turning off certain features like o UCLIBC_HAS_GNU_ERROR o UCLIBC_HAS_PTY o UCLIBC_HAS_GETPT (1) o UCLIBC_SYSCALL_STUBS o UCLIBC_SYSCALL_STUB_WARNING o UCLIBC_LINUX_SPECIFIC (2) o UCLIBC_BSD_SPECIFIC (3) o UCLIBC_NTP_LEGACY (4) o UCLIBC_SV4_DEPRECATED (5) o UCLIBC_HAVE_REALTIME (6) o UCLIBC_HAVE_ADVANCED_REALTIME (7) o UCLIBC_HAVE_EPOLL (8) o UCLIBC_HAVE_XATTR (9) o UCLIBC_HAVE_PROFILING (10) (1) and implement posix_openpt (2) fstatfs(), inotify_*(), ioperm(), iopl(), madvise(), modify_ldt(), personality() ppoll(), setresuid() (3) mincore(), getdomainname(), setdomainname() (4) ntp_adjtime(), ntp_gettime() aliases (5) ustat() [use statfs(2) in your code instead] (6) All marked as (REALTIME) in SUSv3 (7) All marked as (ADVANCED REALTIME) in SUSv3 (8) epoll_create(), epoll_ctl(), epoll_wait() (9) all Extended Attributes (10) helpers for gcc's -finstrument-functions - Fixes missing dep on the script that generates sysnum.h - Fixes _dl_exit() - Implements sleep(3) for !UCLIBC_HAVE_REALTIME - Implements usleep(3) for !UCLIBC_HAVE_REALTIME i386 is already converted, perhaps i'll do alpha next, but alpha doesn't look like it's really complete yet anyway. Statistics: extra/scripts/gen_bits_syscall_h.sh |3 extra/Configs/Config.in | 200 +++ include/sys/syscall.h|3 Makerules|2 ldso/include/dl-syscall.h|8 libutil/Makefile.in |4 libc/inet/resolv.c |6 libc/stdlib/Makefile.in |7 libc/stdlib/getpt.c | 40 ++- libc/stdlib/bsd_getpt.c |2 libc/unistd/pathconf.c |5 libc/unistd/sleep.c | 55 + libc/unistd/fpathconf.c |7 libc/unistd/usleep.c | 14 + libc/sysdeps/linux/common/getgid.c |1 libc/sysdeps/linux/common/mlock.c|1 libc/sysdeps/linux/common/close.c|1 libc/sysdeps/linux/common/poll.c |3 libc/sysdeps/linux/common/setregid.c |1 libc/sysdeps/linux/common/utimes.c |1 libc/sysdeps/linux/common/munlock.c |2 libc/sysdeps/linux/common/create_module.c| 16 - libc/sysdeps/linux/common/read.c |1 libc/sysdeps/linux/common/posix_fadvise64.c |7 libc/sysdeps/linux/common/getsid.c |1 libc/sysdeps/linux/common/getpriority.c |1 libc/sysdeps/linux/common/getuid.c |1 libc/sysdeps/linux/common/arch_prctl.c |6 libc/sysdeps/linux/common/setreuid.c |1 libc/sysdeps/linux/common/wait4.c|3 libc/sysdeps/linux/common/sched_get_priority_min.c |1 libc/sysdeps/linux/common/sysinfo.c |5 libc/sysdeps/linux/common/ftruncate.c|1 libc/sysdeps/linux/common/alarm.c|1 libc/sysdeps/linux/common/setpriority.c |1 libc/sysdeps/linux/common/readahead.c|1 libc/sysdeps/linux/common/time.c |1 libc/sysdeps/linux/common/fchdir.c |1 libc/sysdeps/linux/common/access.c |6 libc/sysdeps/linux/common/xattr.c| 158 +-- libc/sysdeps/linux/common/iopl.c |5 libc/sysdeps/linux/common/statfs.c | 17 + libc/sysdeps/linux/common/_exit.c|1 libc/sysdeps/linux/common/vhangup.c |1 libc/sysdeps/linux/common/clock_gettime.c|1 libc/sysdeps/linux/common/acct.c |5 libc/sysdeps/linux/common/epoll.c| 37 +-- libc/sysdeps/linux/common/bits/uClibc_syscall-stub.h | 96 + libc/sysdeps/linux/common/fstat.c|1 libc/sysdeps/linux/common/sysctl.c | 19 + libc/sysdeps/linux/common/times.c|1 libc/sysdeps/linux/common/sigsuspend.c |4 libc/sysdeps/linux/common/clock_settime.c|1 libc/sysdeps/linux/common/truncate.c |1 libc/sysdeps/linux/common/getrusage.c|1 libc/sysdeps/linux/common/umount.c
Re: Stubbing out unavailable syscalls?
On Tue, May 20, 2008 at 10:25:23PM +0200, Joakim Tjernlund wrote: -Original Message- From: Bernhard Fischer [mailto:[EMAIL PROTECTED] Sent: den 20 maj 2008 22:20 To: Joakim Tjernlund Cc: uclibc@uclibc.org Subject: Re: Stubbing out unavailable syscalls? On Tue, May 20, 2008 at 09:07:26PM +0200, Joakim Tjernlund wrote: Still think ease of cross compiling is more important than stubs. I don't see how this is in any way related to cross compilation since sysnum.h is created just fine either way. Please elaborate? configure often tests for presence of a function by compiling a test program which will fail when that function is undefined. There are only a very few functions stubbed out. Are there any apps that is broken due to missing stubs? Anything that checks if a syscall works is potentially affected. Yes obviously, I wanted a list of such apps(if there are any) For some functions a stub is mandated by standards (e.g. crypt(), encrypt(), setkey()) I can live with stubs behind a config option, default off. My motivations comes from being able to turn them off, so i fully agree. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] doubt in _dl_exit
Could somebody who uses ldso please have a look if this breaks his
setup?
$ size ldso/ldso/ldso.oS*
textdata bss dec hex filename
12424 12 72 1250830dc ldso/ldso/ldso.oS.old
12290 12 72 123743056 ldso/ldso/ldso.oS
@@ -59,7 +59,11 @@
dynamic linking at all, so we cannot return any error codes.
We just punt if there is an error. */
#define __NR__dl_exit __NR_exit
-static __always_inline _syscall1(void, _dl_exit, int, status);
+static __always_inline attribute_noreturn void _dl_exit(int status)
+{
+ while (1)
+ INLINE_SYSCALL(exit, 1, status);
+}
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] smallint
On Tue, May 20, 2008 at 12:18:58AM +0200, Denys Vlasenko wrote:
Hi,
Attached patch instroduces smallint type, and uses it
for flag variables. It results in size reduction
ont only for bss, but text too:
text data bss dec hex filename
-648 4 24 676 2a4
libc/misc/internals/__uClibc_main.o
+645 4 21 670 29e
libc/misc/internals/__uClibc_main.o
-129 0 4 133 85 libc/termios/tcgetsid.o
+126 0 1 127 7f libc/termios/tcgetsid.o
because flag_var = 1 is a smaller instruction now.
Size in smallint can be set per-architecture.
I am a bit unsire I picked suitable include files to put
new definitions in.
Can someone eyeball the patch?
--
vda
diff -d -urpN uClibc.1/libc/termios/tcgetsid.c uClibc.2/libc/termios/tcgetsid.c
--- uClibc.1/libc/termios/tcgetsid.c 2008-05-19 16:23:16.0 +0200
+++ uClibc.2/libc/termios/tcgetsid.c 2008-05-20 00:03:31.0 +0200
@@ -34,7 +34,7 @@ tcgetsid (fd)
pid_t pgrp;
pid_t sid;
#ifdef TIOCGSID
- static int tiocgsid_does_not_work;
+ static smallint tiocgsid_does_not_work;
For cases like this i prefer to just use a bool.
if (! tiocgsid_does_not_work)
{
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: extra/locale include libc/misc/ctype lib etc...
On Mon, May 19, 2008 at 08:24:15AM -0700, [EMAIL PROTECTED] wrote:
Author: carmelo
Date: 2008-05-19 08:24:14 -0700 (Mon, 19 May 2008)
New Revision: 22011
Log:
Added a bounch of locale fixes.
This breaks compilation for me (who does not need no stinkin' locale ;):
CC libc/misc/ctype/isalnum.os
In file included from libc/misc/ctype/ctype.c:37,
from libc/misc/ctype/isalnum.c:8:
./include/locale.h:152: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'locale_t'
./include/locale.h:158: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'newlocale'
./include/locale.h:206: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'duplocale'
./include/locale.h:210: error: expected ')' before '__dataset'
./include/locale.h:217: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'uselocale'
make[1]: *** [libc/misc/ctype/isalnum.os] Error 1
* extra/locale/gen_wc8bit.c: use strrchr to parse locale
name to handle the case in which it contains a '.' character
like ANSI_X3.4-1968
* include/locale.h: use __UCLIBC_HAS_XLOCALE__ to control
inclusion of xlocale.h only
* libc/misc/ctype/ctype.c: add missing weak_alias for
__tolower_l and __toupper_l
* libc/misc/locale/locale.c: use strcasecmp (case insensitive)
for utf-8 locale name.
Those should have been distinct commits imo.
Please fix the !locale config.
TIA,
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Modified:
trunk/uClibc/extra/locale/gen_wc8bit.c
trunk/uClibc/include/locale.h
trunk/uClibc/libc/misc/ctype/ctype.c
trunk/uClibc/libc/misc/locale/locale.c
Changeset:
Modified: trunk/uClibc/extra/locale/gen_wc8bit.c
===
--- trunk/uClibc/extra/locale/gen_wc8bit.c 2008-05-19 10:28:32 UTC (rev
22010)
+++ trunk/uClibc/extra/locale/gen_wc8bit.c 2008-05-19 15:24:14 UTC (rev
22011)
@@ -189,7 +189,7 @@
} else {
++s0;
}
- s1 = strchr(s0, '.');
+ s1 = strrchr(s0, '.');
if (!s1) {
n = strlen(s0);
} else {
Modified: trunk/uClibc/include/locale.h
===
--- trunk/uClibc/include/locale.h 2008-05-19 10:28:32 UTC (rev 22010)
+++ trunk/uClibc/include/locale.h 2008-05-19 15:24:14 UTC (rev 22011)
@@ -132,7 +132,7 @@
__END_NAMESPACE_STD
-#if defined(__USE_GNU) defined(__UCLIBC_HAS_XLOCALE__)
+#if defined(__USE_GNU)
/* The concept of one static locale per category is not very well
thought out. Many applications will need to process its data using
information from several different locales. Another application is
@@ -144,8 +144,10 @@
Attention: all these functions are *not* standardized in any form.
This is a proof-of-concept implementation. */
+#if defined(__UCLIBC_HAS_XLOCALE__)
/* Get locale datatype definition. */
# include xlocale.h
+#endif
typedef __locale_t locale_t;
Modified: trunk/uClibc/libc/misc/ctype/ctype.c
===
--- trunk/uClibc/libc/misc/ctype/ctype.c 2008-05-19 10:28:32 UTC (rev
22010)
+++ trunk/uClibc/libc/misc/ctype/ctype.c 2008-05-19 15:24:14 UTC (rev
22011)
@@ -316,6 +316,7 @@
return __UCLIBC_CTYPE_IN_TO_DOMAIN(c) ? l-__ctype_tolower[c] : c;
}
libc_hidden_def(tolower_l)
+weak_alias (tolower_l, __tolower_l)
#endif
/**/
@@ -362,6 +363,7 @@
return __UCLIBC_CTYPE_IN_TO_DOMAIN(c) ? l-__ctype_toupper[c] : c;
}
libc_hidden_def(toupper_l)
+weak_alias (toupper_l, __toupper_l)
#endif
/**/
Modified: trunk/uClibc/libc/misc/locale/locale.c
===
--- trunk/uClibc/libc/misc/locale/locale.c 2008-05-19 10:28:32 UTC (rev
22010)
+++ trunk/uClibc/libc/misc/locale/locale.c 2008-05-19 15:24:14 UTC (rev
22011)
@@ -1142,7 +1142,7 @@
/* TODO: maybe CODESET_LIST + *s ??? */
/* 7bit is 1, UTF-8 is 2, 8-bit is = 3 */
codeset = 2;
- if (strcmp(utf8,p+6) != 0) {/* TODO - fix! */
+ if (strcasecmp(utf8,p+6) != 0) {/* TODO - fix! */
s = CODESET_LIST;
do {
++codeset; /* Increment codeset
first. */
___
uClibc-cvs mailing list
[EMAIL PROTECTED]
http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc...
On Mon, May 19, 2008 at 03:57:36PM -0700, [EMAIL PROTECTED] wrote: Author: vda Date: 2008-05-19 15:57:34 -0700 (Mon, 19 May 2008) New Revision: 22012 Log: Moving libc_hidden_proto's into #ifdef UCLIBC_INTERNAL block in string.h and strings.h. This caught unguarded string ops in libc/inet/ethers.c __ether_line_w() function. I will wait for fallout reports for a week or so, CC libpthread/linuxthreads.old/forward.oS In file included from libpthread/linuxthreads.old/../linuxthreads.old_db/thread_dbP.h:7, from libpthread/linuxthreads.old/internals.h:32, from libpthread/linuxthreads.old/forward.c:27: ./include/string.h:440: warning: asm declaration ignored due to conflict with previous rename ./include/string.h:441: warning: asm declaration ignored due to conflict with previous rename ./include/string.h:443: warning: asm declaration ignored due to conflict with previous rename ./include/string.h:445: warning: asm declaration ignored due to conflict with previous rename ./include/string.h:446: warning: asm declaration ignored due to conflict with previous rename ./include/string.h:447: warning: asm declaration ignored due to conflict with previous rename [snip all the rest] Please let me know if you need additional info. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: pow() bug?
On Sat, May 17, 2008 at 09:37:11AM -0700, John MacCallum wrote: Hi all, I'm having some trouble with the pow() function. The code below gives me answers of 0.00 when compiled for an arm machine. Any help would be greatly appreciated. buggy toolchain? 0) What toolchain do you use? 1) does it properly say pow: 2.028875 exp: 1.855277 for e.g. -O0 ? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Stubbing out unavailable syscalls?
On Thu, Feb 01, 2007 at 02:45:09PM +0100, Bernhard Fischer wrote:
On Thu, Feb 01, 2007 at 01:31:18PM +0100, Joakim Tjernlund wrote:
O
Well, do we -ENOSYS if something isn't available?
If so, then we should rather
#ifdef __NR_readahead
[snip current code]
#else
ssize_t readahead(int fd, off_t offset, size_t count)
{
__set_errno(ENOSYS);
return -1;
}
link_warning(readahead,not available)
#endif
Wondering if there should be a generic internal helper stub for
the ENOSYS;ret -1 case..
This can make cross compiling painful since you can't tell if
readahead is present or not.
On the other hand, a well behaved app will handle this dynamically ...
Either way, behaviour should imho be consistent, and it is not, from a
quick grep for ENOSYS. Didn't really look, admittedly.
Not stubbing unsupported functions out sounds smaller. Deciding what
route to take, either to stub them out or making them not available
isn't my call, though.
[replying to this old thread]
So.. what do people think should be done in this respect?
I'm attaching a proposal that allows for conveniently adding stubs by
doing this:
--- 8 ---
#include bits/syscall-stub.h
#define __SYSCALL_STUB __NR_pivot_root
#include sys/syscall.h
int pivot_root(const char *new_root, const char *put_old);
_syscall2(int, pivot_root, const char *, new_root, const char *, put_old);
--- 8 ---
instead of manually providing a __set_errno(ENOSYS);return -1; stub
It converts a few conditional syscalls to this proposed scheme as an
example.
This way we could even have a config-option that decides if there should
be any stubs or none (not talking about alternative impls, they are of
no interrest for now).
Opinions?
Index: include/sys/syscall.h
===
--- include/sys/syscall.h (revision 22022)
+++ include/sys/syscall.h (working copy)
@@ -31,6 +31,11 @@
#include features.h
#include bits/sysnum.h
#if defined _LIBC (defined IS_IN_libc || defined NOT_IN_libc)
+# if defined __SYSCALL_STUB __SYSCALL_STUB
+ /* Syscall exists, no stub needed. */
+# undef __SYSCALL_STUB
+# endif
+
# include bits/syscalls.h
#endif
Index: libc/sysdeps/linux/common/access.c
===
--- libc/sysdeps/linux/common/access.c (revision 22022)
+++ libc/sysdeps/linux/common/access.c (working copy)
@@ -7,6 +7,8 @@
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
+#include bits/syscall-stub.h
+#define __SYSCALL_STUB __NR_access
#include sys/syscall.h
#include unistd.h
_syscall2(int, access, const char *, pathname, int, mode);
Index: libc/sysdeps/linux/common/bdflush.c
===
--- libc/sysdeps/linux/common/bdflush.c (revision 22022)
+++ libc/sysdeps/linux/common/bdflush.c (working copy)
@@ -7,15 +7,9 @@
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
+#include bits/syscall-stub.h
+#define __SYSCALL_STUB __NR_bdflush
#include sys/syscall.h
#include sys/kdaemon.h
-#ifdef __NR_bdflush
_syscall2(int, bdflush, int, __func, long int, __data);
-#else
-int bdflush(int __func, long int __data)
-{
- __set_errno(ENOSYS);
- return -1;
-}
-#endif
Index: libc/sysdeps/linux/common/capget.c
===
--- libc/sysdeps/linux/common/capget.c (revision 22022)
+++ libc/sysdeps/linux/common/capget.c (working copy)
@@ -6,15 +6,9 @@
*
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
-
+#include bits/syscall-stub.h
+#define __SYSCALL_STUB __NR_capget
#include sys/syscall.h
+
int capget(void *header, void *data);
-#ifdef __NR_capget
_syscall2(int, capget, void *, header, void *, data);
-#else
-int capget(void *header, void *data)
-{
- __set_errno(ENOSYS);
- return -1;
-}
-#endif
Index: libc/sysdeps/linux/common/adjtimex.c
===
--- libc/sysdeps/linux/common/adjtimex.c (revision 22022)
+++ libc/sysdeps/linux/common/adjtimex.c (working copy)
@@ -7,6 +7,8 @@
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
+#include bits/syscall-stub.h
+#define __SYSCALL_STUB __NR_adjtimex
#include sys/syscall.h
#include sys/timex.h
Index: libc/sysdeps/linux/common/capset.c
===
--- libc/sysdeps/linux/common/capset.c (revision 22022)
+++ libc/sysdeps/linux/common/capset.c (working copy)
@@ -6,15 +6,9 @@
*
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
-
+#include bits/syscall-stub.h
+#define __SYSCALL_STUB __NR_capset
#include sys/syscall.h
+
int capset(void *header, const void *data);
-#ifdef __NR_capset
_syscall2(int, capset, void *, header, const void *, data);
-#else
-int capset(void *header, const void *data)
-{
- __set_errno(ENOSYS);
- return -1;
-}
-#endif
Index
Re: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc...
On Tue, May 20, 2008 at 08:40:19PM +0200, Denys Vlasenko wrote: I can reproduce it. In fact, there is a hint in libpthread/linuxthreads.old/forward.c that something is fishy here: #include features.h #include stdlib.h #include dlfcn.h /* psm: keep this before internals.h */ == libc_hidden_proto(exit) #include internals.h ... psm noticed that doing libc_hidden_proto(exit) AFTER #include internals.h produces a warning, and commented about it. But he either didn't look into why? or he didn't describe it in comments. Bad boy psm, bad ;) [joking] The same thing bites here, just with libc_hidden_proto(memcpy) etc. instead. it happens inside internals.h when it includes string.h. I killed 20 minutes finding out why?. It happens quite deep in include tree. I took unmodified tree (prior to rev 22012) and played with adding just libc_hidden_proto(memcpy). In libpthread/linuxthreads.old/sysdeps/pthread/bits/libc-lock.h adding #include string.h and libc_hidden_proto(memcpy) just before weak_extern (__pthread_initialize) will not warn: //warns? no //#include string.h //libc_hidden_proto(memcpy) weak_extern (__pthread_initialize) //warns? yes //#include string.h //libc_hidden_proto(memcpy) but adding after it will! Which is extremely strange - weak_extern expands into just #pragma weak __pthread_initialize These are exact gcc commands which are used to generate forward.oS: gcc -E libpthread/linuxthreads.old/forward.c -o forward.i.c -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -Wnonnull -Wundef -ffunction-sections -fdata-sections -m32 -march=i486 -fstack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/i386 -DUCLIBC_INTERNAL -std=gnu99 -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fomit-frame-pointer -mpreferred-stack-boundary=2 -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/i386 -I./libpthread/linuxthreads.old/sysdeps/i386 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/usr/srcdevel/uclibc/include_2.6.18.1/include/ -iwithprefix include-fixed -iwithprefix include -DMALLOC_DEBUGGING -DHEAP_DEBUGGING -fPIC -DSHARED -fstack-protector-all gcc -c forward.i.c -o forward.i.oS -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -fno-strict-aliasing -Wnested-externs -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -Wnonnull -Wundef -ffunction-sections -fdata-sections -m32 -march=i486 -fstack-protector -fno-builtin -nostdinc -I./include -I. -I./libc/sysdeps/linux/i386 -DUCLIBC_INTERNAL -std=gnu99 -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fomit-frame-pointer -mpreferred-stack-boundary=2 -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux/i386 -I./libpthread/linuxthreads.old/sysdeps/i386 -I./libpthread/linuxthreads.old/sysdeps/unix/sysv/linux -I./libpthread/linuxthreads.old/sysdeps/pthread -I./libpthread/linuxthreads.old -I./libpthread -I/usr/srcdevel/uclibc/include_2.6.18.1/include/ -iwithprefix include-fixed -iwithprefix include -DMALLOC_DEBUGGING -DHEAP_DEBUGGING -fPIC -DSHARED -fstack-protector-all Can you confirm my observation by adding #include string.h and libc_hidden_proto(memcpy) after weak_extern (__pthread_initialize) and running above two commands? Also note: if you will run first command, then comment out this line in forward.i.c: //#pragma weak __pthread_initialize which should change nothing - __pthread_initialize is not mentined anywhere else in forward.i.c - and run the second command - it will NOT warn! Looks like gcc bug to me. hmz. I'll try to reproduce this sometimes in the next days. Do you have a small standalone testcase that exposes this alleged bug that you could put into the gcc bugzilla, by chance? P.S. I am getting tons of warnings like this: I've fixed those earlier today, please svn up and holler if you still get alot of them (a *few* undefined tokens are expected, ATM) CC libpthread/linuxthreads.old/spinlock.o In file included from ./libpthread/linuxthreads.old/sysdeps/i386/tls.h:23, from ./include/bits/uClibc_errno.h:14, from ./include/errno.h:62, from libpthread/linuxthreads.old/spinlock.c:19: ./libpthread/linuxthreads.old/sysdeps/i386/pt-machine.h:76:5: warning: __ASSUME_LDT_WORKS is not defined In file included from libpthread/linuxthreads.old/internals.h:22, from libpthread/linuxthreads.old/spinlock.c:25:
Re: Stubbing out unavailable syscalls?
On Tue, May 20, 2008 at 09:07:26PM +0200, Joakim Tjernlund wrote: Still think ease of cross compiling is more important than stubs. I don't see how this is in any way related to cross compilation since sysnum.h is created just fine either way. Please elaborate? Are there any apps that is broken due to missing stubs? Anything that checks if a syscall works is potentially affected. I can live with stubs behind a config option, default off. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc...
On Tue, May 20, 2008 at 09:43:38PM +0200, Denys Vlasenko wrote:
On Tuesday 20 May 2008 21:35, Denys Vlasenko wrote:
On Tuesday 20 May 2008 20:52, Bernhard Fischer wrote:
which should change nothing - __pthread_initialize is not mentined
anywhere else
in forward.i.c - and run the second command - it will NOT warn!
Looks like gcc bug to me.
hmz. I'll try to reproduce this sometimes in the next days. Do you have
a small standalone testcase that exposes this alleged bug that you could
put into the gcc bugzilla, by chance?
Not yet.
Here is it. Just run gcc -c test.c on this:
#pragma weak __pthread_initialize
aha. I'm not a fan of pragma, and i wouldn't be surprised if this would
work if you would (properly, i'd tend to say) use the attribute.
Something like
extern int __pthread_initialize(void) __attribute__((weak));
any better?
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, int __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern __typeof (memcpy) memcpy __asm__ ( __GI_memcpy) __attribute__
((visibility (hidden)));
void f(void) {}
$ gcc -c test.c
test.c:5: warning: asm declaration ignored due to conflict with previous rename
$ gcc -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr/app/gcc-4.2.1
--exec-prefix=/usr/app/gcc-4.2.1 --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/app/gcc-4.2.1/libexec --datadir=/usr/app/gcc-4.2.1/share
--sysconfdir=/etc --sharedstatedir=/usr/app/gcc-4.2.1/var/com
--localstatedir=/usr/app/gcc-4.2.1/var --libdir=/usr/lib
--includedir=/usr/include --infodir=/usr/info --mandir=/usr/man
--with-slibdir=/usr/app/gcc-4.2.1/lib --with-local-prefix=/usr/local
--with-gxx-include-dir=/usr/app/gcc-4.2.1/include/g++-v3
--enable-languages=c,c++ --without-system-zlib --disable-nls
--enable-threads=posix i386-pc-linux-gnu
Thread model: posix
gcc version 4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282
--
vda
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/inet libc/inet/rpc libc/mis etc...
On Tue, May 20, 2008 at 10:56:02PM +0200, Denys Vlasenko wrote: Possibly. Pthreads seems to need some cleanups... Let's obsolete it with nptl, so just the bare minimum needed to get the old code to somewhat behave, imho. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] realpath stack usage 8k - 4k
On Wed, May 07, 2008 at 09:06:54PM +0200, Denys Vlasenko wrote:
On Wednesday 07 May 2008 19:11, Carmelo AMOROSO wrote:
Proposed patch uses user-supplied buffer directly,
without intermediate on-stack copy.
This can only make a difference if user supplied
a buffer which is too small - thus user breaks API.
Failure scenario:
realpath(/link_name, user_buffer)
/link_name - /very_long_name_which_fits_into_PATH_MAX_and_is_also_a_link
- - /shorter_name
If user will give e.g. 40-char user_buffer, current implementation
will work, patched one will overflow user_buffer by intermediate name.
This should not be a problem - user must supply PATH_MAX sized buffer,
and in this case patched version also works correctly.
And the following patch on top of previous one reuses copy_buf[]
for readlink, eliminating link_buf[]. In order to make it work,
source pathname is kept at the end of copy_buf, not at the
beginning (so that last NUL byte is the last byte of the copy_buf[]).
The situation when readlink returns link name which is too long
(so that it overwrites pathname), was resulting in ENAMETOOLONG
error return. This patch does the same - the fact the we now trash
pathname does not matter, as we are not returning it to the user.
Run tested.
Can somebody review these patches please?
--
vda
Hi Denys,
I'm just now playing with uclibc-trunk (linuxthreads.old implementation)
and discovered
that your latest change on realpath implementation brakes test-canon
test from uclibc test-suite.
Indeed, I've run exactly the same on nptl branch (that contains the
previous implementation of
the realpath function) and it works fine.
Just built and run test here. Result:
# ./test-canon
./test-canon: flunked test 3 (expected `/etc', got `/.local/etc')
./test-canon: flunked test 4 (expected `/etc', got `/.local/etc')
./test-canon: flunked test 7 (expected resolved `/etc/doesNotExist', got
`/.local/etc/doesNotExist')
./test-canon: flunked test 14 (expected resolved `', got
`/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP')
./test-canon: flunked test 15 (expected resolved `', got
`/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP')
./test-canon: flunked test 18 (expected `/etc', got `/.local/etc')
./test-canon: flunked test 20 (expected `/etc', got `/.local/etc')
./test-canon: flunked test 22 (expected `/etc', got `/.local/etc')
./test-canon: flunked test 24 (expected `/etc', got `/.local/etc')
Except 14 and 15, test makes an assumption that /etc is not a symlink.
On my machine it is not true, so it fails.
Tests 14 and 15 say in source:
/* 10 */
{./doesExist/../doesExist, ./doesExist},
{foobar,0, ./foobar, ENOENT},
{., .},
{./foobar, 0, ./foobar, ENOENT},
#ifdef __UCLIBC__
/* we differ from glibc here, but POSIX allows it as it says that if we did
* not successfuly complete, the value of resolved_path is undefined */
{SYMLINK_LOOP, 0, , ELOOP},
/* 15 */
{./SYMLINK_LOOP,0, , ELOOP},
#else
I can make it work so that test passes. However, as this comment says,
POSIX says nothing about return buffer's contents, so alternative
I didn't (and will not) look what posix mandates in this regard, but if
posix sais that it's undefined then it's just that, undefined.
Obviously, if we can follow bloat-libc in this respect for compatibility
with minor trade-off, then please follow suite (as always) but if we
cannot, then please introduce a(nother) config-knob to follow bloat-libc
in this respect (ISTR that we flags this as glibc-compat in the comment,
fwiw).
fix would be to not check its contents, only return value and errno.
Do you want me to make readlink return or to stop testing
buffer's contents? Your pick.
cought:
no-bloat-libc-code-here;
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] splice, vmsplice and tee for i386
On Sat, May 03, 2008 at 08:33:11AM +0200, Carmelo Amoroso wrote: Khem Raj wrote: Hi We need to patch fcntl.h for all architectures where these syscalls are wired up in kernel, otherwise it will break the build for those architectures. I have already patched up arm with the attached patch and tested it. I did not patch others Thanks -Khem Yes, indeed after having updated my working copy, sh4 build was broken. I'll do the same for sh4. I think who committed the patch for splice co should do the fix for all other archs. Oh sorry, forgot about the rest. I will fix them up in a minute.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] splice, vmsplice and tee for i386
On Fri, May 02, 2008 at 09:04:08AM +0300, Timo Teräs wrote: IMHO, this is good to commit. Any objections? Applied. Thanks! ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] splice, vmsplice and tee for i386
On Thu, Apr 24, 2008 at 02:41:43PM +0300, Timo Teräs wrote: Bernhard Fischer wrote: does splice() work if !LFS ? I'm not exactly sure. splice has __off64_t * in it's prototype so it might require LFS. Perhaps you can try this with your testcase and stub it out if it doesn't work. TIA, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: PATCH: ARM INTERNAL_SYSCALL cleanup
On Mon, Apr 21, 2008 at 12:33:06AM -0700, Khem Raj wrote:
Hi
There was some duplication when defining INTERNAL_SYSCALL macro for ARM.
I have tried to clean this up with attached patch. Tested on ARM EABI
and ARM OABI. Deleted commented out code too.
OK for trunk ?
Ok, from the looks (didn't test it) with two minor changes:
s/asm/__asm__/g
s/volatile/__volatile__/g
thanks,
Thanks
-Khem
Signed-off-by: Khem Raj [EMAIL PROTECTED]
Index: libc/sysdeps/linux/arm/bits/syscalls.h
===
--- libc/sysdeps/linux/arm/bits/syscalls.h (revision 21775)
+++ libc/sysdeps/linux/arm/bits/syscalls.h (working copy)
@@ -106,100 +106,55 @@
#define INTERNAL_SYSCALL_DECL(err) do { } while (0)
#undef INTERNAL_SYSCALL
-#if defined(__ARM_EABI__)
#if !defined(__thumb__)
-#define INTERNAL_SYSCALL(name, err, nr, args...) \
- ({unsigned int __sys_result;
\
- {
\
- register int _a1 __asm__ (r0), _nr __asm__ (r7);
\
- LOAD_ARGS_##nr (args) \
- _nr = SYS_ify(name); \
- __asm__ volatile (swi 0x0 @ syscall #name \
- : =r (_a1) \
- : r (_nr) ASM_ARGS_##nr \
- : memory); \
- __sys_result = _a1;\
- }
\
- (int) __sys_result; })
-#else /* !defined(__thumb__) */
-/* So hide the use of r7 from the compiler, this would be a lot
- * easier but for the fact that the syscalls can exceed 255.
- * For the moment the LOAD_ARG_7 is sacrificed.
- */
-#define INTERNAL_SYSCALL(name, err, nr, args...)\
- ({ unsigned int __sys_result; \
-{ \
- register int _a1 asm (a1); \
- LOAD_ARGS_##nr (args) \
-register int _v3 asm (v3) = (int) (SYS_ify(name));\
- asm volatile (push {r7}\n \
-\tmov r7, v3\n \
-\tswi 0 @ syscall #name \n \
-\tpop {r7} \
- : =r (_a1) \
-: r (_v3) ASM_ARGS_##nr \
-: memory);\
- __sys_result = _a1;\
-} \
-(int) __sys_result; })
-#endif /*!defined(__thumb__)*/
-#else /* !defined(__ARM_EABI__) */
-#if !defined(__thumb__)
+#if defined(__ARM_EABI__)
#define INTERNAL_SYSCALL(name, err, nr, args...) \
- ({ unsigned int __sys_result; \
+ ({unsigned int __sys_result;\
{\
- register int _a1 __asm__ (a1); \
+ register int _a1 __asm__ (r0), _nr __asm__ (r7); \
LOAD_ARGS_##nr (args) \
- __asm__ volatile (swi %1 @ syscall #name \
+ _nr = SYS_ify(name); \
+ __asm__ volatile (swi 0x0 @ syscall #name \
: =r (_a1) \
- : i (SYS_ify(name)) ASM_ARGS_##nr\
+ : r (_nr) ASM_ARGS_##nr \
: memory); \
__sys_result = _a1;\
}\
(int) __sys_result; })
-#else
-#if 0
-/* This doesn't work because GCC uses r7 as a frame pointer in
- * some cases and doesn't notice that the _r7 value changes
- * it, resulting in mysterious crashes after the SWI.
- */
+#else /* defined(__ARM_EABI__) */
+
#define INTERNAL_SYSCALL(name, err, nr, args...) \
({ unsigned int __sys_result; \
{\
register int _a1 __asm__ (a1); \
LOAD_ARGS_##nr (args) \
- register int _r7 __asm__ (r7) = (int) (SYS_ify(name)); \
- __asm__ volatile (swi 0 @ syscall #name \
+ __asm__ volatile (swi %1 @ syscall #name \
Re: [PATCH] splice, vmsplice and tee for i386
On Tue, Apr 22, 2008 at 11:14:22AM -0700, Khem Raj wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You might also update the license header to include 2008 as well. does splice() work if !LFS ? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] splice, vmsplice and tee for i386
On Mon, Apr 21, 2008 at 12:33:59PM +0300, Timo Teräs wrote: Hi, splice et al for i386. Against svn trunk. Ah, yes. We should also see if using some of the new syscalls help busybox. I'll apply this patch in a few days unless i hear something controversial. thanks and cheers, Bernhard ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] decouple sprintf and fseek
On Wed, Apr 09, 2008 at 09:47:26PM +0200, Denys Vlasenko wrote: Hi, On Wednesday 02 April 2008 16:11, Denys Vlasenko wrote: Can you please review and comment on this bug: http://busybox.net/bugs/view.php?id=2714 Although I technically can commit this change myself, I'd much prefer for it to be reviewed by people who actively work on uclubc codebase. The same patches are attached to this mail. I am going to apply these changes. If I break anything, yell at me. If there are testsuite I can run to check for regressions, please point me to it. mompls. Following up with out-of-line breakage avoidance.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: utils/readelf built twice?
On Wed, Apr 02, 2008 at 02:49:22PM +0200, Filippo ARCIDIACONO wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Fischer Sent: Thursday, March 27, 2008 11:31 AM To: Carmelo AMOROSO Cc: uclibc@uclibc.org Subject: Re: utils/readelf built twice? On Thu, Mar 27, 2008 at 08:06:21AM +0100, Carmelo AMOROSO wrote: Bernhard Fischer wrote: Hi, Can anybody confirm that make -C utils builds readelf twice? No. The first one it is only the echo command output. That, further, is different from the compilation command. In my opinion there is something to fix. Perhaps, simply removing @$(disp_compile.c) call from the compile.u routine in Makerules file. The compilation command seems ok. What revision are you using? As mentioned below, i've since fixed this via r21505 | aldot | 2008-03-26 19:49:16 +0100 (Wed, 26 Mar 2008) | 5 lines - improve building utils Either by first compiling objects and linking those or by just passing the source to create the desired binary (this patchlet does the latter). Fixes cosmetic glitch by just not building individual .o (in pwd, at least). r21506 | aldot | 2008-03-26 20:40:39 +0100 (Wed, 26 Mar 2008) | 2 lines - fixup stripping of host utils and make host-utils compile with std=gnu99 thanks, thanks, Hi, yes you're right !!! further, ldconfig the second time is linked with chroot_realpath too. I think i improved the situation yesterday night. Please holler if i broke something. utils/*.c now even build with our default CFLAGS, i.e. with std=gnu99 Maybe i'll find the time to clean them up a little bit so they do not throw so many warnings.. Thanks, Carmelo, for verifying this and cheers ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc Regards, Filippo Arcidiacono. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uclibc segfault in ldso
On Fri, Mar 28, 2008 at 04:42:21PM +, Nigel Kukard wrote: Should I debug this further or just work with the old implementation? Well, it would be generally nice if the new linuxthreads would work on x86 if you find the time, since i don't quite see much progress in the NPTL camp. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Evaluate syscall parameters on ARM LOAD_ARGS_x macros
On Thu, Mar 27, 2008 at 01:57:02AM -0700, Khem Raj wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi While compiling uclibc on thumb and running LTP tests on it I noticed that the sched_setaffinity system calls were failing. The reason is that when the parameters to syscall macros on ARM contain function calls, gcc places the calls to evaluate the parameters at the very end just before the system call instruction (SVC) is called. This corrupts the registers that has been set up for the system call. This patch evaluates the arguments in LOAD_ARGS_x macros and also separates declaration to make it more PPC like. Thanks to Daniel Jacobowitz for this suggestion. Khem, Since you seem to use ARM, may i ask you to take a look and clean-up syscalls.h? Specifically this one spot: The INTERNAL_SYSCALL macro is duplicated, apparently needlessly. Search for r7, v3 in libc/sysdeps/linux/arm/bits/syscalls.h TIA OK ? Is this a recent breakage since Pauls thumb patch was applied or was it already there before this patch was applied (about two days ago, or the like)? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Evaluate syscall parameters on ARM LOAD_ARGS_x macros
On Thu, Mar 27, 2008 at 10:07:54AM -0700, Khem Raj wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard Fischer wrote: | On Thu, Mar 27, 2008 at 01:57:02AM -0700, Khem Raj wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | Hi | | While compiling uclibc on thumb and running LTP tests on it I noticed | that the sched_setaffinity system calls were failing. The reason is that | when the parameters to syscall macros on ARM contain function calls, gcc | places the calls to evaluate the parameters at the very end just before | the system call instruction (SVC) is called. | This corrupts the registers that has been set up for the system call. | | This patch evaluates the arguments in LOAD_ARGS_x macros and also | separates declaration to make it more PPC like. Thanks to Daniel | Jacobowitz for this suggestion. | | Khem, | | Since you seem to use ARM, may i ask you to take a look and clean-up | syscalls.h? Specifically this one spot: | | The INTERNAL_SYSCALL macro is duplicated, apparently needlessly. | Search for r7, v3 in libc/sysdeps/linux/arm/bits/syscalls.h There are 4 different variants of INTERNAL_SYSCALL 2 of them are identical, AFAICS. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [patch] Pure Thumb support
On Sat, Mar 22, 2008 at 02:07:48AM +, Paul Brook wrote: The attached patch adds support for compiling arm uClibc as pure Thumb code. This is needed because some recent ARM codes do not implement traditional ARM mode. Specifically: * Cortex-M1 - An extremely minimal FPGA based core that only implements Thumb-1 (aka ARMv6-M). * Cortex-M3 - A Thumb-2 only ARMv7-M core. Most of uClibc already builds in Thumb mode, all that is left are a handful of assembly bits. Tested on arm-uclinuxeabi. I don't have svn write access, so please apply if ok. Applied as r21498. Thanks! ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
utils/readelf built twice?
Hi, Can anybody confirm that make -C utils builds readelf twice? thanks, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Fix dladdr return value when cannot find symbol
On Fri, Feb 08, 2008 at 10:24:40AM +0100, Carmelo AMOROSO wrote: Bernd Schmidt wrote: Carmelo AMOROSO wrote: based on the patch from Nickolai, here you can find a comprehensive patch to fix dladdr function. With the current implementation, the invocation of dladdr((void *) 1, dlinfo) will fill dlinfo.dli_fname with the name of the application itself and dlinfo.dli_fbase with 0 (the current value of tpnt-loadaddr for the main app). The patch solves this adding a new field into the struct elf_resolve named DL_LOADADDR_TYPE mapaddr. For shared objects, mapaddr has exactly the same value as loadaddr, while for the main app it contains the address of the first PT_LOAD segmented loaded. loadaddr will keep it's value and will used exactly as is (as a in memory offset with respect to relative addresses from ELF sections). While in the DL_ADDR_IN_LOADADDR macro, the new field mapaddr needs to be used. This is broken on FD-PIC, since you treat DL_LOADADDR_TYPE variables as pointers, defeating the point of abstracting away the type. The following patch makes it compile on Blackfin, but I'm unable to test this on a non-FDPIC system. Does it still work for you? Bernd Hi Bernd, the fix is fine for me too.. sorry I did not take care of the specificity of bfin. Please, go ahead and commit it. I'll update the nptl branch too. Ever since this patch was installed, i get: ldso/libdl/libdl.c: In function 'dladdr': ldso/libdl/libdl.c:746: warning: assignment makes pointer from integer without a cast To bypass this alleged bug, i suspect something like the paste below could be appropriate, but i'd prefer if somebody else would have a look and fix this. TIA.. Index: uClibc/ldso/libdl/libdl.c === --- uClibc/ldso/libdl/libdl.c (revision 21490) +++ uClibc/ldso/libdl/libdl.c (working copy) @@ -743,7 +743,7 @@ int dladdr(const void *__address, Dl_inf /* Set the info for the object the address lies in */ __info-dli_fname = pelf-libname; - __info-dli_fbase = pelf-mapaddr; + __info-dli_fbase = (void*)(pelf-mapaddr); symtab = (ElfW(Sym) *) (pelf-dynamic_info[DT_SYMTAB]); strtab = (char *) (pelf-dynamic_info[DT_STRTAB]); ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Omit OUTPUT_FORMAT in the libc.so linker script if none was provided
On Tue, Feb 05, 2008 at 03:06:34PM -0800, Chris Zankel wrote: Hi, I want to commit the following change, which is required for Xtensa. It doesn't affect architectures that do provide the OUTPUT_FORMAT(...) line in their linker script (as printed by 'gcc -Wl,--verbose') Just -OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 21 | sed -n 's/^OUTPUT_FORMAT(\([^]*\),.*/\1/p' +OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 21 | sed -n 's/^OUTPUT_FORMAT(\([^]*\),.*/OUTPUT_FORMAT ( \1 )/p' should do what you seem to want to achieve and is less bloated. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Status of uClibc NPTL and C++ on ARM
On Wed, Feb 06, 2008 at 03:34:01PM +0100, Bernhard Fischer wrote: kraj duplicated the INTERNAL_SYSCALL for arm (thumb vs. non-thumb?) for reasons that i do not really understand (r16334), so we have to fix this up twice now, but it sounds like it would be better to just ditch the duplicate. oh, and AFAICT this hunk can go in independently, too, guarded with a ndef __UCLIBC_HAS_THREADS__ for the old code that thrashes the unwinding (shouldn't be strictly needed if not using threads and saving those bits away sounds like it would cost several bytes per syscall which we can spare. Perhaps somebody who actually uses ARM would know if we should sacrifice some bytes for the non-threading case). ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Status of uClibc NPTL and C++ on ARM
On Wed, Feb 06, 2008 at 09:24:52AM +0100, Carmelo AMOROSO wrote: Ryan Ordway wrote: On Feb 5, 2008, at 11:40 AM, Steven J. Hill wrote: As I understand it, NPTL has been ported to uClibc and there is support for ARM, but it's currently living on a branch at http://uclibc.org/cgi-bin/viewcvs.cgi/branches/uClibc-nptl. Right? No, the ARM NPTL support is in patch form and has been posted to the list. MIPS and SuperH NPTL support are in the branch. I am finishing the merge and testing to then move both of those architectures to the trunk. After that, then the ARM support will be brought in. For now, if you want ARM NPTL support, go grab the patches. Steven, I've had some difficulties locating the latest patch(es). I've found some older versions of them, but have found references to newer versions that I cannot seem to locate. Would you, or someone else who has them, be able to either re-post them or post a URL where they can be found? Thanks, Ryan IIRC this is the last one http://www.codesourcery.com/public/uClibc-0.9.28-csl-nptl-9.patch.gz Yesterday evening i started to update this for current trunk (needs smallish adjustments in several places). We have to (resp i already did, locally) extend our mutex locking macros to deal nicely and transparently with futexes for stdio. The libgcc_s configury can be applied independently (i'll do this but don't have time to test it). kraj duplicated the INTERNAL_SYSCALL for arm (thumb vs. non-thumb?) for reasons that i do not really understand (r16334), so we have to fix this up twice now, but it sounds like it would be better to just ditch the duplicate. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/ldso: include ldso libdl
On Fri, Jan 18, 2008 at 05:14:20AM -0800, [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-01-18 05:14:19 -0800 (Fri, 18 Jan 2008) New Revision: 20871 Log: This patch solves a problem in dladdr caused by the wrong value of elf_resolve's loadaddr field for the main application. Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED] Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED] Modified: trunk/uClibc/ldso/include/dl-defs.h trunk/uClibc/ldso/include/dl-hash.h trunk/uClibc/ldso/ldso/dl-hash.c trunk/uClibc/ldso/ldso/ldso.c trunk/uClibc/ldso/libdl/libdl.c Sounds like this should be on the stable uClibc_0_9_29 branch too. Please apply. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/include/sys
On Tue, Jan 08, 2008 at 11:07:37PM -0800, [EMAIL PROTECTED] wrote: Author: vapier Date: 2008-01-08 23:07:37 -0800 (Tue, 08 Jan 2008) New Revision: 20834 Log: fetch queue.h from latest freebsd cvs Modified: trunk/uClibc/include/sys/queue.h Changeset: Modified: trunk/uClibc/include/sys/queue.h === --- trunk/uClibc/include/sys/queue.h 2008-01-09 06:59:58 UTC (rev 20833) +++ trunk/uClibc/include/sys/queue.h 2008-01-09 07:07:37 UTC (rev 20834) @@ -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. - * 3. Neither the name of the University nor the names of its contributors + * 4. Neither the name of the University nor the names of its contributors I may be wrong, but in such an enumeration, i'd expect 3 (and not 4) to come after 2 :P ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Wed, Dec 19, 2007 at 11:57:28AM -0500, Daniel Jacobowitz wrote: MontaVista noticed that when their kernels were configured to trap Since i just today stumbled across a python-frontend imposed funnyness WRT entries in /etc/hosts that read like: 1.1.1.1 $(seq -w 1 | tr \n ) (or rather 1.1.1.1 foo bar1 ... (-ULL-1)) which made everybody (nscd, python, etc) segfault in various funny ways, i mean to point folks to alleged issues with such candidates.. on unaligned access gethostbyname_r could mysteriously crash. I enjoy, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Fri, Dec 21, 2007 at 09:12:52PM +0100, Bernhard Fischer wrote: On Wed, Dec 19, 2007 at 11:57:28AM -0500, Daniel Jacobowitz wrote: MontaVista noticed that when their kernels were configured to trap on unaligned access gethostbyname_r could mysteriously crash. I tracked this down to an unaligned buffer being passed to gethostbyname_r from some other part of uClibc (afraid I don't remember where from any more). We have to pad the beginning of the buffer to a pointer alignment before we store pointers in it. Is this patch OK? -- Daniel Jacobowitz CodeSourcery --- libc/inet/resolv.c(revision 189757) +++ libc/inet/resolv.c(local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put +pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + if (buflen sizeof(char *)*(ALIAS_DIM)) return ERANGE; alias = (char **)buf; @@ -2030,6 +2039,16 @@ int gethostbyname_r(const char * name, DPRINTF(Nothing found in /etc/hosts\n); *h_errnop = NETDB_INTERNAL; + + /* Align to at least the size of a char * so we can put +pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + This sounds OK to me [provided you wrap that in som commonly useable whatever_range_check() for reuse -- i ment to type before sending. This pops up too often for inlining it.] . Please install it along a testcase if you tested it and found it to be good on all platforms in most common configurations with no regressions. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Wed, Dec 19, 2007 at 11:57:28AM -0500, Daniel Jacobowitz wrote: MontaVista noticed that when their kernels were configured to trap on unaligned access gethostbyname_r could mysteriously crash. I tracked this down to an unaligned buffer being passed to gethostbyname_r from some other part of uClibc (afraid I don't remember where from any more). We have to pad the beginning of the buffer to a pointer alignment before we store pointers in it. Is this patch OK? -- Daniel Jacobowitz CodeSourcery --- libc/inet/resolv.c (revision 189757) +++ libc/inet/resolv.c (local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + if (buflen sizeof(char *)*(ALIAS_DIM)) return ERANGE; alias = (char **)buf; @@ -2030,6 +2039,16 @@ int gethostbyname_r(const char * name, DPRINTF(Nothing found in /etc/hosts\n); *h_errnop = NETDB_INTERNAL; + + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + This sounds OK to me. Please install it along a testcase if you tested it and found it to be good on all platforms in most common configurations with no regressions. thanks.. if (buflen sizeof(*in)) return ERANGE; in = (struct in_addr*)buf; ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: error when building gcc using buildroot/toolchain
On Tue, Dec 11, 2007 at 02:11:42PM +0100, Michael Hunold wrote: Hello all, on 29.11.2007 11:14 Melvin Wu said the following: I'm using buildroot-20071128 and saw the same message. Could someone help me out? Thanks. Same problem here. It seems that Berhard's initial reply to the thread is somehow lost. I'm wondering if anybody knows what the problem is and how it can be fixed. /home/mwu/buildroot/toolchain_build_mips/gcc-4.2.1/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o /home/mwu/buildroot/toolchain_build_mips/gcc-4.2.1/gcc/crtstuff.c:1: error: unsupported combination: -mabicalls -mabi=eabi make[2]: *** [crtbegin.o] Error 1 make[2]: Leaving directory `/home/mwu/buildroot/toolchain_build_mips/gcc-4.2.1-initial/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/mwu/buildroot/toolchain_build_mips/gcc-4.2.1-initial' make: *** [/home/mwu/buildroot/toolchain_build_mips/gcc-4.2.1-initial/.compiled] Error Michael, please send me (in private if you prefer) your br2.config and your uClibc.config so i can try to reproduce this error here. Please note that this doesn't look like it's really uClibc related but a buildroot issue. thanks, ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Always inline system calls
On Tue, Dec 04, 2007 at 08:36:31AM +0100, Carmelo AMOROSO wrote:
Paul Mundt wrote:
On Mon, Dec 03, 2007 at 10:33:39PM +0100, Carmelo Amoroso wrote:
Carmelo Amoroso wrote:
while doing some test for SH4 to measure size increase for 'always inline'
changes,
doscovered suddenly that gcc-4.1.1 (cross sh4) fails with the following
error:
../ldso/ldso/dl-elf.c: In function '_dl_dprintf':
../ldso/ldso/dl-elf.c:858: error: unable to find a register to spill in
class 'R0_REGS'
../ldso/ldso/dl-elf.c:858: error: this is the insn:
(insn 916 917 24 1 (set (reg/f:SI 1 r1 [219])
(mem/u/c:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [220])) [0 S4 A32])) 172 {movsi_ie} (nil)
(expr_list:REG_DEAD (reg/f:SI 1 r1 [220])
(expr_list:REG_EQUIV (symbol_ref:SI (_dl_pagesize) var_decl
0x313a720 _dl_pagesize)
(nil
either running with -Os or -O0.
I'll test tomorrow with gcc-4.2.1 to see if it makes difference,
otherwise I suspect we should go back on my proposal in using always inline
only for arch strictly requiring it.
We've noticed this with some versions in buildroot also, so it seems to
be a more common issue:
Indeed at home I have gcc from buildroot. Tested just now at office
using gcc-4.2.1 from STMicro toolchain
and it works fine, either using -O0 or -Os.
I'll try to update buildroot at home with gcc 4.2.1 as well and see if
it solves.
I'll keep you informed.
Cheers,
Carmelo
CC ldso/ldso/ldso.oS
In file included from
./libpthread/linuxthreads.old/sysdeps/sh/tls.h:23,
from ./include/bits/uClibc_errno.h:35,
from ./include/errno.h:62,
from ./include/bits/syscalls.h:16,
from ./include/sys/syscall.h:34,
from ./ldso/ldso/sh/dl-syscalls.h:3,
from ./ldso/include/dl-syscall.h:12,
from ./ldso/include/ldso.h:36,
from ldso/ldso/ldso.c:33:
./libpthread/linuxthreads.old/sysdeps/sh/pt-machine.h:36: warning: C99
inline functions are not supported; using GNU89
./libpthread/linuxthreads.old/sysdeps/sh/pt-machine.h:36: warning: to
disable this warning use -fgnu89-inline or the gnu_inline function attribute
This needs fixing anyway. See the patch in my buildroot repo.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
