From rob at landley.net Fri Feb 1 22:08:04 2008 From: rob at landley.net (Rob Landley) Date: Sat, 2 Feb 2008 00:08:04 -0600 Subject: Has anybody gotten m68k to build in 0.9.29? Message-ID: <200802020008.05103.rob@landley.net> My attempts at building uClibc-0.9.29 for m68k keep triggering internal compiler errors. > CC libc/inet/inet_aton.os > CC libc/inet/inet_addr.os > CC libc/inet/inet_ntoa.os > libc/inet/addr.c: In function 'inet_ntoa_r': > libc/inet/addr.c:145: internal compiler error: in output_move_qimode, at > config/m68k/m68k.c:1899 Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make[1]: *** [libc/inet/inet_ntoa.os] Error 1 > make: *** [lib/libc.so.0] Error 2 I tried upgrading from gcc 4.1.2 to 4.2.2, and it made no difference. The .config file is attached. Does it work for anybody else? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -------------- next part -------------- # # Automatically generated make config: don't edit # uClibc version: KCONFIG_VERSION # Fri Feb 1 22:30:37 2008 # # TARGET_alpha is not set # TARGET_arm 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 is not set # TARGET_i960 is not set # TARGET_ia64 is not set TARGET_m68k=y # 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 Architecture Features and Options # TARGET_ARCH="m68k" FORCE_OPTIONS_FOR_ARCH=y ARCH_CFLAGS="-Wa,--bitwise-or" TARGET_SUBARCH="" # UCLIBC_FORMAT_ELF is not set UCLIBC_FORMAT_FDPIC_ELF=y # UCLIBC_FORMAT_FLAT is not set # UCLIBC_FORMAT_FLAT_SEP_DATA is not set # UCLIBC_FORMAT_SHARED_FLAT is not set ARCH_BIG_ENDIAN=y # # Using Big Endian # # ARCH_HAS_MMU is not set UCLIBC_HAS_FLOATS=y UCLIBC_HAS_FPU=y # DO_C99_MATH is not set KERNEL_HEADERS="/usr/include" UCLIBC_UCLINUX_BROKEN_MUNMAP=y EXCLUDE_BRK=y HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set DOPIC=y # HAVE_NO_SHARED is not set # ARCH_HAS_NO_LDSO is not set HAVE_SHARED=y # FORCE_SHAREABLE_TEXT_SEGMENTS is not set LDSO_LDD_SUPPORT=y LDSO_CACHE_SUPPORT=y # LDSO_PRELOAD_FILE_SUPPORT is not set LDSO_BASE_FILENAME="ld.so" UCLIBC_STATIC_LDCONFIG=y LDSO_RUNPATH=y UCLIBC_CTOR_DTOR=y # HAS_NO_THREADS is not set UCLIBC_HAS_THREADS=y # PTHREADS_DEBUG_SUPPORT is not set LINUXTHREADS_OLD=y UCLIBC_HAS_LFS=y MALLOC=y # MALLOC_SIMPLE is not set # MALLOC_STANDARD is not set MALLOC_GLIBC_COMPAT=y UCLIBC_DYNAMIC_ATEXIT=y # COMPAT_ATEXIT is not set UCLIBC_SUSV3_LEGACY=y # UCLIBC_SUSV3_LEGACY_MACROS is not set UCLIBC_HAS_SHADOW=y # UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set UCLIBC_HAS___PROGNAME=y UNIX98PTY_ONLY=y ASSUME_DEVPTS=y UCLIBC_HAS_TM_EXTENSIONS=y UCLIBC_HAS_TZ_CACHING=y UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH="/etc/TZ" # # Advanced Library Settings # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 # # Networking Support # # UCLIBC_HAS_IPV6 is not set UCLIBC_HAS_RPC=y # UCLIBC_HAS_FULL_RPC is not set # UCLIBC_HAS_REENTRANT_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=y # UCLIBC_HAS_CTYPE_CHECKED is not set # UCLIBC_HAS_CTYPE_ENFORCED is not set # UCLIBC_HAS_WCHAR is not set # UCLIBC_HAS_LOCALE is not set # UCLIBC_HAS_HEXADECIMAL_FLOATS is not set # UCLIBC_HAS_GLIBC_CUSTOM_PRINTF is not set # USE_OLD_VFPRINTF is not set UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 # UCLIBC_HAS_SCANF_GLIBC_A_FLAG is not set # 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 UCLIBC_HAS_STDIO_GETC_MACRO=y UCLIBC_HAS_STDIO_PUTC_MACRO=y UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y # UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set # UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE is not set # UCLIBC_HAS_GLIBC_CUSTOM_STREAMS is not set # UCLIBC_HAS_PRINTF_M_SPEC is not set UCLIBC_HAS_ERRNO_MESSAGES=y # UCLIBC_HAS_SYS_ERRLIST is not set UCLIBC_HAS_SIGNUM_MESSAGES=y # UCLIBC_HAS_SYS_SIGLIST is not set UCLIBC_HAS_GNU_GETOPT=y UCLIBC_HAS_GNU_GETSUBOPT=y # # Big and Tall # UCLIBC_HAS_REGEX=y UCLIBC_HAS_REGEX_OLD=y UCLIBC_HAS_FNMATCH=y UCLIBC_HAS_FNMATCH_OLD=y # UCLIBC_HAS_WORDEXP is not set # UCLIBC_HAS_FTW is not set UCLIBC_HAS_GLOB=y UCLIBC_HAS_GNU_GLOB=y # # Library Installation Options # SHARED_LIB_LOADER_PREFIX="$(RUNTIME_PREFIX)lib" RUNTIME_PREFIX="/usr/$(TARGET_ARCH)-linux-uclibc/" DEVEL_PREFIX="/usr/$(TARGET_ARCH)-linux-uclibc/usr/" # # Security options # # UCLIBC_HAS_ARC4RANDOM is not set # HAVE_NO_SSP is not set # UCLIBC_HAS_SSP is not set UCLIBC_BUILD_RELRO=y # UCLIBC_BUILD_NOW is not set UCLIBC_BUILD_NOEXECSTACK=y # # uClibc development/debugging options # CROSS_COMPILER_PREFIX="" UCLIBC_EXTRA_CFLAGS="" # DODEBUG is not set # DODEBUG_PT is not set DOSTRIP=y # DOASSERTS is not set # SUPPORT_LD_DEBUG is not set # SUPPORT_LD_DEBUG_EARLY is not set # UCLIBC_MALLOC_DEBUGGING is not set WARNINGS="-Wall" # EXTRA_WARNINGS is not set # DOMULTI is not set # UCLIBC_MJN3_ONLY is not set From ddaney at avtrex.com Mon Feb 4 09:14:02 2008 From: ddaney at avtrex.com (David Daney) Date: Mon, 04 Feb 2008 09:14:02 -0800 Subject: Has anybody gotten m68k to build in 0.9.29? In-Reply-To: <200802020008.05103.rob@landley.net> References: <200802020008.05103.rob@landley.net> Message-ID: <47A747DA.1070704@avtrex.com> Rob Landley wrote: > My attempts at building uClibc-0.9.29 for m68k keep triggering internal > compiler errors. > > >> CC libc/inet/inet_aton.os >> CC libc/inet/inet_addr.os >> CC libc/inet/inet_ntoa.os >> libc/inet/addr.c: In function 'inet_ntoa_r': >> libc/inet/addr.c:145: internal compiler error: in output_move_qimode, at >> config/m68k/m68k.c:1899 Please submit a full bug report, >> with preprocessed source if appropriate. >> See for instructions. >> make[1]: *** [libc/inet/inet_ntoa.os] Error 1 >> make: *** [lib/libc.so.0] Error 2 >> > > I tried upgrading from gcc 4.1.2 to 4.2.2, and it made no difference. > Searching the GCC's bugzilla for 68k internal compiler errors yields nothing for output_move_qimode. Please open a new bug report at the indicated URL. You could also try with the current SVN trunk, as it is very close to being released as GCC 4.3. It could be that it works there. Thanks, David Daney From will.newton at gmail.com Tue Feb 5 09:39:27 2008 From: will.newton at gmail.com (Will Newton) Date: Tue, 5 Feb 2008 17:39:27 +0000 Subject: Conflict between libc-symbols.h and sys/sysctl.h Message-ID: <87a5b0800802050939x272be1edvd8c5e6a875a55ae0@mail.gmail.com> Hi all, I'm seeing what looks like a conflict between libc-symbols.h and sys/sysctl.h in a recent snapshot of uClibc (paired with 2.6.24 kernel headers). libc-symbol.h has this: #ifndef __LINUX_COMPILER_H # define __LINUX_COMPILER_H #endif and sys/sysctl.h has this: #ifndef __LINUX_COMPILER_H # define __LINUX_COMPILER_H 1 # define __user # define __undef__LINUX_COMPILER_H #endif Because libc-symbols.h has already defined __LINUX_COMPILER_H an empty definition of __user is never made here so compiling anything that includes the sys/sysctl.h header fails due to the use of the __user annotation in linux/sysctl.h. Or am I missing something? Thanks, From spam_from_uclibc at chezphil.org Tue Feb 5 09:45:24 2008 From: spam_from_uclibc at chezphil.org (Phil Endecott) Date: Tue, 05 Feb 2008 17:45:24 +0000 Subject: Status of uClibc NPTL and C++ on ARM Message-ID: <1202233524325@dmwebmail.dmwebmail.chezphil.org> Dear Experts, I'm trying to understand the status of uClibc's NPTL port on ARM and how it will function with C++. 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? In general, POSIX thread cancellation does not work well with C++ as destructors are not called during cancellation. In glibc+NPTL, however, destructors are called (though code in catch blocks might not be?) as the cancellation handler unwinds the stack. Can anyone confirm whether this feature has or hasn't been included in the uClibc port of NPTL? Has anyone tested it? I guess that there may be some architecture-specific stuff in the stack unwinding, so maybe I also need to add "...for ARM" to the question. Many thanks for any advice. I'm trying to find answers in the source, but I'm a bit lost at the moment. Is there any documentation that I should refer to? Regards, Phil. From sjhill at realitydiluted.com Tue Feb 5 11:40:52 2008 From: sjhill at realitydiluted.com (Steven J. Hill) Date: Tue, 5 Feb 2008 13:40:52 -0600 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <1202233524325@dmwebmail.dmwebmail.chezphil.org> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> Message-ID: <20080205194052.GA12606@real.realitydiluted.com> > 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. > In general, POSIX thread cancellation does not work well with C++ as > destructors are not called during cancellation. In glibc+NPTL, > however, destructors are called (though code in catch blocks might not > be?) as the cancellation handler unwinds the stack. Can anyone confirm > whether this feature has or hasn't been included in the uClibc port of > NPTL? Has anyone tested it? I guess that there may be some > architecture-specific stuff in the stack unwinding, so maybe I also > need to add "...for ARM" to the question. > I know how to spell 'C' '+' '+' and that's about it. Someone else can answer your question on that. -Steve From rordway at oregonstate.edu Tue Feb 5 14:39:26 2008 From: rordway at oregonstate.edu (Ryan Ordway) Date: Tue, 5 Feb 2008 14:39:26 -0800 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <20080205194052.GA12606@real.realitydiluted.com> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> Message-ID: 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 -- Ryan Ordway E-mail: rordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 From chris at zankel.net Tue Feb 5 15:06:34 2008 From: chris at zankel.net (Chris Zankel) Date: Tue, 05 Feb 2008 15:06:34 -0800 Subject: Omit OUTPUT_FORMAT in the libc.so linker script if none was provided Message-ID: <47A8EBFA.7090907@zankel.net> 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') Thanks, -Chris -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uClibc.005-xtensa-fix-output-format.patch Url: http://busybox.net/lists/uclibc/attachments/20080205/3e32210a/attachment.diff From rob at landley.net Tue Feb 5 16:34:04 2008 From: rob at landley.net (Rob Landley) Date: Tue, 5 Feb 2008 18:34:04 -0600 Subject: Has anybody gotten m68k to build in 0.9.29? In-Reply-To: <47A747DA.1070704@avtrex.com> References: <200802020008.05103.rob@landley.net> <47A747DA.1070704@avtrex.com> Message-ID: <200802051834.05274.rob@landley.net> On Monday 04 February 2008 11:14:02 David Daney wrote: > Rob Landley wrote: > > My attempts at building uClibc-0.9.29 for m68k keep triggering internal > > compiler errors. > > > >> CC libc/inet/inet_aton.os > >> CC libc/inet/inet_addr.os > >> CC libc/inet/inet_ntoa.os > >> libc/inet/addr.c: In function 'inet_ntoa_r': > >> libc/inet/addr.c:145: internal compiler error: in output_move_qimode, at > >> config/m68k/m68k.c:1899 Please submit a full bug report, > >> with preprocessed source if appropriate. > >> See for instructions. > >> make[1]: *** [libc/inet/inet_ntoa.os] Error 1 > >> make: *** [lib/libc.so.0] Error 2 > > > > I tried upgrading from gcc 4.1.2 to 4.2.2, and it made no difference. > > Searching the GCC's bugzilla for 68k internal compiler errors yields > nothing for output_move_qimode. So that would be a "no", then. > Please open a new bug report at the indicated URL. To reproduce the bug: wget http://landley.net/hg/firmware/archive/tip.tar.bz2 tar xvjf tip.tar.bz2 cd firmware-* [ add the attached patch to sources/patches ] ./build.sh m68k That's pretty much all I know about it at the moment. That and moving from 4.1.2->4.2.2 didn't fix it. :( > You could also try with the current SVN trunk, as it is very close to > being released as GCC 4.3. It could be that it works there. Alas, upgrading to gcc 4.2 broke arm soft float. (Ok, it was broken in gcc 4.1 too, but I had a patch to fix it there, and adapting it to gcc 4.2 didn't work. They let M.C. Escher have another go at the makefiles...) I plan to upgrade someday, but for right now I've got higher priority todo items and reverted the upgrade until I get some other things cleared. The problem is that gcc the gcc developers moved the soft float functions in libgcc_s.so, and if you build the compiler with --disable-shared they have to move back to libgcc.a. You have to patch gcc to accomplish this, and the build changed enough between 4.1 and 4.2 that a straightforward adaptation of the patch doesn't work. (I'm working on it, but since gcc 4.2 has no obvious advantages over 4.1 so far, it's low priority.) That said, I can try to take a whack at SVN for diagnostic purposes. Maybe later this evening. (I just can't _deploy_ it in the short term. And if it _does_ fix it, maybe I can binary search for the fix. But if 4.2 didn't, and there's nothing in the bug tracker, I kind of doubt it was specifically addressed...) > Thanks, > David Daney Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -------------- next part -------------- A non-text attachment was scrubbed... Name: uClibc-fixnommu.patch Type: text/x-diff Size: 457 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080205/adbcb9b5/attachment.bin From ddaney at avtrex.com Tue Feb 5 16:51:00 2008 From: ddaney at avtrex.com (David Daney) Date: Tue, 05 Feb 2008 16:51:00 -0800 Subject: Has anybody gotten m68k to build in 0.9.29? In-Reply-To: <200802051834.05274.rob@landley.net> References: <200802020008.05103.rob@landley.net> <47A747DA.1070704@avtrex.com> <200802051834.05274.rob@landley.net> Message-ID: <47A90474.4020607@avtrex.com> Rob Landley wrote: > On Monday 04 February 2008 11:14:02 David Daney wrote: >> Rob Landley wrote: >>> My attempts at building uClibc-0.9.29 for m68k keep triggering internal >>> compiler errors. >>> >>>> CC libc/inet/inet_aton.os >>>> CC libc/inet/inet_addr.os >>>> CC libc/inet/inet_ntoa.os >>>> libc/inet/addr.c: In function 'inet_ntoa_r': >>>> libc/inet/addr.c:145: internal compiler error: in output_move_qimode, at >>>> config/m68k/m68k.c:1899 Please submit a full bug report, >>>> with preprocessed source if appropriate. >>>> See for instructions. >>>> make[1]: *** [libc/inet/inet_ntoa.os] Error 1 >>>> make: *** [lib/libc.so.0] Error 2 >>> I tried upgrading from gcc 4.1.2 to 4.2.2, and it made no difference. >> Searching the GCC's bugzilla for 68k internal compiler errors yields >> nothing for output_move_qimode. > > So that would be a "no", then. > >> Please open a new bug report at the indicated URL. > > To reproduce the bug: > . . . I don't do 68k, so I'm not going to fix it. As you probably know, the drill is to file a bug report with the preprocessed test case. Posting only to uclibc at uclibc.org without a bug report to http://gcc.gnu.org/bugs.html, decreases the chances of it being fixed. David Daney From rob at landley.net Tue Feb 5 17:13:31 2008 From: rob at landley.net (Rob Landley) Date: Tue, 5 Feb 2008 19:13:31 -0600 Subject: Has anybody gotten m68k to build in 0.9.29? In-Reply-To: <47A90474.4020607@avtrex.com> References: <200802020008.05103.rob@landley.net> <200802051834.05274.rob@landley.net> <47A90474.4020607@avtrex.com> Message-ID: <200802051913.31540.rob@landley.net> On Tuesday 05 February 2008 18:51:00 David Daney wrote: > I don't do 68k, so I'm not going to fix it. Didn't expect you to. > As you probably know, the drill is to file a bug report with the > preprocessed test case. > > Posting only to uclibc at uclibc.org without a bug report to > http://gcc.gnu.org/bugs.html, decreases the chances of it being fixed. I was actually looking for a workaround that didn't trigger it (config change?), on the theory that m68k presumably had to work for somebody at some point... > David Daney Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. From carmelo.amoroso at st.com Wed Feb 6 00:24:52 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 06 Feb 2008 09:24:52 +0100 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> Message-ID: <47A96ED4.3050704@st.com> 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 Carmelo > -- > Ryan Ordway E-mail: rordway at oregonstate.edu > Unix Systems Administrator rordway at library.oregonstate.edu > OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 > > > > > > > > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From rep.dot.nop at gmail.com Wed Feb 6 03:18:11 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 6 Feb 2008 12:18:11 +0100 Subject: Omit OUTPUT_FORMAT in the libc.so linker script if none was provided In-Reply-To: <47A8EBFA.7090907@zankel.net> References: <47A8EBFA.7090907@zankel.net> Message-ID: <20080206111811.GB18599@aon.at> 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 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p' +OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/OUTPUT_FORMAT ( \1 )/p' should do what you seem to want to achieve and is less bloated. From rep.dot.nop at gmail.com Wed Feb 6 06:34:01 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 6 Feb 2008 15:34:01 +0100 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <47A96ED4.3050704@st.com> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> <47A96ED4.3050704@st.com> Message-ID: <20080206143400.GA28779@aon.at> 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. From rep.dot.nop at gmail.com Wed Feb 6 06:49:59 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 6 Feb 2008 15:49:59 +0100 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <20080206143400.GA28779@aon.at> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> <47A96ED4.3050704@st.com> <20080206143400.GA28779@aon.at> Message-ID: <20080206144959.GB28779@aon.at> 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). From carmelo.amoroso at st.com Wed Feb 6 07:30:24 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 06 Feb 2008 16:30:24 +0100 Subject: Conflict between libc-symbols.h and sys/sysctl.h In-Reply-To: <87a5b0800802050939x272be1edvd8c5e6a875a55ae0@mail.gmail.com> References: <87a5b0800802050939x272be1edvd8c5e6a875a55ae0@mail.gmail.com> Message-ID: <47A9D290.3020006@st.com> Will Newton wrote: > Hi all, > > I'm seeing what looks like a conflict between libc-symbols.h and > sys/sysctl.h in a recent snapshot of uClibc (paired with 2.6.24 kernel > headers). > > libc-symbol.h has this: > > #ifndef __LINUX_COMPILER_H > # define __LINUX_COMPILER_H > #endif > > and sys/sysctl.h has this: > > #ifndef __LINUX_COMPILER_H > # define __LINUX_COMPILER_H 1 > # define __user > # define __undef__LINUX_COMPILER_H > #endif > > Because libc-symbols.h has already defined __LINUX_COMPILER_H an empty > definition of __user is never made here so compiling anything that > includes the sys/sysctl.h header fails due to the use of the __user > annotation in linux/sysctl.h. Or am I missing something? > > Thanks, > where are you taking kernel-headers from ? I'm using sanitized kernel headers (produce directly from kernel build system by make headers_install) and the is no occurrence of __user into linux/sysctl.h... I think you are using kernel-space headers. Carmelo > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From will.newton at gmail.com Wed Feb 6 07:34:00 2008 From: will.newton at gmail.com (Will Newton) Date: Wed, 6 Feb 2008 15:34:00 +0000 Subject: Conflict between libc-symbols.h and sys/sysctl.h In-Reply-To: <47A9D290.3020006@st.com> References: <87a5b0800802050939x272be1edvd8c5e6a875a55ae0@mail.gmail.com> <47A9D290.3020006@st.com> Message-ID: <87a5b0800802060734v3bc95c27lafe3032da5f83903@mail.gmail.com> On Feb 6, 2008 3:30 PM, Carmelo AMOROSO wrote: > where are you taking kernel-headers from ? > I'm using sanitized kernel headers (produce directly from kernel build > system by make headers_install) > and the is no occurrence of __user into linux/sysctl.h... I think you > are using kernel-space headers. Ah, yes, that's it. I quite often point my kernel headers config option at my kernel source tree, which worked quite well with 2.4 kernels but won't with 2.6. Thanks for your help! From rep.dot.nop at gmail.com Wed Feb 6 10:02:30 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 6 Feb 2008 19:02:30 +0100 Subject: LDSO_GNU_HASH_SUPPORT breaks cross-compilation In-Reply-To: <20071107203320.GC6510@aon.at> References: <20071107151451.8B025A65AA@busybox.net> <200711071955.35530.vda.linux@googlemail.com> <20071107203320.GC6510@aon.at> Message-ID: <20080206180230.GA3416@aon.at> On Wed, Nov 07, 2007 at 09:33:21PM +0100, Bernhard Fischer wrote: >On Wed, Nov 07, 2007 at 07:55:35PM +0000, Denys Vlasenko wrote: >>On Wednesday 07 November 2007 15:14, carmelo at uclibc.org wrote: >>> +config LDSO_GNU_HASH_SUPPORT >>> + bool "Enable GNU hash style support" >>> + depends on HAVE_SHARED >>> + default n >>> + help >>> + Newest binutils support a new hash style named GNU-hash. The dynamic >>> + linker will use the new GNU-hash section (.gnu.hash) for symbol lookup >>> + if present into the ELF binaries, otherwise it will use the old SysV >>> + hash style (.hash). This ensures that it is completely backward compatible. >>> + Further, being the hash table implementation self-contained into each >>> + executable and shared libraries, objects with mixed hash style can >>> + peacefully coexist in the same process. >>> + >>> + If you want to use this new feature, answer Y >>> + >> >>If I would read this help text, I'd wonder whether this >>new GNU style hash is actually better than old way, and why. >>Is it smaller? faster? or what... > >One very visible effect introduced by it is that cross-compilation is >broken now. Unpleasant. > >Reverting locally. Hi Carmelo, Do you intend to fix this anytime soon? Your check if ld supports --hash-style=gnu is not working (since i'm about to configure or install_dev and don't have a proper cross-ld yet): make[1]: Entering directory `/there/toolchain_build_arm_nofpu/uClibc' install -d include/bits /usr/bin/make -j1 -C extra/config conf /bin/sh: /there/build_arm_nofpu/staging_dir/usr/bin/arm-linux-uclibcgnueabi-gcc: No such file or directory ./../Rules.mak:465: *** Your binutils don't support --hash-style option, while you want to use it. Stop. make[1]: *** [extra/config/conf] Error 2 Same for e.g. install_dev. From rordway at oregonstate.edu Wed Feb 6 10:39:13 2008 From: rordway at oregonstate.edu (Ryan Ordway) Date: Wed, 6 Feb 2008 10:39:13 -0800 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <20080206143400.GA28779@aon.at> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> <47A96ED4.3050704@st.com> <20080206143400.GA28779@aon.at> Message-ID: <25BCEA59-595E-4BEC-9A13-CFEC69A4A942@oregonstate.edu> On Feb 6, 2008, at 6:34 AM, Bernhard Fischer wrote: > 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. > > Anything I can do to help? :-) -- Ryan Ordway E-mail: rordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 From carmelo.amoroso at st.com Wed Feb 6 10:56:38 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 06 Feb 2008 19:56:38 +0100 Subject: LDSO_GNU_HASH_SUPPORT breaks cross-compilation In-Reply-To: <20080206180230.GA3416@aon.at> References: <20071107151451.8B025A65AA@busybox.net> <200711071955.35530.vda.linux@googlemail.com> <20071107203320.GC6510@aon.at> <20080206180230.GA3416@aon.at> Message-ID: <47AA02E6.1030709@st.com> Bernhard Fischer wrote: > On Wed, Nov 07, 2007 at 09:33:21PM +0100, Bernhard Fischer wrote: > >> On Wed, Nov 07, 2007 at 07:55:35PM +0000, Denys Vlasenko wrote: >> >>> On Wednesday 07 November 2007 15:14, carmelo at uclibc.org wrote: >>> >>>> +config LDSO_GNU_HASH_SUPPORT >>>> + bool "Enable GNU hash style support" >>>> + depends on HAVE_SHARED >>>> + default n >>>> + help >>>> + Newest binutils support a new hash style named GNU-hash. The dynamic >>>> + linker will use the new GNU-hash section (.gnu.hash) for symbol lookup >>>> + if present into the ELF binaries, otherwise it will use the old SysV >>>> + hash style (.hash). This ensures that it is completely backward compatible. >>>> + Further, being the hash table implementation self-contained into each >>>> + executable and shared libraries, objects with mixed hash style can >>>> + peacefully coexist in the same process. >>>> + >>>> + If you want to use this new feature, answer Y >>>> + >>>> >>> If I would read this help text, I'd wonder whether this >>> new GNU style hash is actually better than old way, and why. >>> Is it smaller? faster? or what... >>> >> One very visible effect introduced by it is that cross-compilation is >> broken now. Unpleasant. >> >> Reverting locally. >> > > Hi Carmelo, > > Do you intend to fix this anytime soon? > > Your check if ld supports --hash-style=gnu is not working (since i'm > about to configure or install_dev and don't have a proper cross-ld yet): > cross ld (as well as all binutils) can be built without relying on uclibc at all. anyway.... > make[1]: Entering directory > `/there/toolchain_build_arm_nofpu/uClibc' > install -d include/bits > /usr/bin/make -j1 -C extra/config conf > this step use host gcc.. and my x86 ld doesn't support --hash-style but this is not a problem at this stage. > /bin/sh: > /there/build_arm_nofpu/staging_dir/usr/bin/arm-linux-uclibcgnueabi-gcc: No such file or directory > ./../Rules.mak:465: *** Your binutils don't support --hash-style option, while you want to use it. Stop. > make[1]: *** [extra/config/conf] Error 2 > > The --hash-style is passed to $(LD) that should be your cross ld ( if correctly defined CROSS or CROSS_COMPILER_PREFIX... but I'm sure you perfectly know this) and not to host ld. I don't see anything wrong... but if you have a better idea... or a better explanation, please advice. I don't use buildroot. Carmelo > Same for e.g. install_dev. > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From rep.dot.nop at gmail.com Wed Feb 6 11:31:50 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 6 Feb 2008 20:31:50 +0100 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <25BCEA59-595E-4BEC-9A13-CFEC69A4A942@oregonstate.edu> References: <1202233524325@dmwebmail.dmwebmail.chezphil.org> <20080205194052.GA12606@real.realitydiluted.com> <47A96ED4.3050704@st.com> <20080206143400.GA28779@aon.at> <25BCEA59-595E-4BEC-9A13-CFEC69A4A942@oregonstate.edu> Message-ID: <20080206193150.GA6905@aon.at> On Wed, Feb 06, 2008 at 10:39:13AM -0800, Ryan Ordway 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. > > Anything I can do to help? :-) yes, you could look through the ifdefs in libc/sysdeps/linux/arm/bits/syscalls.h and figure out which combo to use so all needed parts can use the same INTERNAL_SYSCALL definition (I'm talking about the one with this string): "\tswi 0 @ syscall " #name "\n" From spam_from_uclibc at chezphil.org Wed Feb 6 14:54:16 2008 From: spam_from_uclibc at chezphil.org (Phil Endecott) Date: Wed, 06 Feb 2008 22:54:16 +0000 Subject: Status of uClibc NPTL and C++ on ARM In-Reply-To: <20080206143400.GA28779@aon.at> References: <20080206143400.GA28779@aon.at> Message-ID: <1202338456993@dmwebmail.dmwebmail.chezphil.org> Bernhard Fischer wrote: > 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. >>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). Thanks for the feedback everyone, this is exactly what I needed to know. Regarding the C++ stack unwinding on thread cancellation, my guess is that since you've brought over the glibc code unchanged, and since no-one has said "oh we had to disable all of that to make it work here", there's a good chance that it will just work. I'll let you know how I get on. Cheers, Phil. From carmelo.amoroso at st.com Wed Feb 6 23:10:49 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 07 Feb 2008 08:10:49 +0100 Subject: [PATCH] wprintf overflow In-Reply-To: References: Message-ID: <47AAAEF9.2090905@st.com> Kevin Cernekee wrote: > Hi, > > I am seeing a buffer overflow in uClibc-0.9.28 on mipsel, illustrated by > the following test program: > > > #include > #include > > int main(int argc, char **argv) > { > wprintf(L"This line is OK\n"); > wprintf(L"This line is no problem either because the format spec > is at the end: %d\n", 1); > wprintf(L"%d: This line will segfault because the format spec is > too far from the end\n", 1); > return(0); > } > > > In uClibc/libc/stdio/vfprintf.c or _vfprintf.c, function > _ppfs_parsespec(), there is a loop that copies the const wchar_t format > specifier into a char buffer so that it can be parsed using the same code. > However, this loop terminates at the end of the string, rather than the > end of the format spec, causing a buffer overflow for strings in which the > format specifier begins more than 32 characters from the end of the > string. > Hello, you analysis is correct... > I don't see any evidence that this has been fixed in the SVN sources, but > admittedly I have not tried building/running them either. > > My workaround is attached. A better solution might be to figure out when > the format spec ends, and stop copying at that point. yes, but I'd prefer to keep the code simpler as is, and copying the at maximum 32 bytes. > This would allow us > to reinstate the "char != wchar_t" check that errors out if the user puts > a high character in the format spec. Another option would be to just > store a NUL byte and quit copying if a high character is encountered, > letting the format spec parser sort out any issues. Something like: > The fix I committed I think it's better... because solve the stack overflow but keep the check against higher character. I tested it and it works. Let me know your comments. --- trunk/uClibc/libc/stdio/ _vfprintf.c 2008-02-07 00:53:36 UTC (rev 20951) +++ trunk/uClibc/libc/stdio/_vfprintf.c 2008-02-07 07:06:49 UTC (rev 20952) @@ -898,7 +898,7 @@ ) { return -1; } - } while (buf[i++]); + } while (buf[i++] && (i < sizeof(buf))); buf[sizeof(buf)-1] = 0; } #else /* __UCLIBC_HAS_WCHAR__ */ Cheers, Carmelo > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From filippo.arcidiacono at st.com Thu Feb 7 08:29:32 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Thu, 7 Feb 2008 17:29:32 +0100 Subject: [ping] [patch] getaddrinfo bug In-Reply-To: <200801301954.m0UJsD7e025679@sallyv1.ics.uci.edu> Message-ID: <003901c869a6$9ed7f5a0$838182a4@st.com> > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Dan Nicolaescu > Sent: Wednesday, January 30, 2008 8:54 PM > To: uclibc at uclibc.org > Subject: [ping] [patch] getaddrinfo bug > > 2 weeks ago I sent this patch. There was no feedback on it. > > Can someone please take a look and comment on this patch? > > Thanks > --dan > > > > When using x11r7, starting X11 application ends up calling > _xcb_open_tcp in libxcb. > > _xcb_open_tcp looks like this: > > static int _xcb_open_tcp(char *host, const unsigned short port) { > int fd = -1; > struct addrinfo hints = { AI_ADDRCONFIG #ifdef AI_NUMERICSERV > | AI_NUMERICSERV #endif > , AF_UNSPEC, SOCK_STREAM }; [snip] > res = getaddrinfo(host, service, &hints, &results); > > > uclibc's netdb.h always defines AI_NUMERICSERV, so > AI_NUMERICSERV is always used. > > The getaddrinfo implementation in uclibc does: > > if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| > AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) > return EAI_BADFLAGS; > > which means that getaddrinfo will always fail and return > EAI_BADFLAGS because it passes AI_NUMERICSERV. > > As a result, X11 applications won't start. > > This patch fixes the problem: > > --- getaddrinfo.c.orig 2008-01-15 07:36:08.264317000 -0800 > +++ getaddrinfo.c 2008-01-15 07:36:00.518071000 -0800 > @@ -822,7 +822,7 @@ > if (hints == NULL) > hints = &default_hints; > > - if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| > + if (hints->ai_flags & > + ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_NUMERICSERV| > AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) > return EAI_BADFLAGS; In my opinion you have to check if the string is not just a number with AI_NUMERICSERV flag high. See the patch below. For more detail see glibc patch http://sourceware.org/ml/glibc-cvs/2004-q3/msg00296.html Based on the following bug http://sources.redhat.com/bugzilla/show_bug.cgi?id=296 Regards Filippo Arcidiacono. --- uClibc-nptl/libc/inet/getaddrinfo.c (revision 16) +++ uClibc-nptl/libc/inet/getaddrinfo.c (working copy) @@ -823,7 +823,7 @@ hints = &default_hints; if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| - AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) + AI_ADDRCONFIG|AI_V4MAPPED|AI_NUMERICSERV|AI_ALL)) return EAI_BADFLAGS; if ((hints->ai_flags & AI_CANONNAME) && name == NULL) @@ -834,8 +834,12 @@ char *c; gaih_service.name = service; gaih_service.num = strtoul (gaih_service.name, &c, 10); - if (*c) + if (*c != '\0') { + if (hints->ai_flags & AI_NUMERICSERV) + return EAI_NONAME; + gaih_service.num = -1; + } else /* * Can't specify a numerical socket unless a protocol > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From bernds_cb1 at t-online.de Thu Feb 7 13:38:14 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 07 Feb 2008 22:38:14 +0100 Subject: [PATCH] Fix dladdr return value when cannot find symbol In-Reply-To: <4784ECCF.9080200@st.com> References: <12b5f1ef0711292147x5e74be2dn41bcb8b9c3d567ba@mail.gmail.com> <475D57A0.1050507@st.com> <47603EC4.6080609@st.com> <200801051910.29409.vapier@gentoo.org> <4784ECCF.9080200@st.com> Message-ID: <47AB7A46.4070208@t-online.de> 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 -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -------------- next part -------------- A non-text attachment was scrubbed... Name: mapaddr.diff Type: text/x-patch Size: 4087 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080207/4d6cb0f8/attachment.bin From bernds_cb1 at t-online.de Thu Feb 7 13:40:57 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Thu, 07 Feb 2008 22:40:57 +0100 Subject: fork on nommu Message-ID: <47AB7AE9.7080106@t-online.de> A number of programs, such as busybox, contain calls to fork which may not necessarily get executed at runtime. On nommu systems, this currently produces link errors since the function doesn't exist. In our Blackfin tree, we use the following patch (by Mike IIRC) to convert the link error into a warning. Any objections to installing this? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -------------- next part -------------- A non-text attachment was scrubbed... Name: fork.diff Type: text/x-patch Size: 1215 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080207/156d75d8/attachment.bin From drow at false.org Thu Feb 7 13:56:20 2008 From: drow at false.org (Daniel Jacobowitz) Date: Thu, 7 Feb 2008 16:56:20 -0500 Subject: fork on nommu In-Reply-To: <47AB7AE9.7080106@t-online.de> References: <47AB7AE9.7080106@t-online.de> Message-ID: <20080207215620.GA27684@caradoc.them.org> On Thu, Feb 07, 2008 at 10:40:57PM +0100, Bernd Schmidt wrote: > A number of programs, such as busybox, contain calls to fork which may > not necessarily get executed at runtime. On nommu systems, this > currently produces link errors since the function doesn't exist. > > In our Blackfin tree, we use the following patch (by Mike IIRC) to > convert the link error into a warning. Any objections to installing this? FWIW, I think the link error is more useful than a stub version. Most programs don't handle fork failure gracefully. -- Daniel Jacobowitz CodeSourcery From chris at zankel.net Thu Feb 7 13:58:09 2008 From: chris at zankel.net (Chris Zankel) Date: Thu, 07 Feb 2008 13:58:09 -0800 Subject: Omit OUTPUT_FORMAT in the libc.so linker script if none was provided In-Reply-To: <20080206111811.GB18599@aon.at> References: <47A8EBFA.7090907@zankel.net> <20080206111811.GB18599@aon.at> Message-ID: <47AB7EF1.70500@zankel.net> Hi Bernhard, Thanks for you comment. That's certainly a much cleaner way. I modified the patch and intend to commit it over the weekend. I've tested in on Xtensa and i386. Thanks, -Chris Bernhard Fischer wrote: > 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 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p' > +OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/OUTPUT_FORMAT ( \1 )/p' > > should do what you seem to want to achieve and is less bloated. > Index: libc/Makefile.in =================================================================== --- libc/Makefile.in (revision 20928) +++ libc/Makefile.in (working copy) @@ -54,7 +54,7 @@ lib-so-y += $(libc) objclean-y += libc_clean -OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p' +OUTPUT_FORMAT = $(CC) $(CFLAGS) -Wl,--verbose 2>&1 | sed -n 's/^OUTPUT_FORMAT("\([^"]*\)",.*/OUTPUT_FORMAT ( \1 )/p' ifeq ($(DOMULTI),n) $(libc:.$(MAJOR_VERSION)=): $(libc_OUT)/libc_so.a $(LIBS-libc.so) @@ -66,7 +66,7 @@ endif $(Q)$(RM) $@ $(Q)cp $(top_srcdir)extra/scripts/format.lds $@ - $(Q)echo "OUTPUT_FORMAT ( $(shell $(OUTPUT_FORMAT)) )" >> $@ + $(Q)echo "$(shell $(OUTPUT_FORMAT))" >> $@ ifeq ($(COMPAT_ATEXIT),y) $(Q)echo "GROUP ( $(NONSHARED_LIBNAME) $(SHARED_MAJORNAME) $(ASNEEDED) )" >> $@ else From carmelo.amoroso at st.com Fri Feb 8 01:24:40 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Fri, 08 Feb 2008 10:24:40 +0100 Subject: [PATCH] Fix dladdr return value when cannot find symbol In-Reply-To: <47AB7A46.4070208@t-online.de> References: <12b5f1ef0711292147x5e74be2dn41bcb8b9c3d567ba@mail.gmail.com> <475D57A0.1050507@st.com> <47603EC4.6080609@st.com> <200801051910.29409.vapier@gentoo.org> <4784ECCF.9080200@st.com> <47AB7A46.4070208@t-online.de> Message-ID: <47AC1FD8.2020805@st.com> 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. Regards, Carmelo From dann at ics.uci.edu Fri Feb 8 16:43:53 2008 From: dann at ics.uci.edu (Dan Nicolaescu) Date: Fri, 08 Feb 2008 16:43:53 -0800 Subject: [ping] [patch] getaddrinfo bug In-Reply-To: <003901c869a6$9ed7f5a0$838182a4@st.com> (Filippo ARCIDIACONO's message of "Thu, 7 Feb 2008 17:29:32 +0100") References: <200801301954.m0UJsD7e025679@sallyv1.ics.uci.edu> <003901c869a6$9ed7f5a0$838182a4@st.com> Message-ID: <200802090043.m190hrlA002496@sallyv1.ics.uci.edu> Filippo ARCIDIACONO writes: > > > > -----Original Message----- > > From: uclibc-bounces at uclibc.org > > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Dan Nicolaescu > > Sent: Wednesday, January 30, 2008 8:54 PM > > To: uclibc at uclibc.org > > Subject: [ping] [patch] getaddrinfo bug > > > > 2 weeks ago I sent this patch. There was no feedback on it. > > > > Can someone please take a look and comment on this patch? > > > > Thanks > > --dan > > > > > > > > When using x11r7, starting X11 application ends up calling > > _xcb_open_tcp in libxcb. > > > > _xcb_open_tcp looks like this: > > > > static int _xcb_open_tcp(char *host, const unsigned short port) { > > int fd = -1; > > struct addrinfo hints = { AI_ADDRCONFIG #ifdef AI_NUMERICSERV > > | AI_NUMERICSERV #endif > > , AF_UNSPEC, SOCK_STREAM }; [snip] > > res = getaddrinfo(host, service, &hints, &results); > > > > > > uclibc's netdb.h always defines AI_NUMERICSERV, so > > AI_NUMERICSERV is always used. > > > > The getaddrinfo implementation in uclibc does: > > > > if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| > > AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) > > return EAI_BADFLAGS; > > > > which means that getaddrinfo will always fail and return > > EAI_BADFLAGS because it passes AI_NUMERICSERV. > > > > As a result, X11 applications won't start. > > > > This patch fixes the problem: > > > > --- getaddrinfo.c.orig 2008-01-15 07:36:08.264317000 -0800 > > +++ getaddrinfo.c 2008-01-15 07:36:00.518071000 -0800 > > @@ -822,7 +822,7 @@ > > if (hints == NULL) > > hints = &default_hints; > > > > - if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| > > + if (hints->ai_flags & > > + ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_NUMERICSERV| > > AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) > > return EAI_BADFLAGS; > > In my opinion you have to check if the string is not just a number > with AI_NUMERICSERV flag high. > See the patch below. > > For more detail see glibc patch > http://sourceware.org/ml/glibc-cvs/2004-q3/msg00296.html > Based on the following bug > http://sources.redhat.com/bugzilla/show_bug.cgi?id=296 Thanks! Have you tested this? If it works, then it sounds like a good idea to check it in. (I will only be able to test this in about a week) > Regards > Filippo Arcidiacono. > > > --- uClibc-nptl/libc/inet/getaddrinfo.c (revision 16) > +++ uClibc-nptl/libc/inet/getaddrinfo.c (working copy) > @@ -823,7 +823,7 @@ > hints = &default_hints; > > if (hints->ai_flags & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST| > - AI_ADDRCONFIG|AI_V4MAPPED|AI_ALL)) > + > AI_ADDRCONFIG|AI_V4MAPPED|AI_NUMERICSERV|AI_ALL)) > return EAI_BADFLAGS; > > if ((hints->ai_flags & AI_CANONNAME) && name == NULL) > @@ -834,8 +834,12 @@ > char *c; > gaih_service.name = service; > gaih_service.num = strtoul (gaih_service.name, &c, 10); > - if (*c) > + if (*c != '\0') { > + if (hints->ai_flags & AI_NUMERICSERV) > + return EAI_NONAME; > + > gaih_service.num = -1; > + } > else > /* > * Can't specify a numerical socket unless a protocol > > _______________________________________________ > > uClibc mailing list > > uClibc at uclibc.org > > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From juanba.romance at gmail.com Sun Feb 10 09:11:43 2008 From: juanba.romance at gmail.com (juanba romance) Date: Sun, 10 Feb 2008 18:11:43 +0100 Subject: thread debugging with gdb Message-ID: Same behaviour for the AVR32 AP7 processor using the next tags avr32-linux-gcc 4.2.1-atmel.1.0.3 gdb-6.4.atmel.1.0.1 linux-kernel-2.6.18 uclibc-0.9.28 Which is the current status for this issue ? Chhers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/uclibc/attachments/20080210/4ba0c04e/attachment.htm From hcegtvedt at atmel.com Sun Feb 10 22:45:56 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 11 Feb 2008 07:45:56 +0100 Subject: thread debugging with gdb In-Reply-To: References: Message-ID: <1202712356.8056.66.camel@localhost> On Sun, 2008-02-10 at 18:11 +0100, juanba romance wrote: > Same behaviour for the AVR32 AP7 processor using the next tags > avr32-linux-gcc 4.2.1-atmel.1.0.3 > gdb-6.4.atmel.1.0.1 > linux-kernel-2.6.18 Please upgrade to v2.6.24.atmel.1 to get the debugging fixes. > uclibc-0.9.28 > Again, I think Subversion HEAD will be better than 0.9.28. > Which is the current status for this issue ? What issue? Debugging threads? Did you build uClibc with debuggable threads? -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Sun Feb 10 23:55:03 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 11 Feb 2008 08:55:03 +0100 Subject: thread debugging with gdb In-Reply-To: References: <1202712356.8056.66.camel@localhost> Message-ID: <1202716503.8056.72.camel@localhost> On Mon, 2008-02-11 at 08:44 +0100, juanba romance wrote: > On Feb 11, 2008 7:45 AM, Hans-Christian Egtvedt > wrote: PS! Do not drop the mailinglist address. Other may be interested or want to contribute to the discussion. > On Sun, 2008-02-10 at 18:11 +0100, juanba romance wrote: > > Same behaviour for the AVR32 AP7 processor using the next > tags > > avr32-linux-gcc 4.2.1-atmel.1.0.3 > > gdb-6.4.atmel.1.0.1 > > linux-kernel-2.6.18 > > > Please upgrade to v2.6.24.atmel.1 to get the debugging fixes. > > Ok, i changed above software chain provided by the official BSP to > the buildroot environment > which refresh all this stuff to the 2.6.23 kernel tag, maybe enough > Nope, the kernel in Buildroot for AVR32 fork does not have the debug fix. The easiest is to grab the kernel from http://avr32linux.org/twiki/bin/view/Main/LinuxPatches and compile it with the toolchain you generate with Buildroot. Then replace the /lib/modules and /boot/uImage in your image. > > uclibc-0.9.28 > > > Again, I think Subversion HEAD will be better than 0.9.28. > > The buildroot provides the 0.9.29 tag as above i assume also that's > enough > Yes, the Buildroot uClibc should be fine. > > Which is the current status for this issue ? > What issue? Debugging threads? > Yes.. > > > Did you build uClibc with debuggable > > threads? > Not yet i unpackaged the NGW100 kit on saturday and i was only > checking the default provided environment, Anyway the the buildroot > has already manufactured the images and all the stuff, but yes this > time i have toggled CONFIG_BR2_PTHREAD_DEBUG option i mean it's > related on isn't it? > If the file in toolchain_build_avr32_nofpu/uClibc-0.9.29/.config has PTHREADS_DEBUG_SUPPORT=y, then you should be fine. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From matthew at wil.cx Mon Feb 11 17:36:18 2008 From: matthew at wil.cx (Matthew Wilcox) Date: Mon, 11 Feb 2008 18:36:18 -0700 Subject: Implementation of ether_line, ether_hostton and ether_ntohost Message-ID: <20080212013618.GB18225@parisc-linux.org> I want to be able to etherwake by hostname. Since I've gone to the trouble of putting that information in /etc/ethers, I think my computer should jolly well not force me to type in meaningless strings of hex. So here's an implementation (ethers.c) and two test programs (ethers-line-test.c and ethers-test.c) which exercise it a little. I'm not sure how to integrate all this into your build framework; seems to me you guys would be the experts at that ;-) I hope you find my contribution useful. (Oh, and in case anyone's wondering, I have an agreement with my employer that this work I did in my own time belongs to me.) -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -------------- next part -------------- A non-text attachment was scrubbed... Name: ethers.c Type: text/x-csrc Size: 2712 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080211/898e7b49/attachment.c -------------- next part -------------- A non-text attachment was scrubbed... Name: ethers-line-test.c Type: text/x-csrc Size: 407 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080211/898e7b49/attachment-0001.c -------------- next part -------------- A non-text attachment was scrubbed... Name: ethers-test.c Type: text/x-csrc Size: 403 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080211/898e7b49/attachment-0002.c From bernds_cb1 at t-online.de Tue Feb 12 05:17:21 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 12 Feb 2008 14:17:21 +0100 Subject: __uc_malloc Message-ID: <47B19C61.8090203@t-online.de> The __uc_malloc patch was a bit sloppy about the libc_hidden_proto conventions in uClibc; as a result, more relocations than necessary are generated for libc.so. The patch below fixes that. Before I apply this, I wanted to start a discussion about whether __uc_malloc is a good idea at all. Space savings are all well and good, but these come at a cost in reliability. A number of libc functions can now call exit, even though this is not documented and not expected by any programs that call them. Personally, I think all the __uc_malloc patches should be reverted. Comments? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif -------------- next part -------------- A non-text attachment was scrubbed... Name: ucmalloc-proto.diff Type: text/x-patch Size: 5090 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080212/7215e47a/attachment.bin From vda.linux at googlemail.com Tue Feb 12 05:34:38 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 12 Feb 2008 13:34:38 +0000 Subject: __uc_malloc In-Reply-To: <47B19C61.8090203@t-online.de> References: <47B19C61.8090203@t-online.de> Message-ID: <200802121334.38059.vda.linux@googlemail.com> On Tuesday 12 February 2008 13:17, Bernd Schmidt wrote: > The __uc_malloc patch was a bit sloppy about the libc_hidden_proto > conventions in uClibc; as a result, more relocations than necessary are > generated for libc.so. The patch below fixes that. > > Before I apply this, I wanted to start a discussion about whether > __uc_malloc is a good idea at all. Space savings are all well and good, > but these come at a cost in reliability. There is no cost in reliability. Face it: if you have no free memory - you have no free memory. Just allocating a big static object (like des.c was doing) cannot magically guarantee that you will have this memory. It just shifts failure to some other place - program might fail to load, or hit malloc failure earlier in other plase, because des.c ate 70k. Anyone who codes in C a lot usually gets a habitual "feeling" that this is safe: char buf[10000]; this is safe too: void f() { char buf[10000]; .... } and this is not: void g() { char *buf = malloc(10000); /* might fail */ ... } but think about it again: first two cases cannot be 100.00% safe too - otherwise it would mean that your system can "produce" arbitrary amounts of free memory! This is not true! _All_ these things require memory, they just fail differently! First one: failure to load on NOMMU, death via swap storm on MMU Second: stack overflow Third: depends on how program author coded NULL check. > A number of libc functions can > now call exit, even though this is not documented and not expected by > any programs that call them. This is not exactly true. They can exit *if* program author did not install alternative handler for __uc_malloc failure. Clever handler can e.g. exit gracefully, or free some kind of "emergency pool", show message box "Low on memory" and let user close GUI app cleanly. > Personally, I think all the __uc_malloc patches should be reverted. Hope my explanation of __uc_malloc chaged your mind. Also, the patch below *definitely* is an improvement, right? --- /trunk/uClibc/libc/misc/ttyent/getttyent.c 2007/07/30 16:55:05 19346 +++ trunk/uClibc/libc/misc/ttyent/getttyent.c 2007/07/30 17:02:06 19347 @@ -34,6 +34,7 @@ #include #include #include +#include #ifdef __UCLIBC_HAS_THREADS__ #include #endif @@ -132,9 +133,7 @@ return (NULL); if (!line) { - line = malloc(BUFSIZ); - if (!line) - abort(); + line = __uc_malloc(BUFSIZ); } __STDIO_ALWAYS_THREADLOCK(tf); -- vda From bernds_cb1 at t-online.de Tue Feb 12 07:18:33 2008 From: bernds_cb1 at t-online.de (Bernd Schmidt) Date: Tue, 12 Feb 2008 16:18:33 +0100 Subject: __uc_malloc In-Reply-To: <200802121334.38059.vda.linux@googlemail.com> References: <47B19C61.8090203@t-online.de> <200802121334.38059.vda.linux@googlemail.com> Message-ID: <47B1B8C9.3000203@t-online.de> Denys Vlasenko wrote: >> Before I apply this, I wanted to start a discussion about whether >> __uc_malloc is a good idea at all. Space savings are all well and good, >> but these come at a cost in reliability. > > There is no cost in reliability. > > Face it: if you have no free memory - you have no free memory. > Just allocating a big static object (like des.c was doing) > cannot magically guarantee that you will have this memory. > It just shifts failure to some other place - program might fail to load, > or hit malloc failure earlier in other plase, because des.c ate 70k. IMO it's much better to have it fail with out of memory in places where such behaviour is expected and documented as a possibility. >> A number of libc functions can >> now call exit, even though this is not documented and not expected by >> any programs that call them. > > This is not exactly true. They can exit *if* program author did not > install alternative handler for __uc_malloc failure. And __uc_malloc is documented in which standard? Which manpage tells program authors about the function calls that may need a handler installed? Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif From vda.linux at googlemail.com Tue Feb 12 07:45:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 12 Feb 2008 15:45:37 +0000 Subject: __uc_malloc In-Reply-To: <47B1B8C9.3000203@t-online.de> References: <47B19C61.8090203@t-online.de> <200802121334.38059.vda.linux@googlemail.com> <47B1B8C9.3000203@t-online.de> Message-ID: <200802121545.37807.vda.linux@googlemail.com> On Tuesday 12 February 2008 15:18, Bernd Schmidt wrote: > Denys Vlasenko wrote: > >> Before I apply this, I wanted to start a discussion about whether > >> __uc_malloc is a good idea at all. Space savings are all well and good, > >> but these come at a cost in reliability. > > > > There is no cost in reliability. > > > > Face it: if you have no free memory - you have no free memory. > > Just allocating a big static object (like des.c was doing) > > cannot magically guarantee that you will have this memory. > > It just shifts failure to some other place - program might fail to load, > > or hit malloc failure earlier in other plase, because des.c ate 70k. > > IMO it's much better to have it fail with out of memory in places where > such behaviour is expected and documented as a possibility. 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. > >> A number of libc functions can > >> now call exit, even though this is not documented and not expected by > >> any programs that call them. Similarly, say, a number of fucnctions can touch static arrays in bss. On MMU system, memory pages will be supplied on demand, on first access. What will happen if system has exactly ZERO free pages and no pages are freeable? On Linux, this will trigger OOM killer. So, shall we outlaw static arrays in bss too? > > This is not exactly true. They can exit *if* program author did not > > install alternative handler for __uc_malloc failure. > > And __uc_malloc is documented in which standard? None. > Which manpage tells > program authors about the function calls that may need a handler installed? Author doesn't need to care which functions can trigger this. It's similar to the fact that you don't need to decide which libc function can overflow the stack on NOMMU CPU - any function can, if stack is already tight enough when you call it. Author only needs to decide _what to do_ if __uc_malloc_ fails, in case default behaviour of doing "_exit(1)" is not desirable. Example: #ifdef __UCLIBC__ static void uc_malloc_failed() { write(2, "out of memory\n", sizeof("out of memory\n") - 1); _exit(1); } #endif int main() { #ifdef __UCLIBC__ __uc_malloc_failed = uc_malloc_failed; #endif ... } -- vda From carmelo73 at gmail.com Tue Feb 12 11:10:41 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Tue, 12 Feb 2008 20:10:41 +0100 Subject: Implementation of ether_line, ether_hostton and ether_ntohost In-Reply-To: <20080212013618.GB18225@parisc-linux.org> References: <20080212013618.GB18225@parisc-linux.org> Message-ID: <47B1EF31.4050507@gmail.com> Matthew Wilcox wrote: > I want to be able to etherwake by hostname. Since I've gone to the > trouble of putting that information in /etc/ethers, I think my computer > should jolly well not force me to type in meaningless strings of hex. > > So here's an implementation (ethers.c) and two test programs > (ethers-line-test.c and ethers-test.c) which exercise it a little. > I'm not sure how to integrate all this into your build framework; seems > to me you guys would be the experts at that ;-) > > I hope you find my contribution useful. > Let me see.... indeed I'm interested into etherwake too Cheers, Carmelo > (Oh, and in case anyone's wondering, I have an agreement with my > employer that this work I did in my own time belongs to me.) > > > > ------------------------------------------------------------------------ > > /* > * libc/inet/ethers.c > * > * Programmatic interface for the /etc/ethers file > * > * Copyright 2007 by Matthew Wilcox > * > * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. > */ > > #include > #include > #include > #include > > #ifndef ETHER_FILE_NAME > #define ETHER_FILE_NAME "/etc/ethers" > #endif > #define ETHER_LINE_LEN 256 > > /* > * Internal function which returns a pointer to the part of the line > * with the start of the hostname, or NULL if we couldn't parse the line. > * Note that this line may have a comment symbol on it somewhere; if so > * it will return NULL if the # is before or within the ether_addr, and > * succeed if the # is before or within the host. It's up to the callers > * to be aware of this. > * > * I would have preferred to write a NUL to the location of the comment > * character, but ether_line takes a const argument. See __ether_line_w. > */ > static const char *__ether_line(const char *line, struct ether_addr *addr) > { > struct ether_addr *res = ether_aton_r(line, addr); > if (!res) > return NULL; > > while (*line && (*line != ' ') && (*line != '\t')) > line++; > while (*line && ((*line == ' ') || (*line == '\t'))) > line++; > return (*line) ? line : NULL; > } > > /* > * Strips out the comment before calling __ether_line. We can do this, > * since we know the buffer is writable. > */ > static const char *__ether_line_w(char *line, struct ether_addr *addr) > { > char *end = strchr(line, '#'); > if (!end) > end = strchr(line, '\n'); > if (end) > *end = '\0'; > return __ether_line(line, addr); > } > > int ether_line(const char *line, struct ether_addr *addr, char *hostname) > { > const char *name = __ether_line(line, addr); > if (!name) > return -1; > > while (*name) { > if ((*name == '#') || isspace(*name)) > break; > *hostname++ = *name++; > } > *hostname = '\0'; > > return 0; > } > > int ether_ntohost(char *hostname, const struct ether_addr *addr) > { > int res = -1; > FILE *fp; > char buf[ETHER_LINE_LEN]; > > fp = fopen(ETHER_FILE_NAME, "r"); > if (!fp) > return -1; > > while (fgets(buf, sizeof(buf), fp)) { > struct ether_addr tmp_addr; > const char *cp = __ether_line_w(buf, &tmp_addr); > if (!cp) > continue; > if (memcmp(addr, &tmp_addr, sizeof(tmp_addr))) > continue; > > strcpy(hostname, cp); > res = 0; > break; > } > > fclose(fp); > return res; > } > > int ether_hostton(const char *hostname, struct ether_addr *addr) > { > int res = -1; > FILE *fp; > char buf[ETHER_LINE_LEN]; > > fp = fopen(ETHER_FILE_NAME, "r"); > if (!fp) > return -1; > > while (fgets(buf, sizeof(buf), fp)) { > const char *cp = __ether_line_w(buf, addr); > if (!cp) > continue; > if (strcasecmp(hostname, cp)) > continue; > > res = 0; > break; > } > > fclose(fp); > return res; > } > > > ------------------------------------------------------------------------ > > #include > #include > #include > #include > #include > #include > > #include "ethers.c" > > int main(void) > { > struct ether_addr addr; > char hostname[1024]; > int fd = open("ethers", O_RDONLY); > const char *ethers = mmap(NULL, 100000, PROT_READ, MAP_SHARED, fd, 0); > > ether_line(ethers, &addr, hostname); > > printf("%s\n", hostname); > > return 0; > } > > > ------------------------------------------------------------------------ > > #define ETHER_FILE_NAME "ethers" > #include "ethers.c" > > int main(void) > { > struct ether_addr addr; > char host[256]; > int i, res = ether_hostton("teeth", &addr); > if (res) > return 1; > > for (i = 0; i < 6; i++) { > printf("%02x", addr.ether_addr_octet[i]); > if (i == 5) > printf(" "); > else > printf(":"); > } > > res = ether_ntohost(host, &addr); > if (res) > return 1; > printf("%s\n", host); > > return 0; > } > > > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From vda.linux at googlemail.com Tue Feb 12 11:31:12 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 12 Feb 2008 19:31:12 +0000 Subject: __uc_malloc In-Reply-To: <47B19C61.8090203@t-online.de> References: <47B19C61.8090203@t-online.de> Message-ID: <200802122031.12471.vda.linux@googlemail.com> On Tuesday 12 February 2008 14:17, Bernd Schmidt wrote: > The __uc_malloc patch was a bit sloppy about the libc_hidden_proto > conventions in uClibc; as a result, more relocations than necessary are > generated for libc.so. The patch below fixes that. I took the liberty of applying your patch. Thanks, and apologies for me not doing it myself. -- vda From drow at false.org Tue Feb 12 12:46:56 2008 From: drow at false.org (Daniel Jacobowitz) Date: Tue, 12 Feb 2008 15:46:56 -0500 Subject: Skip early ld.so event Message-ID: <20080212204656.GA30545@caradoc.them.org> This patch skips the first call to _dl_debug_state. This one's troublesome, because we have a non-empty list of shared libraries (it's got the application on it), but we don't have the ld.so interpreter on the list yet. So the current location is code that the debugger doesn't have symbols for. In a perfect world this works anyway and the debugger doesn't mind not having symbols. In practice this is the second time I've encountered a uClibc-only bug because of this call so I would suggest removing it. Glibc doesn't call _dl_debug_state until it is ready to initialize directly linked and preloaded libraries. -- Daniel Jacobowitz CodeSourcery 2008-02-12 Daniel Jacobowitz * ldso/ldso/ldso.c (_dl_get_ready_to_run): Do not call _dl_debug_state before recording ld.so. Index: ldso/ldso/ldso.c =================================================================== --- ldso/ldso/ldso.c (revision 193179) +++ ldso/ldso/ldso.c (working copy) @@ -470,9 +470,7 @@ void _dl_get_ready_to_run(struct elf_res debug_addr->r_brk = (unsigned long) &_dl_debug_state; _dl_debug_addr = debug_addr; - /* Notify the debugger we are in a consistant state */ - _dl_debug_addr->r_state = RT_CONSISTENT; - _dl_debug_state(); + /* Do not notify the debugger until the interpreter is in the list. */ /* OK, we now have the application in the list, and we have some * basic stuff in place. Now search through the list for other shared From John.Calixto at watchguard.com Wed Feb 13 16:30:26 2008 From: John.Calixto at watchguard.com (John Calixto) Date: Wed, 13 Feb 2008 16:30:26 -0800 Subject: locale support (yes, i'm going to try to improve it) Message-ID: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66EB2@VS02SE.wgti.net> Hello folks, I'm currently working on improving locale support. My specific interest is in getting it working on armeb. I have successfully built in locale support for x86, and it seems to work fine. However, when working with armeb, I see a few spots where I suspect at least struct alignment to be a problem. Drilling down into how the data (i.e. c8tables.h, locale_data.c, and friends) are generated, I'm a bit confused by what goes on in gen_wc8bit.c. What are ``tt``, ``ti``, and ``xi``? They appear to be part of some kind of indexing algorithm, but I'm not sure. Any help would be greatly appreciated. Thanks, John From carmelo.amoroso at st.com Thu Feb 14 01:25:17 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 14 Feb 2008 10:25:17 +0100 Subject: locale support (yes, i'm going to try to improve it) In-Reply-To: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66EB2@VS02SE.wgti.net> References: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66EB2@VS02SE.wgti.net> Message-ID: <47B408FD.4020404@st.com> John Calixto wrote: > Hello folks, > > I'm currently working on improving locale support. My specific interest > is in getting it working on armeb. > > I have successfully built in locale support for x86, and it seems to > work fine. However, when working with armeb, I see a few spots where I > suspect at least struct alignment to be a problem. > Hello, I have a some fixes into locale code to be committed soon. We have included a lot of locale tests from glibc tree into uClibc, and tested locale support into uClibc, so added some fixes to solve some of them. Cheers, Carmelo > Drilling down into how the data (i.e. c8tables.h, locale_data.c, and > friends) are generated, I'm a bit confused by what goes on in > gen_wc8bit.c. What are ``tt``, ``ti``, and ``xi``? They appear to be > part of some kind of indexing algorithm, but I'm not sure. > > Any help would be greatly appreciated. > > Thanks, > > John > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From John.Calixto at watchguard.com Thu Feb 14 10:13:31 2008 From: John.Calixto at watchguard.com (John Calixto) Date: Thu, 14 Feb 2008 10:13:31 -0800 Subject: locale support (yes, i'm going to try to improve it) In-Reply-To: <47B408FD.4020404@st.com> References: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66EB2@VS02SE.wgti.net> <47B408FD.4020404@st.com> Message-ID: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66FBB@VS02SE.wgti.net> > Hello, > I have a some fixes into locale code to be committed soon. We > have included a lot of locale tests from glibc tree into > uClibc, and tested locale support into uClibc, so added some > fixes to solve some of them. > > Cheers, > Carmelo > Great! Not to pester you, but when you say "committed soon", do you mean days, weeks, or months "soon"? ;) I just need to have an idea about whether or not to proceed with my short-term solution. Also, if you need help with testing, please let me know - I have time and ARM hardware to test on, and I'm very eager to get this working on armeb. Thanks, John From vapier at gentoo.org Fri Feb 15 15:10:32 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 15 Feb 2008 18:10:32 -0500 Subject: fork on nommu In-Reply-To: <20080207215620.GA27684@caradoc.them.org> References: <47AB7AE9.7080106@t-online.de> <20080207215620.GA27684@caradoc.them.org> Message-ID: <200802151810.33067.vapier@gentoo.org> On Thursday 07 February 2008, Daniel Jacobowitz wrote: > On Thu, Feb 07, 2008 at 10:40:57PM +0100, Bernd Schmidt wrote: > > A number of programs, such as busybox, contain calls to fork which may > > not necessarily get executed at runtime. On nommu systems, this > > currently produces link errors since the function doesn't exist. > > > > In our Blackfin tree, we use the following patch (by Mike IIRC) to > > convert the link error into a warning. Any objections to installing > > this? err, not quite ... you added fork() as a stub for no-mmu and i complained about it existing at all, but then just added the link warning so that it wouldnt go completely unnoticed. > FWIW, I think the link error is more useful than a stub version. Most > programs don't handle fork failure gracefully. i'd agree. i dont think ive seen code yet that handles the case where fork() is not actually implemented other than simply aborting. the code may as not exist if fork() doesnt exist. the default mainline no-mmu build should not have a fork() symbol ... whether we want to add a config option for no-mmu "Add stubs for unimplemented symbols" to control this and things like daemon() would be ok i think -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080215/78e0a3dd/attachment.pgp From vapier at gentoo.org Fri Feb 15 15:38:49 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 15 Feb 2008 18:38:49 -0500 Subject: uClibc and expected versions of usable gcc In-Reply-To: <200801081206.47766.vapier@gentoo.org> References: <200801081206.47766.vapier@gentoo.org> Message-ID: <200802151838.49963.vapier@gentoo.org> On Tuesday 08 January 2008, Mike Frysinger wrote: > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > uClibc. that means it's the oldest version i'd consider adding source code > tweaks to work around gcc bugs. for older versions of gcc, if uClibc fails > to build for you due to a bug in the compiler, the answer is upgrade your > gcc, sorry. > > any comments/thoughts/inputs/whatever ? ready set fight ive updated the FAQ. if people could take a quick peek, that'd be great: http://uclibc.org/FAQ.html#upstream_versions -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080215/f6709c46/attachment.pgp From christian.michon at gmail.com Fri Feb 15 15:54:09 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Sat, 16 Feb 2008 00:54:09 +0100 Subject: uClibc and expected versions of usable gcc In-Reply-To: <200802151838.49963.vapier@gentoo.org> References: <200801081206.47766.vapier@gentoo.org> <200802151838.49963.vapier@gentoo.org> Message-ID: <46d6db660802151554u31e9a6besc4ef75d5b3ed8555@mail.gmail.com> On Feb 16, 2008 12:38 AM, Mike Frysinger wrote: > > On Tuesday 08 January 2008, Mike Frysinger wrote: > > at this time, i'd consider gcc-3.4.6 the oldest version worth using with > > uClibc. that means it's the oldest version i'd consider adding source code > > tweaks to work around gcc bugs. for older versions of gcc, if uClibc fails > > to build for you due to a bug in the compiler, the answer is upgrade your > > gcc, sorry. > > > > any comments/thoughts/inputs/whatever ? ready set fight > > ive updated the FAQ. if people could take a quick peek, that'd be great: > http://uclibc.org/FAQ.html#upstream_versions > -mike > thanks. looks ok (gcc-3.4.6 is still supported, cool!) -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From carmelo73 at gmail.com Sat Feb 16 06:09:27 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 16 Feb 2008 15:09:27 +0100 Subject: locale support (yes, i'm going to try to improve it) In-Reply-To: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66FBB@VS02SE.wgti.net> References: <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66EB2@VS02SE.wgti.net> <47B408FD.4020404@st.com> <1D4AF0FA9FFEEE44AF46F697C8A2A51402B66FBB@VS02SE.wgti.net> Message-ID: <2ccd6e3c0802160609t57cb4e9fgcc03880be47a972c@mail.gmail.com> On 14/02/2008, John Calixto wrote: > > Hello, > > I have a some fixes into locale code to be committed soon. We > > have included a lot of locale tests from glibc tree into > > uClibc, and tested locale support into uClibc, so added some > > fixes to solve some of them. > > > > Cheers, > > Carmelo > > > > Great! Not to pester you, but when you say "committed soon", do you > mean days, weeks, or months "soon"? ;) I just need to have an idea > about whether or not to proceed with my short-term solution. Hopefully by the end of next week. > Also, if > you need help with testing, please let me know - I have time and ARM > hardware to test on, and I'm very eager to get this working on armeb. > If you have some specific tests for utf8 multibyte locales, may be usefull. > Thanks, > > John > carmelo > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > From hcegtvedt at atmel.com Sun Feb 17 22:42:01 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 07:42:01 +0100 Subject: [PATCH 5/7] add AVR32 pthread support In-Reply-To: <200801050256.10182.vapier@gentoo.org> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> <11943354101804-git-send-email-hcegtvedt@atmel.com> <200801050256.10182.vapier@gentoo.org> Message-ID: <1203316921.24908.5.camel@localhost> On Sat, 2008-01-05 at 02:56 -0500, Mike Frysinger wrote: > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > + __asm__ __volatile__( > > + "/* Inline test and set */\n" > > is it really a good idea to be sticking comments in the assembly output ? i > guess as long as your assembler supports it as they wont be getting > preprocessed by the the compiler ... > Comments in assembly output works, yes. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Sun Feb 17 22:44:12 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 07:44:12 +0100 Subject: [PATCH 6/7] add dynamic library support for AVR32 In-Reply-To: <200801050257.49971.vapier@gentoo.org> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354101804-git-send-email-hcegtvedt@atmel.com> <1194335410549-git-send-email-hcegtvedt@atmel.com> <200801050257.49971.vapier@gentoo.org> Message-ID: <1203317052.24908.8.camel@localhost> On Sat, 2008-01-05 at 02:57 -0500, Mike Frysinger wrote: > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > --- /dev/null > > +++ b/ldso/ldso/avr32/elfinterp.c > > @@ -0,0 +1,193 @@ > > +/* > > + * AVR32 ELF shared library loader suppport > > + * > > + * Copyright (C) 2004-2006 Atmel Corporation > > + * > > + * All rights reserved. > > + * > > + * Redistribution and use in source and binary forms, with or without > > ........ > > what's with this spurious BSD license when all the rest of your code is LGPL > like uClibc ? > The AVR32 specific stuff should be dual license (LGPL + modified BSD), since we do not mind people ripping out the code and use it in their own stuff. AFAIK this should be ok for the uClibc project? I have to admit that I did not double check if it is consistent though. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Sun Feb 17 22:47:50 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 07:47:50 +0100 Subject: [PATCH 2/7] add include, bits and sys headers In-Reply-To: <200801050251.24277.vapier@gentoo.org> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354103911-git-send-email-hcegtvedt@atmel.com> <1194335410428-git-send-email-hcegtvedt@atmel.com> <200801050251.24277.vapier@gentoo.org> Message-ID: <1203317270.24908.11.camel@localhost> On Sat, 2008-01-05 at 02:51 -0500, Mike Frysinger wrote: > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > +#define EM_AVR32 0x18ad > > you guys arent in binutils yet eh ? you planning on keeping this value, or > you going to be dropping down to a normal one ? > We are not in binutils upstream yet, no, working on it though :) AFAIK we will keep this value, as it is chosen by a third party compiler vendor (IAR). This was done before my time, so perhaps Haavard can shed some light on it? -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Sun Feb 17 22:49:13 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 07:49:13 +0100 Subject: [PATCH] libc: cleanup some compile warnings In-Reply-To: <200801050429.17099.vapier@gentoo.org> References: <11933880373405-git-send-email-hcegtvedt@atmel.com> <200801050429.17099.vapier@gentoo.org> Message-ID: <1203317353.24908.14.camel@localhost> On Sat, 2008-01-05 at 04:29 -0500, Mike Frysinger wrote: > On Friday 26 October 2007, Hans-Christian Egtvedt wrote: > > Signed-off-by: Hans-Christian Egtvedt > > --- > > libc/inet/rpc/create_xid.c | 2 +- > > libc/inet/rpc/xdr.c | 12 ++++++------ > > libc/inet/rpc/xdr_intXX_t.c | 4 ++-- > > the rpc code is horrendous ... i'm of the opinion we should encourage people > to use the TIRPC library rather than the SUNRPC code in uClibc. the SUNRPC > has known limitations (which are addressed by the TIRPC library), any drepper > has already denied enhancements to SUNRPC in glibc (he regrets ever having > merged it actually). > > i'm guessing these casts are for strict aliased warnings ? i dont think > casting them away fixes the problem. > Agreed, I saw some other work lately on the list about strict aliased warnings. Although, unsure if it touched the RPC code. > > libc/stdio/_scanf.c | 8 ++++---- > > libc/stdio/_vfprintf.c | 8 ++++---- > > libc/stdio/vsnprintf.c | 4 ++-- > > merged, cheers > Thanks. Sorry about all the late answers. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Mon Feb 18 00:04:25 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 09:04:25 +0100 Subject: [PATCH 4/7] add AVR32 optimized string functions In-Reply-To: <200801050254.10862.vapier@gentoo.org> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354102079-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> <200801050254.10862.vapier@gentoo.org> Message-ID: <1203321865.24908.26.camel@localhost> On Sat, 2008-01-05 at 02:54 -0500, Mike Frysinger wrote: > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > + rjmp __GI_memmove > > all of your .S files should be using HIDDEN_JUMPTARGET() rather than the __GI_ > prefixes manually added. > Thanks for spotting it. For these "quick fixes" is it appropriate if I just do the commit, or is the common way to post the patch to the uClibc mailing list and commit a few days later if there is no negative response? I could not really find any details about the review process. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hskinnemoen at atmel.com Mon Feb 18 02:07:12 2008 From: hskinnemoen at atmel.com (Haavard Skinnemoen) Date: Mon, 18 Feb 2008 11:07:12 +0100 Subject: [PATCH 2/7] add include, bits and sys headers In-Reply-To: <1203317270.24908.11.camel@localhost> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354103911-git-send-email-hcegtvedt@atmel.com> <1194335410428-git-send-email-hcegtvedt@atmel.com> <200801050251.24277.vapier@gentoo.org> <1203317270.24908.11.camel@localhost> Message-ID: <20080218110712.0db24093@dhcp-252-066.norway.atmel.com> On Mon, 18 Feb 2008 07:47:50 +0100 Hans-Christian Egtvedt wrote: > AFAIK we will keep this value, as it is chosen by a third party compiler > vendor (IAR). This was done before my time, so perhaps Haavard can shed > some light on it? You're right that it was initially used by the IAR toolchain, but we should probably try to get an official value. I'll ask if IAR has any plans. How do we get an official number these days? There's a comment in there saying we should ask SCO, but are they in shape to do anything right now? Haavard From carmelo.amoroso at st.com Tue Feb 19 02:10:14 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 19 Feb 2008 11:10:14 +0100 Subject: Skip early ld.so event In-Reply-To: <20080212204656.GA30545@caradoc.them.org> References: <20080212204656.GA30545@caradoc.them.org> Message-ID: <47BAAB06.90006@st.com> Daniel Jacobowitz wrote: > This patch skips the first call to _dl_debug_state. This one's > troublesome, because we have a non-empty list of shared libraries > (it's got the application on it), but we don't have the ld.so > interpreter on the list yet. So the current location is code > that the debugger doesn't have symbols for. > > In a perfect world this works anyway and the debugger doesn't mind > not having symbols. In practice this is the second time I've > encountered a uClibc-only bug because of this call so I would suggest > removing it. Glibc doesn't call _dl_debug_state until it is ready > to initialize directly linked and preloaded libraries. > > Hello Daniel, I'm interested to know what kind of bug you had, segfault on gdbserver ? or whatever, just to see if it is the same kind of strange behavior I've seen in the past on my uclibc. Let me know Carmelo From drow at false.org Tue Feb 19 05:20:24 2008 From: drow at false.org (Daniel Jacobowitz) Date: Tue, 19 Feb 2008 08:20:24 -0500 Subject: Skip early ld.so event In-Reply-To: <47BAAB06.90006@st.com> References: <20080212204656.GA30545@caradoc.them.org> <47BAAB06.90006@st.com> Message-ID: <20080219132024.GB20899@caradoc.them.org> On Tue, Feb 19, 2008 at 11:10:14AM +0100, Carmelo AMOROSO wrote: > Daniel Jacobowitz wrote: >> This patch skips the first call to _dl_debug_state. This one's >> troublesome, because we have a non-empty list of shared libraries >> (it's got the application on it), but we don't have the ld.so >> interpreter on the list yet. So the current location is code >> that the debugger doesn't have symbols for. >> >> In a perfect world this works anyway and the debugger doesn't mind >> not having symbols. In practice this is the second time I've >> encountered a uClibc-only bug because of this call so I would suggest >> removing it. Glibc doesn't call _dl_debug_state until it is ready >> to initialize directly linked and preloaded libraries. >> >> > Hello Daniel, > I'm interested to know what kind of bug you had, segfault on gdbserver ? > or whatever, just to see if it is the same kind of strange behavior > I've seen in the past on my uclibc. > Let me know No, this shouldn't ever affect gdbserver. It crashed the program being run once, when GDB thought it was in ARM mode instead of Thumb. And more recently GDB just disabled the _dl_debug_state breakpoint, which breaks debugging of dlopen. -- Daniel Jacobowitz CodeSourcery From md4uclibc at gmail.com Tue Feb 19 05:20:03 2008 From: md4uclibc at gmail.com (Mile Davidovic) Date: Tue, 19 Feb 2008 14:20:03 +0100 Subject: uclibc and mips32r2 Message-ID: Hello, is ti possible to build uClibC with MIPS32R2 and EABI as used ABI? BR Mile From hcegtvedt at atmel.com Wed Feb 20 06:03:19 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Wed, 20 Feb 2008 15:03:19 +0100 Subject: [PATCH 4/7] add AVR32 optimized string functions In-Reply-To: <1203321865.24908.26.camel@localhost> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354102079-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> <200801050254.10862.vapier@gentoo.org> <1203321865.24908.26.camel@localhost> Message-ID: <1203516199.21867.47.camel@localhost> On Mon, 2008-02-18 at 09:04 +0100, Hans-Christian Egtvedt wrote: > On Sat, 2008-01-05 at 02:54 -0500, Mike Frysinger wrote: > > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > > + rjmp __GI_memmove > > > > all of your .S files should be using HIDDEN_JUMPTARGET() rather than the __GI_ > > prefixes manually added. > > > > Thanks for spotting it. For these "quick fixes" is it appropriate if I > just do the commit, or is the common way to post the patch to the uClibc > mailing list and commit a few days later if there is no negative > response? > > I could not really find any details about the review process. > Bump -- With kind regards, Hans-Christian Egtvedt, Applications Engineer From hcegtvedt at atmel.com Wed Feb 20 06:23:22 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Wed, 20 Feb 2008 15:23:22 +0100 Subject: [PATCH 4/7] add AVR32 optimized string functions In-Reply-To: <1203516199.21867.47.camel@localhost> References: <11943354102834-git-send-email-hcegtvedt@atmel.com> <11943354102079-git-send-email-hcegtvedt@atmel.com> <11943354101432-git-send-email-hcegtvedt@atmel.com> <200801050254.10862.vapier@gentoo.org> <1203321865.24908.26.camel@localhost> <1203516199.21867.47.camel@localhost> Message-ID: <1203517402.21867.51.camel@localhost> On Wed, 2008-02-20 at 15:03 +0100, Hans-Christian Egtvedt wrote: > On Mon, 2008-02-18 at 09:04 +0100, Hans-Christian Egtvedt wrote: > > On Sat, 2008-01-05 at 02:54 -0500, Mike Frysinger wrote: > > > On Tuesday 06 November 2007, Hans-Christian Egtvedt wrote: > > > > + rjmp __GI_memmove > > > > > > all of your .S files should be using HIDDEN_JUMPTARGET() rather than the __GI_ > > > prefixes manually added. > > > The following patch should fix all the __GI_ stuff, commited on trunk. -- With kind regards, Hans-Christian Egtvedt, Applications Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-HIDDEN_JUMPTARGET-define-instead-of-__gi_-direct.patch Type: application/mbox Size: 0 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080220/2433fc96/attachment.bin From hcegtvedt at atmel.com Mon Feb 18 00:14:10 2008 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 18 Feb 2008 09:14:10 +0100 Subject: [PATCH 1/1] Use HIDDEN_JUMPTARGET define instead of __gi_ directly in AVR32 files Message-ID: This patch uses the HIDDEN_JUMPTARGET instead of the __gi_ prefix in AVR32 assembler files. This is done to follow the code style in uClibc. Signed-off-by: Hans-Christian Egtvedt --- I know the patch shows a really broken indentation using spaces instead of TAB, but it seems like all the AVR32 stuff has been crippled in the initial commit, turning all TABs into spaces. I will get around to form a patch correcting that. In the mean time, lets remove the __GI_ stuff (-: libc/string/avr32/bcopy.S | 2 +- libc/string/avr32/memmove.S | 2 +- libc/sysdeps/linux/avr32/bsd-_setjmp.S | 2 +- libc/sysdeps/linux/avr32/bsd-setjmp.S | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libc/string/avr32/bcopy.S b/libc/string/avr32/bcopy.S index 87c1e04..bdd5218 100644 --- a/libc/string/avr32/bcopy.S +++ b/libc/string/avr32/bcopy.S @@ -19,7 +19,7 @@ bcopy: eor r11, r12 eor r12, r11 eor r11, r12 - rjmp __GI_memmove + rjmp HIDDEN_JUMPTARGET(memmove) .size bcopy, . - bcopy diff --git a/libc/string/avr32/memmove.S b/libc/string/avr32/memmove.S index 98287c5..535f4a2 100644 --- a/libc/string/avr32/memmove.S +++ b/libc/string/avr32/memmove.S @@ -15,7 +15,7 @@ .type memmove, @function memmove: cp.w src, dst - brge __GI_memcpy + brge HIDDEN_JUMPTARGET(memcpy) add dst, len add src, len diff --git a/libc/sysdeps/linux/avr32/bsd-_setjmp.S b/libc/sysdeps/linux/avr32/bsd-_setjmp.S index be66a10..f23e73b 100644 --- a/libc/sysdeps/linux/avr32/bsd-_setjmp.S +++ b/libc/sysdeps/linux/avr32/bsd-_setjmp.S @@ -12,5 +12,5 @@ .align 1 _setjmp: mov r11, 0 - bral __GI___sigsetjmp + bral HIDDEN_JUMPTARGET(__sigsetjmp) .size _setjmp, . - _setjmp diff --git a/libc/sysdeps/linux/avr32/bsd-setjmp.S b/libc/sysdeps/linux/avr32/bsd-setjmp.S index 4635eeb..5247ec3 100644 --- a/libc/sysdeps/linux/avr32/bsd-setjmp.S +++ b/libc/sysdeps/linux/avr32/bsd-setjmp.S @@ -12,5 +12,5 @@ .align 1 setjmp: mov r11, 1 - bral __GI___sigsetjmp + bral HIDDEN_JUMPTARGET(__sigsetjmp) .size setjmp, . - setjmp -- 1.5.2.5 --=-oWh1F2kSsezSXa8dccTN-- From carmelo73 at gmail.com Wed Feb 20 12:29:02 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Wed, 20 Feb 2008 21:29:02 +0100 Subject: Skip early ld.so event In-Reply-To: <20080219132024.GB20899@caradoc.them.org> References: <20080212204656.GA30545@caradoc.them.org> <47BAAB06.90006@st.com> <20080219132024.GB20899@caradoc.them.org> Message-ID: <47BC8D8E.30906@gmail.com> Daniel Jacobowitz wrote: > On Tue, Feb 19, 2008 at 11:10:14AM +0100, Carmelo AMOROSO wrote: >> Daniel Jacobowitz wrote: >>> This patch skips the first call to _dl_debug_state. This one's >>> troublesome, because we have a non-empty list of shared libraries >>> (it's got the application on it), but we don't have the ld.so >>> interpreter on the list yet. So the current location is code >>> that the debugger doesn't have symbols for. >>> >>> In a perfect world this works anyway and the debugger doesn't mind >>> not having symbols. In practice this is the second time I've >>> encountered a uClibc-only bug because of this call so I would suggest >>> removing it. Glibc doesn't call _dl_debug_state until it is ready >>> to initialize directly linked and preloaded libraries. >>> >>> >> Hello Daniel, >> I'm interested to know what kind of bug you had, segfault on gdbserver ? >> or whatever, just to see if it is the same kind of strange behavior >> I've seen in the past on my uclibc. >> Let me know > > No, this shouldn't ever affect gdbserver. It crashed the program > being run once, when GDB thought it was in ARM mode instead of Thumb. > And more recently GDB just disabled the _dl_debug_state breakpoint, > which breaks debugging of dlopen. > Merged in r21077. Thanks Carmelo From ricard.wanderlof at axis.com Thu Feb 21 06:30:19 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Thu, 21 Feb 2008 15:30:19 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work Message-ID: We experienced a problem with a product when IPv6 is compiled into the product (and uClibc) but selectively disabled by a user. In this case, IPv6 traffic was still be generated, which in this particular case was not acceptable. The problem turned out to be in getaddrinfo(). When hints.ai_flags has the AI_ADDRCONFIG bit set in a call to getaddrinfo, IPv4 and IPv6 addresses should only be returned if the system as at least one address of the appropriate type configured. However, this turned out not to be the case, and both types of addresses were returned in any case, causing IPv6 DNS traffic even if no interface had an IPv6 address configured. The following patch fixes the problem, while still touching the existing code as little as possible. It has been tested and works and I would like to commit it, but comments would be valued. I've also included the patch as an attachement. It was made against svn 21085, head of the development tree att the time of writing. Some comments on the changes: First of all, two new functions ipv4_available() and ipv6_available() check if ipv4 or ipb6 is enabled. For ipv6, /proc/net/if_inet6 is checked. For ipv4 there is no corresponding file, instead /proc/net/route is checked to determine there is a route defined (i.e. the file has one more line with data besides the header line), as this indicates ipv4 is available. The addrconfig() and gaih_inet() functions have then been modified to use these two functions when AF_INET or AF_INET6 is specified, respectively. For addrconfig() it has been noted that just being able to create a SOCK_DGRAM socket of the corresponding address family type is not enough to determine the existence of correspondingly configured interfaces. The final block in the patch fixes a bug which caused an infinite loop when hints->ai_flags had the AI_ADDRCONFIG bit set. (Perhaps this was a failed attempt att fixing the problem at some time, as the coresponding glibc version does not seem to have the corresponding if-followed-by-continue clause. It has been in the svn repo since the first entry in 2002 (svn 4414) ). /Ricard Index: libc/inet/getaddrinfo.c =================================================================== --- libc/inet/getaddrinfo.c (revision 21085) +++ libc/inet/getaddrinfo.c (working copy) @@ -165,20 +165,72 @@ { 0, PF_UNSPEC, 0, 0, 0, NULL, NULL, NULL }; #endif +static int ipv4_available(void) { + int fd; + size_t bytes = 1; + void *pos; + char buf[10]; + int firstline = 1; + int routefound = 0; + fd = open("/proc/net/route", O_RDONLY); + // If proc is not mounted assume IPv4 is available + if (fd < 0) + return 1; + + while (routefound == 0 && bytes > 0) + { + bytes = read(fd, buf, sizeof(buf)); + pos = memchr(buf, '\n', bytes); + if (pos != NULL) + if (!firstline) + routefound = 1; + else + firstline = 0; + } + close(fd); + return routefound; +} + +#if __UCLIBC_HAS_IPV6__ +static int ipv6_available(void) { + int fd; + size_t bytes = 0; + char buf[1]; + + fd = open("/proc/net/if_inet6", O_RDONLY); + // If proc is not mounted assume IPv4 is available + if (fd < 0) + return 1; + + bytes = read(fd, buf, sizeof(buf)); + close(fd); + return (bytes > 0) ? 1 : 0; +} +#endif + 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; - else - { - close(s); - ret = 1; + if (af == AF_INET) + ret = ipv4_available(); +#if __UCLIBC_HAS_IPV6__ + else if (af == AF_INET6) + ret = ipv6_available(); +#endif + 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; } @@ -383,6 +435,11 @@ int v4mapped = (req->ai_family == PF_UNSPEC || req->ai_family == PF_INET6) && (req->ai_flags & AI_V4MAPPED); +#if __UCLIBC_HAS_IPV6__ + int ipv6 = ipv6_available(); +#endif + int ipv4 = ipv4_available(); + if (req->ai_protocol || req->ai_socktype) { ++tp; @@ -569,14 +626,16 @@ #if __UCLIBC_HAS_IPV6__ if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET6) - gethosts (AF_INET6, struct in6_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || ipv6) + gethosts (AF_INET6, struct in6_addr); #endif no_inet6_data = no_data; if (req->ai_family == AF_INET || (!v4mapped && req->ai_family == AF_UNSPEC) || (v4mapped && (no_inet6_data != 0 || (req->ai_flags & AI_ALL)))) - gethosts (AF_INET, struct in_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || ipv4) + gethosts (AF_INET, struct in_addr); if (no_data != 0 && no_inet6_data != 0) { @@ -704,6 +763,13 @@ for (st2 = st; st2 != NULL; st2 = st2->next) { + if (req->ai_flags & AI_ADDRCONFIG) + if (family == AF_INET && !ipv4) + break; +#if __UCLIBC_HAS_IPV6__ + else if (family == AF_INET6 && !ipv6) + break; +#endif *pai = malloc (sizeof (struct addrinfo) + socklen + namelen); if (*pai == NULL) return -EAI_MEMORY; @@ -862,7 +928,10 @@ if (hints->ai_family == g->family || hints->ai_family == AF_UNSPEC) { if ((hints->ai_flags & AI_ADDRCONFIG) && !addrconfig(g->family)) + { + ++g; continue; + } j++; if (pg == NULL || pg->gaih != g->gaih) { -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 -------------- next part -------------- Index: libc/inet/getaddrinfo.c =================================================================== --- libc/inet/getaddrinfo.c (revision 21085) +++ libc/inet/getaddrinfo.c (working copy) @@ -165,20 +165,72 @@ { 0, PF_UNSPEC, 0, 0, 0, NULL, NULL, NULL }; #endif +static int ipv4_available(void) { + int fd; + size_t bytes = 1; + void *pos; + char buf[10]; + int firstline = 1; + int routefound = 0; + fd = open("/proc/net/route", O_RDONLY); + // If proc is not mounted assume IPv4 is available + if (fd < 0) + return 1; + + while (routefound == 0 && bytes > 0) + { + bytes = read(fd, buf, sizeof(buf)); + pos = memchr(buf, '\n', bytes); + if (pos != NULL) + if (!firstline) + routefound = 1; + else + firstline = 0; + } + close(fd); + return routefound; +} + +#if __UCLIBC_HAS_IPV6__ +static int ipv6_available(void) { + int fd; + size_t bytes = 0; + char buf[1]; + + fd = open("/proc/net/if_inet6", O_RDONLY); + // If proc is not mounted assume IPv4 is available + if (fd < 0) + return 1; + + bytes = read(fd, buf, sizeof(buf)); + close(fd); + return (bytes > 0) ? 1 : 0; +} +#endif + 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; - else - { - close(s); - ret = 1; + if (af == AF_INET) + ret = ipv4_available(); +#if __UCLIBC_HAS_IPV6__ + else if (af == AF_INET6) + ret = ipv6_available(); +#endif + 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; } @@ -383,6 +435,11 @@ int v4mapped = (req->ai_family == PF_UNSPEC || req->ai_family == PF_INET6) && (req->ai_flags & AI_V4MAPPED); +#if __UCLIBC_HAS_IPV6__ + int ipv6 = ipv6_available(); +#endif + int ipv4 = ipv4_available(); + if (req->ai_protocol || req->ai_socktype) { ++tp; @@ -569,14 +626,16 @@ #if __UCLIBC_HAS_IPV6__ if (req->ai_family == AF_UNSPEC || req->ai_family == AF_INET6) - gethosts (AF_INET6, struct in6_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || ipv6) + gethosts (AF_INET6, struct in6_addr); #endif no_inet6_data = no_data; if (req->ai_family == AF_INET || (!v4mapped && req->ai_family == AF_UNSPEC) || (v4mapped && (no_inet6_data != 0 || (req->ai_flags & AI_ALL)))) - gethosts (AF_INET, struct in_addr); + if (!(req->ai_flags & AI_ADDRCONFIG) || ipv4) + gethosts (AF_INET, struct in_addr); if (no_data != 0 && no_inet6_data != 0) { @@ -704,6 +763,13 @@ for (st2 = st; st2 != NULL; st2 = st2->next) { + if (req->ai_flags & AI_ADDRCONFIG) + if (family == AF_INET && !ipv4) + break; +#if __UCLIBC_HAS_IPV6__ + else if (family == AF_INET6 && !ipv6) + break; +#endif *pai = malloc (sizeof (struct addrinfo) + socklen + namelen); if (*pai == NULL) return -EAI_MEMORY; @@ -862,7 +928,10 @@ if (hints->ai_family == g->family || hints->ai_family == AF_UNSPEC) { if ((hints->ai_flags & AI_ADDRCONFIG) && !addrconfig(g->family)) + { + ++g; continue; + } j++; if (pg == NULL || pg->gaih != g->gaih) { From ricard.wanderlof at axis.com Thu Feb 21 06:37:53 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Thu, 21 Feb 2008 15:37:53 +0100 (CET) Subject: [PATCH] Remove unnecessary #defines from getaddrinfo Message-ID: The following definitions in getaddrinfo.c seem redundant as they _are_ defined in the public netdb.h header, contrary to the comment. AI_DEFAULT is not, however it is not used in the file either so can be safely removed. Seems a no-brainer to me to remove them, unless anyone has any objections. /Ricard Index: libc/inet/getaddrinfo.c =================================================================== --- libc/inet/getaddrinfo.c (revision 21085) +++ libc/inet/getaddrinfo.c (working copy) @@ -90,15 +90,6 @@ libc_hidden_proto(in6addr_loopback) #endif -/* The following declarations and definitions have been removed from - * the public header since we don't want people to use them. */ -#define AI_V4MAPPED 0x0008 /* IPv4-mapped addresses are acceptable. */ -#define AI_ALL 0x0010 /* Return both IPv4 and IPv6 addresses. */ -#define AI_ADDRCONFIG 0x0020 /* Use configuration of this host to choose - returned address type. */ -#define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) - - #define GAIH_OKIFUNSPEC 0x0100 #define GAIH_EAI ~(GAIH_OKIFUNSPEC) -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 -------------- next part -------------- Index: libc/inet/getaddrinfo.c =================================================================== --- libc/inet/getaddrinfo.c (revision 21085) +++ libc/inet/getaddrinfo.c (working copy) @@ -90,15 +90,6 @@ libc_hidden_proto(in6addr_loopback) #endif -/* The following declarations and definitions have been removed from - * the public header since we don't want people to use them. */ -#define AI_V4MAPPED 0x0008 /* IPv4-mapped addresses are acceptable. */ -#define AI_ALL 0x0010 /* Return both IPv4 and IPv6 addresses. */ -#define AI_ADDRCONFIG 0x0020 /* Use configuration of this host to choose - returned address type. */ -#define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) - - #define GAIH_OKIFUNSPEC 0x0100 #define GAIH_EAI ~(GAIH_OKIFUNSPEC) From ricard.wanderlof at axis.com Thu Feb 21 08:09:23 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Thu, 21 Feb 2008 17:09:23 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <20080221151646.GA4751@real.realitydiluted.com> References: <20080221151646.GA4751@real.realitydiluted.com> Message-ID: On Thu, 21 Feb 2008, sjhill at real.realitydiluted.com wrote: >> The problem turned out to be in getaddrinfo(). When hints.ai_flags has >> the AI_ADDRCONFIG bit set in a call to getaddrinfo, IPv4 and IPv6 >> addresses should only be returned if the system as at least one address >> of the appropriate type configured. However, this turned out not to be >> the case, and both types of addresses were returned in any case, causing >> IPv6 DNS traffic even if no interface had an IPv6 address configured. >> >> The following patch fixes the problem, while still touching the existing >> code as little as possible. It has been tested and works and I would like >> to commit it, but comments would be valued. >> > How does glibc handle this? The latest (2.7) glibc (which is much newer than what uClibc is based on) has a similar way of introducing additional checks in various parts of the code. However, it relies on getifaddrs() to determine the existance of an interface instead of checking the /proc filesystem. Which as you are implying might be a better way to do it. /Ricard -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 From carmelo.amoroso at st.com Thu Feb 21 08:23:50 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 21 Feb 2008 17:23:50 +0100 Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: References: <20080221151646.GA4751@real.realitydiluted.com> Message-ID: <47BDA596.8070107@st.com> Ricard Wanderlof wrote: > On Thu, 21 Feb 2008, sjhill at real.realitydiluted.com wrote: > > >>> The problem turned out to be in getaddrinfo(). When hints.ai_flags has >>> the AI_ADDRCONFIG bit set in a call to getaddrinfo, IPv4 and IPv6 >>> addresses should only be returned if the system as at least one address >>> of the appropriate type configured. However, this turned out not to be >>> the case, and both types of addresses were returned in any case, causing >>> IPv6 DNS traffic even if no interface had an IPv6 address configured. >>> >>> The following patch fixes the problem, while still touching the existing >>> code as little as possible. It has been tested and works and I would like >>> to commit it, but comments would be valued. >>> >>> >> How does glibc handle this? >> > > The latest (2.7) glibc (which is much newer than what uClibc is based on) > has a similar way of introducing additional checks in various parts of the > code. However, it relies on getifaddrs() to determine the existance of an > interface instead of checking the /proc filesystem. > > Which as you are implying might be a better way to do it. > > /Ricard > Hi All, please note that we cannot takes code from glibc 2.7 due to licensing issues. glibc 2.7 moved to GPL v3 !!! be careful. Carmelo > -- > Ricard Wolf Wanderl?f ricardw(at)axis.com > Axis Communications AB, Lund, Sweden www.axis.com > Phone +46 46 272 2016 Fax +46 46 13 61 30 > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From sjhill at realitydiluted.com Thu Feb 21 08:35:05 2008 From: sjhill at realitydiluted.com (sjhill at realitydiluted.com) Date: Thu, 21 Feb 2008 10:35:05 -0600 Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: References: <20080221151646.GA4751@real.realitydiluted.com> Message-ID: <20080221163505.GA6186@real.realitydiluted.com> >> How does glibc handle this? > > The latest (2.7) glibc (which is much newer than what uClibc is based on) > has a similar way of introducing additional checks in various parts of > the code. However, it relies on getifaddrs() to determine the existance > of an interface instead of checking the /proc filesystem. > > Which as you are implying might be a better way to do it. > I would tend to lean that way, yes. As Carmelo points out though, we cannot copy code from glibc-2.7 due to their licensing. Is it possible to examine and then recreate something for uClibc that does things similarly? -Steve From joseph at codesourcery.com Thu Feb 21 09:13:28 2008 From: joseph at codesourcery.com (Joseph S. Myers) Date: Thu, 21 Feb 2008 17:13:28 +0000 (UTC) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <47BDA596.8070107@st.com> References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> Message-ID: On Thu, 21 Feb 2008, Carmelo AMOROSO wrote: > please note that we cannot takes code from glibc 2.7 due to licensing > issues. > glibc 2.7 moved to GPL v3 !!! be careful. No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC has got suitable wording from the FSF for an exception to allow GPLv2-only programs to continue to be linked with LGPLv3 glibc, and the FSF is being extremely slow about producing wording for any GPLv3 exceptions at all. -- Joseph S. Myers joseph at codesourcery.com From sjhill at realitydiluted.com Thu Feb 21 09:56:31 2008 From: sjhill at realitydiluted.com (sjhill at realitydiluted.com) Date: Thu, 21 Feb 2008 11:56:31 -0600 Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> Message-ID: <20080221175631.GA7161@real.realitydiluted.com> On Thu, Feb 21, 2008 at 05:13:28PM +0000, Joseph S. Myers wrote: > > No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC > has got suitable wording from the FSF for an exception to allow GPLv2-only > programs to continue to be linked with LGPLv3 glibc, and the FSF is being > extremely slow about producing wording for any GPLv3 exceptions at all. > Cool, thanks for the info Joe! So...Ricard go snag the code from glibc :). -Steve From ricard.wanderlof at axis.com Fri Feb 22 04:08:08 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Fri, 22 Feb 2008 13:08:08 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <20080221163505.GA6186@real.realitydiluted.com> References: <20080221151646.GA4751@real.realitydiluted.com> <20080221163505.GA6186@real.realitydiluted.com> Message-ID: On Thu, 21 Feb 2008, sjhill at realitydiluted.com wrote: >>> How does glibc handle this? >> >> The latest (2.7) glibc (which is much newer than what uClibc is based on) >> has a similar way of introducing additional checks in various parts of >> the code. However, it relies on getifaddrs() to determine the existance >> of an interface instead of checking the /proc filesystem. >> >> Which as you are implying might be a better way to do it. >> > I would tend to lean that way, yes. As Carmelo points out though, we > cannot copy code from glibc-2.7 due to their licensing. Is it possible > to examine and then recreate something for uClibc that does things > similarly? Regardless of licensing issues, if it works it might be possible to copy the essence of the glibc-2.7 function by using getifaddrs(). I will investigate. /Ricard -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 From ricard.wanderlof at axis.com Fri Feb 22 06:08:23 2008 From: ricard.wanderlof at axis.com (Ricard Wanderlof) Date: Fri, 22 Feb 2008 15:08:23 +0100 (CET) Subject: [PATCH] make getaddrinfo hint AI_ADDRCONFIG work In-Reply-To: <20080221175631.GA7161@real.realitydiluted.com> References: <20080221151646.GA4751@real.realitydiluted.com> <47BDA596.8070107@st.com> <20080221175631.GA7161@real.realitydiluted.com> Message-ID: On Thu, 21 Feb 2008, sjhill at realitydiluted.com wrote: > On Thu, Feb 21, 2008 at 05:13:28PM +0000, Joseph S. Myers wrote: >> >> No, glibc hasn't moved to GPLv3 yet. It's not moving until the glibc SC >> has got suitable wording from the FSF for an exception to allow GPLv2-only >> programs to continue to be linked with LGPLv3 glibc, and the FSF is being >> extremely slow about producing wording for any GPLv3 exceptions at all. >> > Cool, thanks for the info Joe! So...Ricard go snag the code from > glibc :). Have just looked a trifle at it, seems like glibc relies on the getifaddrs() in libc/inet/ifaddrs.c, but that function and other parts of the file have been #if 0'd out as they weren't the reason the file was lifted into uClibc in the first place. While I hope it's possible to reinstate the missing parts (including two ifaddrs.h files which uClibc doesn't yet have), one issue might be that it increases the code size perhaps unnecessarily for many users. Perhaps the whole fix should be a selectable option in the config if this is the case? /Ricard -- Ricard Wolf Wanderl?f ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 From alec at sensi.org Fri Feb 22 07:23:46 2008 From: alec at sensi.org (Alexander Voropay) Date: Fri, 22 Feb 2008 18:23:46 +0300 Subject: uclibc and mips32r2 In-Reply-To: References: Message-ID: <347d9b1b0802220723l23214017i8a1f3d60e579fcc9@mail.gmail.com> 2008/2/19, Mile Davidovic : > Hello, > is ti possible to build uClibC with MIPS32R2 and EABI as used ABI? No, it's impossible. There is no EABI ELF for the MIPS architecture, it's ARM-spacific. Only O32, N32 and N64 ELFs are available for MIPS (BE and LE variants) http://www.linux-mips.org/wiki/ELF http://www.linux-mips.org/wiki/MIPSABIHistory Just change an ABI in the "menu config". The bug is opened, but not resolved yet http://busybox.net/bugs/view.php?id=1889 -- -=AV=- From drow at false.org Fri Feb 22 07:34:48 2008 From: drow at false.org (Daniel Jacobowitz) Date: Fri, 22 Feb 2008 10:34:48 -0500 Subject: uclibc and mips32r2 In-Reply-To: <347d9b1b0802220723l23214017i8a1f3d60e579fcc9@mail.gmail.com> References: <347d9b1b0802220723l23214017i8a1f3d60e579fcc9@mail.gmail.com> Message-ID: <20080222153448.GA28434@caradoc.them.org> On Fri, Feb 22, 2008 at 06:23:46PM +0300, Alexander Voropay wrote: > 2008/2/19, Mile Davidovic : > > Hello, > > is ti possible to build uClibC with MIPS32R2 and EABI as used ABI? > > No, it's impossible. There is no EABI ELF for the MIPS architecture, > it's ARM-spacific. > Only O32, N32 and N64 ELFs a