From bugs at busybox.net Sun Oct 7 16:35:50 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sun, 7 Oct 2007 16:35:50 -0700 Subject: [uClibc 0000101]: Implementation of backtrace() from glibc would be useful Message-ID: <78164ca8f31788e6b621ce949758b7f2@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=101 ====================================================================== Reported By: hgb Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 101 Category: New Features Reproducibility: N/A Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 02-14-2005 02:09 PST Last Modified: 10-07-2007 16:35 PDT ====================================================================== Summary: Implementation of backtrace() from glibc would be useful Description: The backtrace() function (and its friends backtrace_symbols() and backtrace_symbols_fd()) would be a very welcome addition to uClibc. I have no idea how hard it is to implement, but if it's not-that-hard, I would at least consider it a very useful addition. It is excellent for debugging. ====================================================================== ---------------------------------------------------------------------- enaess - 10-07-07 16:35 ---------------------------------------------------------------------- Note for: uclibc-backtrace.tar.bz2 Hi, I added backtrace support for uClibc 0.9.28 for both x86 and arm/xscale. For the latter platform, you may need to tweak your compiler settings to use -mapcs (arm procedure calling standard). This adds a bit overhead on a per-function call basis but does the trick. Have a nice day! - Eivind Issue History Date Modified Username Field Change ====================================================================== 02-14-05 02:09 hgb New Issue 03-16-05 11:55 andersen Assigned To andersen => uClibc 10-07-07 16:32 enaess File Added: uclibc-backtrace.tar.bz2 10-07-07 16:35 enaess Note Added: 0002813 ====================================================================== From vapier at uclibc.org Sun Oct 7 19:03:49 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Sun, 7 Oct 2007 19:03:49 -0700 (PDT) Subject: svn commit: trunk/uClibc/ldso/ldso Message-ID: <20071008020349.396AFA6ABD@busybox.net> Author: vapier Date: 2007-10-07 19:03:48 -0700 (Sun, 07 Oct 2007) New Revision: 20204 Log: Do string comparisos as late as possible during symbol lookup. Signed-off-by: Carmelo Amoroso Modified: trunk/uClibc/ldso/ldso/dl-hash.c Changeset: Modified: trunk/uClibc/ldso/ldso/dl-hash.c =================================================================== --- trunk/uClibc/ldso/ldso/dl-hash.c 2007-10-07 21:06:51 UTC (rev 20203) +++ trunk/uClibc/ldso/ldso/dl-hash.c 2007-10-08 02:03:48 UTC (rev 20204) @@ -175,12 +175,12 @@ if (type_class & (sym->st_shndx == SHN_UNDEF)) continue; - if (_dl_strcmp(strtab + sym->st_name, name) != 0) - continue; if (sym->st_value == 0) continue; if (ELF_ST_TYPE(sym->st_info) > STT_FUNC) continue; + if (_dl_strcmp(strtab + sym->st_name, name) != 0) + continue; switch (ELF_ST_BIND(sym->st_info)) { case STB_WEAK: From aldot at uclibc.org Sat Oct 13 07:41:47 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Sat, 13 Oct 2007 07:41:47 -0700 (PDT) Subject: svn commit: trunk/uClibc Message-ID: <20071013144147.86BB3A45EE@busybox.net> Author: aldot Date: 2007-10-13 07:41:46 -0700 (Sat, 13 Oct 2007) New Revision: 20240 Log: - allow for passing in UCLIBC_EXTRA_LDFLAGS Modified: trunk/uClibc/Rules.mak Changeset: Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-10-13 10:15:01 UTC (rev 20239) +++ trunk/uClibc/Rules.mak 2007-10-13 14:41:46 UTC (rev 20240) @@ -368,6 +368,10 @@ CFLAGS += $(subst ",, $(UCLIBC_EXTRA_CFLAGS)) endif +ifneq ($(strip $(UCLIBC_EXTRA_LDFLAGS)),"") +LDFLAGS += $(subst ",, $(UCLIBC_EXTRA_LDFLAGS)) +endif + LDADD_LIBFLOAT= ifeq ($(UCLIBC_HAS_SOFT_FLOAT),y) # If -msoft-float isn't supported, we want an error anyway. From aldot at uclibc.org Sat Oct 13 07:50:47 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Sat, 13 Oct 2007 07:50:47 -0700 (PDT) Subject: svn commit: trunk/uClibc: ldso/ldso ldso/libdl libc libpthread/li etc... Message-ID: <20071013145047.4523EA45EB@busybox.net> Author: aldot Date: 2007-10-13 07:50:43 -0700 (Sat, 13 Oct 2007) New Revision: 20241 Log: - use the compiler-driver instead of the linker - adjust setting flags accordingly to use (hardcoded, see below) -Wl, Potential improvements: *) --warn-unresolved-symbols should perhaps be used for all libs *) eventually rename LDFLAGS to CC_LDFLAGS *) probe for compiler driver's notion of flag to use for passing in linker flags (i.e. don't hardcode "-Wl,") Modified: trunk/uClibc/Makerules trunk/uClibc/Rules.mak trunk/uClibc/TODO trunk/uClibc/ldso/ldso/Makefile.in trunk/uClibc/ldso/libdl/Makefile.in trunk/uClibc/libc/Makefile.in trunk/uClibc/libpthread/linuxthreads.old/Makefile.in trunk/uClibc/libpthread/linuxthreads.old_db/Makefile.in trunk/uClibc/libpthread/linuxthreads/Makefile.in trunk/uClibc/libpthread/linuxthreads_db/Makefile.in Changeset: Modified: trunk/uClibc/Makerules =================================================================== --- trunk/uClibc/Makerules 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/Makerules 2007-10-13 14:50:43 UTC (rev 20241) @@ -126,9 +126,9 @@ $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $@ $@.$(2) $(dir $@)$(1) @$(disp_ld) - $(Q)$(LD) $(LDFLAGS-$(notdir $@)) -soname=$(notdir $@).$(2) \ - -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ - --whole-archive $(firstword $^) --no-whole-archive \ + $(Q)$(CC) $(LDFLAGS-$(notdir $@)) -Wl,-soname=$(notdir $@).$(2) \ + -nostdlib -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ + -Wl,--whole-archive $(firstword $^) -Wl,--no-whole-archive \ $(LIBS-$(notdir $@)) $(LIBGCC) $(END_FILE-$(notdir $@)) $(Q)$(LN) -sf $(1) $@.$(2) $(Q)$(LN) -sf $(1) $@ @@ -150,10 +150,10 @@ $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $(1) $@ @$(disp_ld) - $(Q)$(LD) $(LDFLAGS-$(notdir $@)) -o $(1) \ - -elf2flt -shared-lib-id $(2) $(top_builddir)lib/Scrt1.o \ - $(top_builddir)/lib/crti.o --whole-archive $(firstword $^) \ - --no-whole-archive $(LIBS-$(notdir $@)) $(LIBGCC) \ + $(Q)$(CC) $(LDFLAGS-$(notdir $@)) -nostdlib -o $(1) \ + -Wl,-elf2flt -Wl,-shared-lib-id $(2) $(top_builddir)lib/Scrt1.o \ + $(top_builddir)/lib/crti.o -Wl,--whole-archive $(firstword $^) \ + -Wl,--no-whole-archive $(LIBS-$(notdir $@)) $(LIBGCC) \ $(top_builddir)/lib/crtn.o endef @@ -161,8 +161,8 @@ $(Q)$(INSTALL) -d $(dir $@) $(Q)$(RM) $@ $@.$(2) $(dir $@)$(1) @$(disp_ld) - $(Q)$(LD) $(LDFLAGS-$(notdir $@)) -soname=$(notdir $@).$(2) \ - -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) $^ \ + $(Q)$(CC) $(LDFLAGS-$(notdir $@)) -Wl,-soname=$(notdir $@).$(2) \ + -nostdlib -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) $^ \ $(LIBS-$(notdir $@)) $(LIBGCC) $(END_FILE-$(notdir $@)) $(Q)$(LN) -sf $(1) $@.$(2) $(Q)$(LN) -sf $(1) $@ Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/Rules.mak 2007-10-13 14:50:43 UTC (rev 20241) @@ -117,6 +117,9 @@ ldso := endif +comma:=, +space:= # + ifndef CROSS CROSS=$(subst ",, $(strip $(CROSS_COMPILER_PREFIX))) endif @@ -192,8 +195,8 @@ ifeq ($(TARGET_ARCH),arm) OPTIMIZATION+=-fstrict-aliasing - CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-EL - CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-EB + CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-Wl,-EL + CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-Wl,-EB CPU_CFLAGS-$(ARCH_LITTLE_ENDIAN)+=-mlittle-endian CPU_CFLAGS-$(ARCH_BIG_ENDIAN)+=-mbig-endian CPU_CFLAGS-$(CONFIG_GENERIC_ARM)+= @@ -216,8 +219,8 @@ endif ifeq ($(TARGET_ARCH),mips) - CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-EL - CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-EB + CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-Wl,-EL + CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-Wl,-EB CPU_CFLAGS-$(CONFIG_MIPS_ISA_1)+=-mips1 CPU_CFLAGS-$(CONFIG_MIPS_ISA_2)+=-mips2 -mtune=mips2 CPU_CFLAGS-$(CONFIG_MIPS_ISA_3)+=-mips3 -mtune=mips3 @@ -225,12 +228,12 @@ CPU_CFLAGS-$(CONFIG_MIPS_ISA_MIPS32)+=-mips32 -mtune=mips32 CPU_CFLAGS-$(CONFIG_MIPS_ISA_MIPS64)+=-mips64 -mtune=mips32 ifeq ($(strip $(ARCH_BIG_ENDIAN)),y) - CPU_LDFLAGS-$(CONFIG_MIPS_N64_ABI)+=-melf64btsmip - CPU_LDFLAGS-$(CONFIG_MIPS_O32_ABI)+=-melf32btsmip + CPU_LDFLAGS-$(CONFIG_MIPS_N64_ABI)+=-Wl,-melf64btsmip + CPU_LDFLAGS-$(CONFIG_MIPS_O32_ABI)+=-Wl,-melf32btsmip endif ifeq ($(strip $(ARCH_LITTLE_ENDIAN)),y) - CPU_LDFLAGS-$(CONFIG_MIPS_N64_ABI)+=-melf64ltsmip - CPU_LDFLAGS-$(CONFIG_MIPS_O32_ABI)+=-melf32ltsmip + CPU_LDFLAGS-$(CONFIG_MIPS_N64_ABI)+=-Wl,-melf64ltsmip + CPU_LDFLAGS-$(CONFIG_MIPS_O32_ABI)+=-Wl,-melf32ltsmip endif CPU_CFLAGS-$(CONFIG_MIPS_N64_ABI)+=-mabi=64 CPU_CFLAGS-$(CONFIG_MIPS_O32_ABI)+=-mabi=32 @@ -238,15 +241,15 @@ endif ifeq ($(TARGET_ARCH),nios) - CPU_LDFLAGS-y+=-m32 - CPU_CFLAGS-y+=-m32 + CPU_LDFLAGS-y+=-Wl,-m32 + CPU_CFLAGS-y+=-Wl,-m32 endif ifeq ($(TARGET_ARCH),sh) OPTIMIZATION+=-fstrict-aliasing OPTIMIZATION+= $(call check_gcc,-mprefergot,) - CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-EL - CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-EB + CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN)+=-Wl,-EL + CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+=-Wl,-EB CPU_CFLAGS-$(ARCH_LITTLE_ENDIAN)+=-ml CPU_CFLAGS-$(ARCH_BIG_ENDIAN)+=-mb CPU_CFLAGS-$(CONFIG_SH2)+=-m2 @@ -262,23 +265,23 @@ ifeq ($(TARGET_ARCH),sh64) OPTIMIZATION+=-fstrict-aliasing - CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN):=-EL - CPU_LDFLAGS-$(ARCH_BIG_ENDIAN):=-EB + CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN):=-Wl,-EL + CPU_LDFLAGS-$(ARCH_BIG_ENDIAN):=-Wl,-EB CPU_CFLAGS-$(ARCH_LITTLE_ENDIAN):=-ml CPU_CFLAGS-$(ARCH_BIG_ENDIAN):=-mb CPU_CFLAGS-$(CONFIG_SH5)+=-m5-32media endif ifeq ($(TARGET_ARCH),h8300) - CPU_LDFLAGS-$(CONFIG_H8300H)+= -ms8300h - CPU_LDFLAGS-$(CONFIG_H8S) += -ms8300s + CPU_LDFLAGS-$(CONFIG_H8300H)+= -Wl,-ms8300h + CPU_LDFLAGS-$(CONFIG_H8S) += -Wl,-ms8300s CPU_CFLAGS-$(CONFIG_H8300H) += -mh -mint32 CPU_CFLAGS-$(CONFIG_H8S) += -ms -mint32 endif ifeq ($(TARGET_ARCH),cris) - CPU_LDFLAGS-$(CONFIG_CRIS)+=-mcrislinux - CPU_LDFLAGS-$(CONFIG_CRISV32)+=-mcrislinux + CPU_LDFLAGS-$(CONFIG_CRIS)+=-Wl,-mcrislinux + CPU_LDFLAGS-$(CONFIG_CRISV32)+=-Wl,-mcrislinux CPU_CFLAGS-$(CONFIG_CRIS)+=-mlinux PICFLAG:=-fpic PIEFLAG_NAME:=-fpie @@ -304,13 +307,13 @@ endif ifeq ($(TARGET_ARCH),frv) - CPU_LDFLAGS-$(CONFIG_FRV)+=-melf32frvfd + CPU_LDFLAGS-$(CONFIG_FRV)+=-Wl,-melf32frvfd # Using -pie causes the program to have an interpreter, which is # forbidden, so we must make do with -shared. Unfortunately, # -shared by itself would get us global function descriptors # and calls through PLTs, dynamic resolution of symbols, etc, # which would break as well, but -Bsymbolic comes to the rescue. - export LDPIEFLAG:=-shared -Bsymbolic + export LDPIEFLAG:=-Wl,-shared -Wl,-Bsymbolic UCLIBC_LDSO=ld.so.1 endif @@ -396,19 +399,20 @@ CFLAGS += $(call check_gcc,-std=gnu99,) -LDFLAGS_NOSTRIP:=$(CPU_LDFLAGS-y) -shared --warn-common --warn-once -z combreloc +LDFLAGS_NOSTRIP:=$(CPU_LDFLAGS-y) -Wl,-shared \ + -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc # binutils-2.16.1 warns about ignored sections, 2.16.91.0.3 and newer are ok #LDFLAGS_NOSTRIP+=$(call check_ld,--gc-sections) ifeq ($(UCLIBC_BUILD_RELRO),y) -LDFLAGS_NOSTRIP+=-z relro +LDFLAGS_NOSTRIP+=-Wl,-z,relro endif ifeq ($(UCLIBC_BUILD_NOW),y) -LDFLAGS_NOSTRIP+=-z now +LDFLAGS_NOSTRIP+=-Wl,-z,now endif -LDFLAGS:=$(LDFLAGS_NOSTRIP) -z defs +LDFLAGS:=$(LDFLAGS_NOSTRIP) -Wl,-z,defs ifeq ($(DODEBUG),y) #CFLAGS += -g3 CFLAGS += -O0 -g3 @@ -416,7 +420,7 @@ CFLAGS += $(OPTIMIZATION) $(XARCH_CFLAGS) endif ifeq ($(DOSTRIP),y) -LDFLAGS += -s +LDFLAGS += -Wl,-s else STRIPTOOL := true -Stripping_disabled endif Modified: trunk/uClibc/TODO =================================================================== --- trunk/uClibc/TODO 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/TODO 2007-10-13 14:50:43 UTC (rev 20241) @@ -39,8 +39,6 @@ *) Should integrate test subdir better ... need to propagate CPU CFLAGS/LDFLAGS to the build/link for target binaries so that when we have a multilib toolchain, the proper ABI is selected. - *) LD/LDFLAGS handling is broken ... stop invoking the linker directly and - have everything go through the compiler driver TODO list for the uClibc 1.0.0 release: Modified: trunk/uClibc/ldso/ldso/Makefile.in =================================================================== --- trunk/uClibc/ldso/ldso/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/ldso/ldso/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -20,9 +20,9 @@ ifneq ($(SUPPORT_LD_DEBUG),y) LDFLAGS-$(UCLIBC_LDSO_NAME).so := $(LDFLAGS) else -LDFLAGS-$(UCLIBC_LDSO_NAME).so := $(LDFLAGS_NOSTRIP) -z defs +LDFLAGS-$(UCLIBC_LDSO_NAME).so := $(LDFLAGS_NOSTRIP) -Wl,-z,defs endif -LDFLAGS-$(UCLIBC_LDSO_NAME).so += -e _start -z now -Bsymbolic --export-dynamic --sort-common --discard-locals --discard-all --no-undefined +LDFLAGS-$(UCLIBC_LDSO_NAME).so += -Wl,-e,_start -Wl,-z,now -Wl,-Bsymbolic -Wl,--export-dynamic -Wl,--sort-common -Wl,--discard-locals -Wl,--discard-all -Wl,--no-undefined ldso_FULL_NAME := $(UCLIBC_LDSO_NAME)-$(VERSION).so Modified: trunk/uClibc/ldso/libdl/Makefile.in =================================================================== --- trunk/uClibc/ldso/libdl/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/ldso/libdl/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -17,7 +17,7 @@ CFLAGS-libdl.c := -DLDSO_ELFINTERP=\"$(TARGET_ARCH)/elfinterp.c\" -LDFLAGS-libdl.so := $(LDFLAGS) -fini dl_cleanup +LDFLAGS-libdl.so := $(LDFLAGS) -Wl,-fini,dl_cleanup LIBS-libdl.so := $(LIBS) $(ldso) Modified: trunk/uClibc/libc/Makefile.in =================================================================== --- trunk/uClibc/libc/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/libc/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -12,10 +12,10 @@ # libc, and if so, include it when linking. VERSION_SCRIPT := $(wildcard $(libc_DIR)/sysdeps/linux/$(TARGET_ARCH)/libc.map) ifneq ($(VERSION_SCRIPT),) -VERSION_SCRIPT := --version-script $(VERSION_SCRIPT) +VERSION_SCRIPT := -Wl,--version-script,$(VERSION_SCRIPT) endif -LDFLAGS-libc.so := $(LDFLAGS) $(VERSION_SCRIPT) -init __uClibc_init +LDFLAGS-libc.so := $(LDFLAGS) $(VERSION_SCRIPT) -Wl,-init,__uClibc_init LIBS-libc.so := $(interp) $(ldso) $(top_builddir)lib/$(NONSHARED_LIBNAME) Modified: trunk/uClibc/libpthread/linuxthreads/Makefile.in =================================================================== --- trunk/uClibc/libpthread/linuxthreads/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/libpthread/linuxthreads/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -19,7 +19,7 @@ #CFLAGS:=$(CFLAGS:-O0=-O1) ifeq ($(PTHREADS_DEBUG_SUPPORT),y) -LDFLAGS-libpthread.so := $(LDFLAGS_NOSTRIP) -z defs +LDFLAGS-libpthread.so := $(LDFLAGS_NOSTRIP) -Wl,-z,defs else LDFLAGS-libpthread.so := $(LDFLAGS) endif Modified: trunk/uClibc/libpthread/linuxthreads.old/Makefile.in =================================================================== --- trunk/uClibc/libpthread/linuxthreads.old/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/libpthread/linuxthreads.old/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -12,7 +12,7 @@ CFLAGS-libpthread/linuxthreads.old/sysdeps/$(TARGET_ARCH)/ := $(CFLAGS-linuxthreads.old) ifeq ($(PTHREADS_DEBUG_SUPPORT),y) -LDFLAGS-libpthread.so := $(LDFLAGS_NOSTRIP) -z defs +LDFLAGS-libpthread.so := $(LDFLAGS_NOSTRIP) -Wl,-z,defs else LDFLAGS-libpthread.so := $(LDFLAGS) endif Modified: trunk/uClibc/libpthread/linuxthreads.old_db/Makefile.in =================================================================== --- trunk/uClibc/libpthread/linuxthreads.old_db/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/libpthread/linuxthreads.old_db/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -8,9 +8,9 @@ # Get the thread include dependencies and shared object name CFLAGS-linuxthreads.old_db := -DNOT_IN_libc -DLIBPTHREAD_SO="\"libpthread.so.$(MAJOR_VERSION)\"" -LDFLAGS-libthread_db.so := $(LDFLAGS_NOSTRIP) $(call check_ld,--warn-unresolved-symbols) +LDFLAGS-libthread_db.so := $(LDFLAGS_NOSTRIP) $(if $(call check_ld,--warn-unresolved-symbols),-Wl$(comma)--warn-unresolved-symbols) ifeq ($(DOSTRIP),y) -LDFLAGS-libthread_db.so += -s +LDFLAGS-libthread_db.so += -Wl,-s endif LIBS-libthread_db.so := $(LIBS) Modified: trunk/uClibc/libpthread/linuxthreads_db/Makefile.in =================================================================== --- trunk/uClibc/libpthread/linuxthreads_db/Makefile.in 2007-10-13 14:41:46 UTC (rev 20240) +++ trunk/uClibc/libpthread/linuxthreads_db/Makefile.in 2007-10-13 14:50:43 UTC (rev 20241) @@ -8,9 +8,9 @@ # Get the thread include dependencies and shared object name CFLAGS-linuxthreads_db := -DNOT_IN_libc -DLIBPTHREAD_SO="\"libpthread.so.$(MAJOR_VERSION)\"" -LDFLAGS-libthread_db.so := $(LDFLAGS_NOSTRIP) $(call check_ld,--warn-unresolved-symbols) +LDFLAGS-libthread_db.so := $(LDFLAGS_NOSTRIP) $(if $(call check_ld,--warn-unresolved-symbols),-Wl$(comma)--warn-unresolved-symbols) ifeq ($(DOSTRIP),y) -LDFLAGS-libthread_db.so += -s +LDFLAGS-libthread_db.so += -Wl,-s endif LIBS-libthread_db.so := $(LIBS) From bugs at busybox.net Sat Oct 13 11:08:47 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sat, 13 Oct 2007 11:08:47 -0700 Subject: [uClibc 0000056]: Memory bug when loading module in Xorg Message-ID: <167716a4e14efb2b70da6cd069a19f05@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=56 ====================================================================== Reported By: thintux Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 56 Category: Architecture Specific Reproducibility: always Severity: crash Priority: normal Status: assigned ====================================================================== Date Submitted: 01-21-2005 22:21 PST Last Modified: 10-13-2007 11:08 PDT ====================================================================== Summary: Memory bug when loading module in Xorg Description: I recently updated from 0.9.24 to 0.9.27. I downloaded and compiled Xorg 6.8.1. I didn't received any errors during the build. The problem is that when I try to start X, the computer starts to get really slow and the Xorg binary takes all available memory. The binary use 100M(RES) and 700M(VIRT). The problem starts when X try to load the first module(bitmap). Instead of loading the module it starts to use a lot of "brk"'s. I received > 50000 brk's during an execution time of a few seconds. ====================================================================== ---------------------------------------------------------------------- khem - 10-13-07 11:08 ---------------------------------------------------------------------- Can you verify this problem with latest release or svn snapshot. Issue History Date Modified Username Field Change ====================================================================== 01-21-05 22:21 thintux New Issue 03-16-05 11:53 andersen Assigned To andersen => uClibc 10-13-07 11:08 khem Note Added: 0002822 ====================================================================== From aldot at uclibc.org Tue Oct 16 04:51:52 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Tue, 16 Oct 2007 04:51:52 -0700 (PDT) Subject: svn commit: trunk/uClibc Message-ID: <20071016115152.96D37A6151@busybox.net> Author: aldot Date: 2007-10-16 04:51:51 -0700 (Tue, 16 Oct 2007) New Revision: 20264 Log: - move UCLIBC_EXTRA_LDFLAGS below pinning LDFLAGS Modified: trunk/uClibc/Rules.mak Changeset: Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-10-16 10:47:27 UTC (rev 20263) +++ trunk/uClibc/Rules.mak 2007-10-16 11:51:51 UTC (rev 20264) @@ -371,10 +371,6 @@ CFLAGS += $(subst ",, $(UCLIBC_EXTRA_CFLAGS)) endif -ifneq ($(strip $(UCLIBC_EXTRA_LDFLAGS)),"") -LDFLAGS += $(subst ",, $(UCLIBC_EXTRA_LDFLAGS)) -endif - LDADD_LIBFLOAT= ifeq ($(UCLIBC_HAS_SOFT_FLOAT),y) # If -msoft-float isn't supported, we want an error anyway. @@ -440,6 +436,10 @@ DOMULTI:=n endif +ifneq ($(strip $(UCLIBC_EXTRA_LDFLAGS)),"") +LDFLAGS += $(subst ",, $(UCLIBC_EXTRA_LDFLAGS)) +endif + ifeq ($(UCLIBC_HAS_THREADS),y) ifeq ($(UCLIBC_HAS_THREADS_NATIVE),y) PTNAME := nptl From bugs at busybox.net Fri Oct 19 11:15:16 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 19 Oct 2007 11:15:16 -0700 Subject: [uClibc 0000972]: errno broken in linuxthreads.old Message-ID: <660ae1d46881fa9f495e435e30c5b452@bugs.busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=972 ====================================================================== Reported By: bsfost Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 972 Category: Posix Threads Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-27-2006 05:36 PDT Last Modified: 10-19-2007 11:15 PDT ====================================================================== Summary: errno broken in linuxthreads.old Description: I have a problem where, effectively, errno is never set in threads within applications built with uClibc (using the linuxthreads.old library). Debugging has shown that the system call (send(), in the case of the example) is made and the global/libc errno is set prior to returning to application code. The subsequent request to retrieve the error code calls into __errno_location() in the linuxthreads.old library, which finds the appropriate thread descriptor and returns (*self->p_errnop), which was never set. I didn't see anything obvious that "intended" to set the thread specific errno value based on system calls made on that thread's behalf (i.e., I would expect this in the syscall wrappers, perhaps..?), but I'm fairly new to this library so I'm not sure whether this is considered a bug, misconfiguration or simple lack of functionality. For completeness, I compared the behavior with an _old_ glibc-2.2 system which looked like it had the same general design. The application worked in this case, but I noticed that the thread_self() call (while requesting the errno value in the thread, following the failed syscall) ended up returning a pointer to the __pthread_initial_thread structure rather than the specific thread structure I assume it created when it cloned (which is what happens in uClibc's thread_self()). I also tested a quick change in uClibc by setting __pthread_manager_thread's p_errnop to '&_errno' as well as new threads created in pthread_handle_create(). This change allowed expected behavior, but it's probably not the appropriate fix. Any information on this is greatly appreciated, and let me know if I've been unclear or missed any important points. Thanks. Brian ====================================================================== ---------------------------------------------------------------------- andre_rosa - 08-23-07 17:19 ---------------------------------------------------------------------- The attached file has different behavior in mipsel platform when comparing with glibc in a regular PC. ---------------------------------------------------------------------- corp186 - 10-19-07 11:15 ---------------------------------------------------------------------- This appears to be fixed by revision 15936. I have applied the diff from 15935 to 15936 to the sources I saw this bug with and it fixed the issue for me. Issue History Date Modified Username Field Change ====================================================================== 07-27-06 05:36 bsfost New Issue 07-27-06 05:36 bsfost Status new => assigned 07-27-06 05:36 bsfost Assigned To => uClibc 08-23-07 17:11 andre_rosa Issue Monitored: andre_rosa 08-23-07 17:18 andre_rosa File Added: main3.c 08-23-07 17:19 andre_rosa Note Added: 0002680 10-19-07 11:15 corp186 Note Added: 0002834 ====================================================================== From bugs at busybox.net Fri Oct 19 11:33:14 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 19 Oct 2007 11:33:14 -0700 Subject: [uClibc 0000972]: errno broken in linuxthreads.old Message-ID: <99ef19aa4df498734250279b514d5c3d@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=972 ====================================================================== Reported By: bsfost Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 972 Category: Posix Threads Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-27-2006 05:36 PDT Last Modified: 10-19-2007 11:33 PDT ====================================================================== Summary: errno broken in linuxthreads.old Description: I have a problem where, effectively, errno is never set in threads within applications built with uClibc (using the linuxthreads.old library). Debugging has shown that the system call (send(), in the case of the example) is made and the global/libc errno is set prior to returning to application code. The subsequent request to retrieve the error code calls into __errno_location() in the linuxthreads.old library, which finds the appropriate thread descriptor and returns (*self->p_errnop), which was never set. I didn't see anything obvious that "intended" to set the thread specific errno value based on system calls made on that thread's behalf (i.e., I would expect this in the syscall wrappers, perhaps..?), but I'm fairly new to this library so I'm not sure whether this is considered a bug, misconfiguration or simple lack of functionality. For completeness, I compared the behavior with an _old_ glibc-2.2 system which looked like it had the same general design. The application worked in this case, but I noticed that the thread_self() call (while requesting the errno value in the thread, following the failed syscall) ended up returning a pointer to the __pthread_initial_thread structure rather than the specific thread structure I assume it created when it cloned (which is what happens in uClibc's thread_self()). I also tested a quick change in uClibc by setting __pthread_manager_thread's p_errnop to '&_errno' as well as new threads created in pthread_handle_create(). This change allowed expected behavior, but it's probably not the appropriate fix. Any information on this is greatly appreciated, and let me know if I've been unclear or missed any important points. Thanks. Brian ====================================================================== ---------------------------------------------------------------------- andre_rosa - 08-23-07 17:19 ---------------------------------------------------------------------- The attached file has different behavior in mipsel platform when comparing with glibc in a regular PC. ---------------------------------------------------------------------- corp186 - 10-19-07 11:15 ---------------------------------------------------------------------- This appears to be fixed by revision 15936. I have applied the diff from 15935 to 15936 to the sources I saw this bug with and it fixed the issue for me. ---------------------------------------------------------------------- andre_rosa - 10-19-07 11:33 ---------------------------------------------------------------------- Hi, Mr. corp186. Would you please post the aforementioned patch? Thank you so much! Issue History Date Modified Username Field Change ====================================================================== 07-27-06 05:36 bsfost New Issue 07-27-06 05:36 bsfost Status new => assigned 07-27-06 05:36 bsfost Assigned To => uClibc 08-23-07 17:11 andre_rosa Issue Monitored: andre_rosa 08-23-07 17:18 andre_rosa File Added: main3.c 08-23-07 17:19 andre_rosa Note Added: 0002680 10-19-07 11:15 corp186 Note Added: 0002834 10-19-07 11:33 andre_rosa Note Added: 0002835 ====================================================================== From bugs at busybox.net Fri Oct 19 12:09:21 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 19 Oct 2007 12:09:21 -0700 Subject: [uClibc 0000972]: errno broken in linuxthreads.old Message-ID: <33b69cba7e168974e138479ff8e02262@bugs.busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=972 ====================================================================== Reported By: bsfost Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 972 Category: Posix Threads Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-27-2006 05:36 PDT Last Modified: 10-19-2007 12:09 PDT ====================================================================== Summary: errno broken in linuxthreads.old Description: I have a problem where, effectively, errno is never set in threads within applications built with uClibc (using the linuxthreads.old library). Debugging has shown that the system call (send(), in the case of the example) is made and the global/libc errno is set prior to returning to application code. The subsequent request to retrieve the error code calls into __errno_location() in the linuxthreads.old library, which finds the appropriate thread descriptor and returns (*self->p_errnop), which was never set. I didn't see anything obvious that "intended" to set the thread specific errno value based on system calls made on that thread's behalf (i.e., I would expect this in the syscall wrappers, perhaps..?), but I'm fairly new to this library so I'm not sure whether this is considered a bug, misconfiguration or simple lack of functionality. For completeness, I compared the behavior with an _old_ glibc-2.2 system which looked like it had the same general design. The application worked in this case, but I noticed that the thread_self() call (while requesting the errno value in the thread, following the failed syscall) ended up returning a pointer to the __pthread_initial_thread structure rather than the specific thread structure I assume it created when it cloned (which is what happens in uClibc's thread_self()). I also tested a quick change in uClibc by setting __pthread_manager_thread's p_errnop to '&_errno' as well as new threads created in pthread_handle_create(). This change allowed expected behavior, but it's probably not the appropriate fix. Any information on this is greatly appreciated, and let me know if I've been unclear or missed any important points. Thanks. Brian ====================================================================== ---------------------------------------------------------------------- andre_rosa - 08-23-07 17:19 ---------------------------------------------------------------------- The attached file has different behavior in mipsel platform when comparing with glibc in a regular PC. ---------------------------------------------------------------------- corp186 - 10-19-07 11:15 ---------------------------------------------------------------------- This appears to be fixed by revision 15936. I have applied the diff from 15935 to 15936 to the sources I saw this bug with and it fixed the issue for me. ---------------------------------------------------------------------- andre_rosa - 10-19-07 11:33 ---------------------------------------------------------------------- Hi, Mr. corp186. Would you please post the aforementioned patch? Thank you so much! ---------------------------------------------------------------------- corp186 - 10-19-07 12:09 ---------------------------------------------------------------------- You can get the patch from "svn diff -r 15935:15936" inside the uClibc sources. I have attached the patch as well. Issue History Date Modified Username Field Change ====================================================================== 07-27-06 05:36 bsfost New Issue 07-27-06 05:36 bsfost Status new => assigned 07-27-06 05:36 bsfost Assigned To => uClibc 08-23-07 17:11 andre_rosa Issue Monitored: andre_rosa 08-23-07 17:18 andre_rosa File Added: main3.c 08-23-07 17:19 andre_rosa Note Added: 0002680 10-19-07 11:15 corp186 Note Added: 0002834 10-19-07 11:33 andre_rosa Note Added: 0002835 10-19-07 12:09 corp186 File Added: pthread-errno.patch 10-19-07 12:09 corp186 Note Added: 0002836 ====================================================================== From bugs at busybox.net Fri Oct 19 13:00:51 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 19 Oct 2007 13:00:51 -0700 Subject: [uClibc 0000972]: errno broken in linuxthreads.old Message-ID: <799641953523c9993a1b9ab912d55051@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=972 ====================================================================== Reported By: bsfost Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 972 Category: Posix Threads Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 07-27-2006 05:36 PDT Last Modified: 10-19-2007 13:00 PDT ====================================================================== Summary: errno broken in linuxthreads.old Description: I have a problem where, effectively, errno is never set in threads within applications built with uClibc (using the linuxthreads.old library). Debugging has shown that the system call (send(), in the case of the example) is made and the global/libc errno is set prior to returning to application code. The subsequent request to retrieve the error code calls into __errno_location() in the linuxthreads.old library, which finds the appropriate thread descriptor and returns (*self->p_errnop), which was never set. I didn't see anything obvious that "intended" to set the thread specific errno value based on system calls made on that thread's behalf (i.e., I would expect this in the syscall wrappers, perhaps..?), but I'm fairly new to this library so I'm not sure whether this is considered a bug, misconfiguration or simple lack of functionality. For completeness, I compared the behavior with an _old_ glibc-2.2 system which looked like it had the same general design. The application worked in this case, but I noticed that the thread_self() call (while requesting the errno value in the thread, following the failed syscall) ended up returning a pointer to the __pthread_initial_thread structure rather than the specific thread structure I assume it created when it cloned (which is what happens in uClibc's thread_self()). I also tested a quick change in uClibc by setting __pthread_manager_thread's p_errnop to '&_errno' as well as new threads created in pthread_handle_create(). This change allowed expected behavior, but it's probably not the appropriate fix. Any information on this is greatly appreciated, and let me know if I've been unclear or missed any important points. Thanks. Brian ====================================================================== ---------------------------------------------------------------------- andre_rosa - 08-23-07 17:19 ---------------------------------------------------------------------- The attached file has different behavior in mipsel platform when comparing with glibc in a regular PC. ---------------------------------------------------------------------- corp186 - 10-19-07 11:15 ---------------------------------------------------------------------- This appears to be fixed by revision 15936. I have applied the diff from 15935 to 15936 to the sources I saw this bug with and it fixed the issue for me. ---------------------------------------------------------------------- andre_rosa - 10-19-07 11:33 ---------------------------------------------------------------------- Hi, Mr. corp186. Would you please post the aforementioned patch? Thank you so much! ---------------------------------------------------------------------- corp186 - 10-19-07 12:09 ---------------------------------------------------------------------- You can get the patch from "svn diff -r 15935:15936" inside the uClibc sources. I have attached the patch as well. ---------------------------------------------------------------------- andre_rosa - 10-19-07 13:00 ---------------------------------------------------------------------- Thanks a lot for your help! I do not use SVN at this moment to track uClibc development. Issue History Date Modified Username Field Change ====================================================================== 07-27-06 05:36 bsfost New Issue 07-27-06 05:36 bsfost Status new => assigned 07-27-06 05:36 bsfost Assigned To => uClibc 08-23-07 17:11 andre_rosa Issue Monitored: andre_rosa 08-23-07 17:18 andre_rosa File Added: main3.c 08-23-07 17:19 andre_rosa Note Added: 0002680 10-19-07 11:15 corp186 Note Added: 0002834 10-19-07 11:33 andre_rosa Note Added: 0002835 10-19-07 12:09 corp186 File Added: pthread-errno.patch 10-19-07 12:09 corp186 Note Added: 0002836 10-19-07 13:00 andre_rosa Note Added: 0002842 ====================================================================== From aldot at uclibc.org Sat Oct 20 11:17:18 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Sat, 20 Oct 2007 11:17:18 -0700 (PDT) Subject: svn commit: trunk/uClibc/include Message-ID: <20071020181718.8DB57A4A3C@busybox.net> Author: aldot Date: 2007-10-20 11:17:18 -0700 (Sat, 20 Oct 2007) New Revision: 20307 Log: - commentary typo fix Modified: trunk/uClibc/include/malloc.h Changeset: Modified: trunk/uClibc/include/malloc.h =================================================================== --- trunk/uClibc/include/malloc.h 2007-10-20 18:09:53 UTC (rev 20306) +++ trunk/uClibc/include/malloc.h 2007-10-20 18:17:18 UTC (rev 20307) @@ -186,7 +186,7 @@ /* uClibc may use malloc internally in situations where user can not be * notified about out-of-memory condition. In this situation uClibc will * call __uc_malloc_failed if it is non-NULL, and retry allocation - * if it returns. If __uc_malloc_failed is NULL, uclubc will _exit(1). + * if it returns. If __uc_malloc_failed is NULL, uclibc will _exit(1). * NB: do not use stdio in __uc_malloc_failed handler! */ extern void *__uc_malloc(size_t size); extern void (*__uc_malloc_failed)(size_t size); From jocke at uclibc.org Sun Oct 21 08:36:18 2007 From: jocke at uclibc.org (jocke at uclibc.org) Date: Sun, 21 Oct 2007 08:36:18 -0700 (PDT) Subject: svn commit: trunk/uClibc/ldso/ldso Message-ID: <20071021153618.AE46CA4B6B@busybox.net> Author: jocke Date: 2007-10-21 08:36:17 -0700 (Sun, 21 Oct 2007) New Revision: 20311 Log: Handle STT_COMMON symbols too. Following binutils release will set the type of common symbols to STT_COMMON instead of STT_OBJECTS, so the dynamic linker needs to handle this type os symbols too. Same changes have been added to glibc (See: bugzilla #5104). This patch ensures the uclibc will work with later bintuils. Signed-off-by: Carmelo Amoroso Modified: trunk/uClibc/ldso/ldso/dl-hash.c Changeset: Modified: trunk/uClibc/ldso/ldso/dl-hash.c =================================================================== --- trunk/uClibc/ldso/ldso/dl-hash.c 2007-10-21 12:02:16 UTC (rev 20310) +++ trunk/uClibc/ldso/ldso/dl-hash.c 2007-10-21 15:36:17 UTC (rev 20311) @@ -177,7 +177,12 @@ continue; if (sym->st_value == 0) continue; - if (ELF_ST_TYPE(sym->st_info) > STT_FUNC) + if (ELF_ST_TYPE(sym->st_info) > STT_FUNC + && ELF_ST_TYPE(sym->st_info) != STT_COMMON) + /* Ignore all but STT_NOTYPE, STT_OBJECT, STT_FUNC + * and STT_COMMON entries since these are no + * code/data definitions + */ continue; if (_dl_strcmp(strtab + sym->st_name, name) != 0) continue; From bugs at busybox.net Mon Oct 22 08:01:32 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 22 Oct 2007 08:01:32 -0700 Subject: [uClibc 0001547]: popen(3) allows "rw" to be specified Message-ID: <97b54c05ce18629964b67928ef01d563@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1547 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1547 Category: Standards Compliance Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 10-22-2007 08:01 PDT Last Modified: 10-22-2007 08:01 PDT ====================================================================== Summary: popen(3) allows "rw" to be specified Description: Specifying "rw" as the mode to popen(3) succeeds, giving read access, but should fail, as only one mode is permitted by the standard. The attached patch fixes this. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 10-22-07 08:01 chmeee New Issue 10-22-07 08:01 chmeee Status new => assigned 10-22-07 08:01 chmeee Assigned To => uClibc 10-22-07 08:01 chmeee File Added: popen.diff ====================================================================== From bugs at busybox.net Mon Oct 22 15:03:15 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 22 Oct 2007 15:03:15 -0700 Subject: [uClibc 0001263]: Daylight Saving Time (DST) doesn't end at the correct time for the US Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1263 ====================================================================== Reported By: mikevoyt Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1263 Category: Standards Compliance Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 03-07-2007 11:55 PST Last Modified: 10-22-2007 15:03 PDT ====================================================================== Summary: Daylight Saving Time (DST) doesn't end at the correct time for the US Description: There are new rules in 2007 for Daylight Saving Time. Daylight Saving Time for 2007 beings at 2AM on 3/11, and ends at 2AM on 11/4. uClibc will start DST at the correct date/time; but it will not end at the correct time. The following test case illustrates the bug: # date -u -s 031109592007 ; date ; sleep 70 ; date Sun Mar 11 09:59:00 UTC 2007 Sun Mar 11 01:59:00 PST 2007 Sun Mar 11 03:00:10 PDT 2007 <---- GOOD: jumps an hour ahead # date -u -s 110409592007 ; date ; sleep 70 ; date Sun Nov 4 09:59:00 UTC 2007 Sun Nov 4 01:59:00 PST 2007 Sun Nov 4 02:00:10 PST 2007 <----- BAD: it should be 1:00:10 !!! ====================================================================== ---------------------------------------------------------------------- lubek - 05-10-07 07:50 ---------------------------------------------------------------------- Interestingly, the error occurs only when setting the date with -u: export TZ="PST8PDT"; date -s 110401592007; date; sleep 70; date Sun Nov 4 01:59:00 PDT 2007 Sun Nov 4 01:59:00 PDT 2007 Sun Nov 4 01:00:10 PST 2007 The short TZ form was used to show that the new rules are in effect. ---------------------------------------------------------------------- JohnAta - 10-22-07 15:03 ---------------------------------------------------------------------- The submitter's example does not show an error in DST processing. When setting the time, it was set to 1:59 PST which is an hour late since standard time has already been entered. This is because when Daylight Savings ends, time backs up an hour and repeats itself in the standard time zone so between 1 and 2, there can be two specifications: one in daylight savings and the other in standard time. So the example originally given behaved correctly in that since time had already gone back to standard time, there is no rollback pending between 1:59 PST and 2:00 PST. The example should have set the time an hour earlier like: # date -u -s 110408592007 ; date ; sleep 70 ; date Sun Nov 4 08:59:00 UTC 2007 Sun Nov 4 01:59:00 PDT 2007 Sun Nov 4 01:00:10 PST 2007 Issue History Date Modified Username Field Change ====================================================================== 03-07-07 11:55 mikevoyt New Issue 03-07-07 11:55 mikevoyt Status new => assigned 03-07-07 11:55 mikevoyt Assigned To => uClibc 05-10-07 07:50 lubek Note Added: 0002353 10-22-07 15:03 JohnAta Note Added: 0002857 ====================================================================== From bugs at busybox.net Tue Oct 23 00:18:48 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 23 Oct 2007 00:18:48 -0700 Subject: [uClibc 0001551]: Poll with zero or negative timeout Message-ID: <50a9b266a387553dbd8c56ca84ccbd44@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1551 ====================================================================== Reported By: jcdr Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1551 Category: Standards Compliance Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 10-23-2007 00:18 PDT Last Modified: 10-23-2007 00:18 PDT ====================================================================== Summary: Poll with zero or negative timeout Description: Hello, I tried to use the bug tracking system, but the "Report Issue" page never go after the "Select Project" form. So I post this patch here. The attached patch solve an issue I faced while using the libdbus-glib waiting for a D-Bus message or the end of a glib timer at the same time. This specific case of use generate a poll call with a zero timeout. On platformes with the glibc a zero timeout poll return immetiately even if there is no file descriptor event. But on platformes with uClibc a zero timeout poll block until a file descriptor event occurs. I found that the file libc/sysdeps/linux/common/poll.c only take care of positive timeout and pass a null pointer in case of a zero or negative timeout, making the zero and negative the same case: blocking. The patch alway pass a valid structure for the timeout of poll and assign acceptable timeout values for the zero and negative case by avoiding the math needed for positive timeout value. This has been tested on a Blackfin BF533 processor. Have a good day, -- Jean-Christian de Rivaz ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 10-23-07 00:18 jcdr New Issue 10-23-07 00:18 jcdr Status new => assigned 10-23-07 00:18 jcdr Assigned To => uClibc 10-23-07 00:18 jcdr File Added: poll-zero-or-negative-timeout.txt ====================================================================== From bugs at busybox.net Tue Oct 23 04:07:53 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 23 Oct 2007 04:07:53 -0700 Subject: [uClibc 0001551]: Poll with zero or negative timeout Message-ID: <60995502b2c04691ae7f03ddfe044d4c@busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1551 ====================================================================== Reported By: jcdr Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1551 Category: Standards Compliance Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 10-23-2007 00:18 PDT Last Modified: 10-23-2007 04:07 PDT ====================================================================== Summary: Poll with zero or negative timeout Description: Hello, I tried to use the bug tracking system, but the "Report Issue" page never go after the "Select Project" form. So I post this patch here. The attached patch solve an issue I faced while using the libdbus-glib waiting for a D-Bus message or the end of a glib timer at the same time. This specific case of use generate a poll call with a zero timeout. On platformes with the glibc a zero timeout poll return immetiately even if there is no file descriptor event. But on platformes with uClibc a zero timeout poll block until a file descriptor event occurs. I found that the file libc/sysdeps/linux/common/poll.c only take care of positive timeout and pass a null pointer in case of a zero or negative timeout, making the zero and negative the same case: blocking. The patch alway pass a valid structure for the timeout of poll and assign acceptable timeout values for the zero and negative case by avoiding the math needed for positive timeout value. This has been tested on a Blackfin BF533 processor. Have a good day, -- Jean-Christian de Rivaz ====================================================================== ---------------------------------------------------------------------- jcdr - 10-23-07 04:07 ---------------------------------------------------------------------- Joakim Tjernlund a ?crit : > And why not pass NULL as it was before? The man 2 ppoll say: "If timeout is specified as NULL, then ppoll() can block indefinitely." So you are right, it's possible to passe a null pointer to do the same as negative value. The poll-zero-timeout.txt patch improve this. Issue History Date Modified Username Field Change ====================================================================== 10-23-07 00:18 jcdr New Issue 10-23-07 00:18 jcdr Status new => assigned 10-23-07 00:18 jcdr Assigned To => uClibc 10-23-07 00:18 jcdr File Added: poll-zero-or-negative-timeout.txt 10-23-07 00:49 jcdr Issue Monitored: jcdr 10-23-07 04:06 jcdr File Added: poll-zero-timeout.txt 10-23-07 04:07 jcdr Note Added: 0002858 ====================================================================== From jocke at uclibc.org Tue Oct 23 04:47:01 2007 From: jocke at uclibc.org (jocke at uclibc.org) Date: Tue, 23 Oct 2007 04:47:01 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/sysdeps/linux/common Message-ID: <20071023114701.14EEAA4A3E@busybox.net> Author: jocke Date: 2007-10-23 04:47:01 -0700 (Tue, 23 Oct 2007) New Revision: 20318 Log: Poll with zero timeout Jean-Christian de Rivaz writes: The attached patch solve an issue I faced while using the libdbus-glib waiting for a D-Bus message or the end of a glib timer at the same time. This specific case of use generate a poll call with a zero timeout. On platformes with the glibc a zero timeout poll return immetiately even if there is no file descriptor event. But on platformes with uClibc a zero timeout poll block until a file descriptor event occurs. Modified: trunk/uClibc/libc/sysdeps/linux/common/poll.c Changeset: Modified: trunk/uClibc/libc/sysdeps/linux/common/poll.c =================================================================== --- trunk/uClibc/libc/sysdeps/linux/common/poll.c 2007-10-23 09:49:56 UTC (rev 20317) +++ trunk/uClibc/libc/sysdeps/linux/common/poll.c 2007-10-23 11:47:01 UTC (rev 20318) @@ -38,6 +38,10 @@ tval.tv_sec = timeout / 1000; tval.tv_nsec = (timeout % 1000) * 1000000; ts = &tval; + } else if (timeout == 0) { + tval.tv_sec = 0; + tval.tv_nsec = 0; + ts = &tval; } return ppoll(fds, nfds, ts, NULL); } From bugs at busybox.net Tue Oct 23 11:07:57 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 23 Oct 2007 11:07:57 -0700 Subject: [uClibc 0001551]: Poll with zero or negative timeout Message-ID: <98bacfc8ef8a41d5d818749918ff1af6@busybox.net> The following issue has been RESOLVED. ====================================================================== http://busybox.net/bugs/view.php?id=1551 ====================================================================== Reported By: jcdr Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1551 Category: Standards Compliance Reproducibility: always Severity: block Priority: normal Status: resolved Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 10-23-2007 00:18 PDT Last Modified: 10-23-2007 11:07 PDT ====================================================================== Summary: Poll with zero or negative timeout Description: Hello, I tried to use the bug tracking system, but the "Report Issue" page never go after the "Select Project" form. So I post this patch here. The attached patch solve an issue I faced while using the libdbus-glib waiting for a D-Bus message or the end of a glib timer at the same time. This specific case of use generate a poll call with a zero timeout. On platformes with the glibc a zero timeout poll return immetiately even if there is no file descriptor event. But on platformes with uClibc a zero timeout poll block until a file descriptor event occurs. I found that the file libc/sysdeps/linux/common/poll.c only take care of positive timeout and pass a null pointer in case of a zero or negative timeout, making the zero and negative the same case: blocking. The patch alway pass a valid structure for the timeout of poll and assign acceptable timeout values for the zero and negative case by avoiding the math needed for positive timeout value. This has been tested on a Blackfin BF533 processor. Have a good day, -- Jean-Christian de Rivaz ====================================================================== ---------------------------------------------------------------------- jcdr - 10-23-07 04:07 ---------------------------------------------------------------------- Joakim Tjernlund a ?crit : > And why not pass NULL as it was before? The man 2 ppoll say: "If timeout is specified as NULL, then ppoll() can block indefinitely." So you are right, it's possible to passe a null pointer to do the same as negative value. The poll-zero-timeout.txt patch improve this. ---------------------------------------------------------------------- jocke - 10-23-07 11:07 ---------------------------------------------------------------------- fixed in uClibc trunk Issue History Date Modified Username Field Change ====================================================================== 10-23-07 00:18 jcdr New Issue 10-23-07 00:18 jcdr Status new => assigned 10-23-07 00:18 jcdr Assigned To => uClibc 10-23-07 00:18 jcdr File Added: poll-zero-or-negative-timeout.txt 10-23-07 00:49 jcdr Issue Monitored: jcdr 10-23-07 04:06 jcdr File Added: poll-zero-timeout.txt 10-23-07 04:07 jcdr Note Added: 0002858 10-23-07 11:07 jocke Status assigned => resolved 10-23-07 11:07 jocke Resolution open => fixed 10-23-07 11:07 jocke Note Added: 0002859 ====================================================================== From aldot at uclibc.org Wed Oct 24 15:29:31 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Wed, 24 Oct 2007 15:29:31 -0700 (PDT) Subject: svn commit: trunk/uClibc/extra/config Message-ID: <20071024222931.B2498A479B@busybox.net> Author: aldot Date: 2007-10-24 15:29:30 -0700 (Wed, 24 Oct 2007) New Revision: 20320 Log: - fix order of link-flags On cygwin one has to pass make menuconfig HOST_LOADLIBES="-lcurses -lintl" otherwise just curses is linked in and some symbols that live in intl are unresolved. Closes #1554 and possibly a couple of other reports. Modified: trunk/uClibc/extra/config/Makefile Changeset: Modified: trunk/uClibc/extra/config/Makefile =================================================================== --- trunk/uClibc/extra/config/Makefile 2007-10-23 23:01:04 UTC (rev 20319) +++ trunk/uClibc/extra/config/Makefile 2007-10-24 22:29:30 UTC (rev 20320) @@ -18,10 +18,10 @@ host-cobjs := $(sort $(foreach m,$(__hostprogs),$($(m)-objs))) $(host-csingle): %: %.c - $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $(HOST_LOADLIBES) $< -o $@ + $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $< $(HOST_LOADLIBES) -o $@ $(host-cmulti): %: $(host-cobjs) $(host-cshlib) - $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $(HOST_LOADLIBES) $($@-objs) -o $@ + $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) $($@-objs) $(HOST_LOADLIBES) -o $@ $(host-cobjs): %.o: %.c $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTCFLAGS) $(HOSTCFLAGS_$@) -c $< -o $@ From bugs at busybox.net Tue Oct 30 10:22:29 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 30 Oct 2007 10:22:29 -0700 Subject: [uClibc 0000710]: /bin/ls fails to accept args Message-ID: The following issue has been CLOSED ====================================================================== http://busybox.net/bugs/view.php?id=710 ====================================================================== Reported By: hufnus Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 710 Category: Other Reproducibility: always Severity: major Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 02-09-2006 12:32 PST Last Modified: 10-30-2007 10:22 PDT ====================================================================== Summary: /bin/ls fails to accept args Description: This bug does not appear if the same buildroot snapshot everything is used, but building with uclibc 0.9.27 instead of 0.9.28! Bug reflects itself on the argument parsing of non-busybox mapped function ls (coreutils-5.3.0). ls -CatX reports file not found ls --color=always reports file not found ls -CatX --color reports file not found ls --color=always * succeeds ls . -CatX succeeds ls succeeds Probably affects other /bin's of the coreutils 5.3.0? (other not tested) Env: buildroot snapshots 01/28, 2/08/06 uclibc 0.9.28 bash 3.0 binutils 2.15.94.0.2.2 gcc 3.4.5 (and 3.4.3) kernel headers 2.4.29 If I just rebuild using the same everything, but replace with: uclibc 0.9.27 then ls functions correctly! ====================================================================== ---------------------------------------------------------------------- alior101 - 02-10-06 06:26 ---------------------------------------------------------------------- I noticed the same issue but if I issue a ls -la * then it works... strange .... ---------------------------------------------------------------------- bernhardf - 10-30-07 10:22 ---------------------------------------------------------------------- fixed in 0.9.28 and later (as reported). Closing accordingly Issue History Date Modified Username Field Change ====================================================================== 02-09-06 12:32 hufnus New Issue 02-09-06 12:32 hufnus Status new => assigned 02-09-06 12:32 hufnus Assigned To => uClibc 02-10-06 06:26 alior101 Note Added: 0001080 10-30-07 10:22 bernhardf Status assigned => closed 10-30-07 10:22 bernhardf Note Added: 0002872 ====================================================================== From bogus@does.not.exist.com Sat Oct 6 13:13:59 2007 From: bogus@does.not.exist.com () Date: Sat, 06 Oct 2007 20:13:59 -0000 Subject: No subject Message-ID: __bswap_16 could not assume that it's zero extended when an unsigned short int is loaded into the data register. Modified: trunk/uClibc/libc/sysdeps/linux/bfin/bits/byteswap.h Changeset: Modified: trunk/uClibc/libc/sysdeps/linux/bfin/bits/byteswap.h =================================================================== --- trunk/uClibc/libc/sysdeps/linux/bfin/bits/byteswap.h 2007-11-23 17:09:54 UTC (rev 20505) +++ trunk/uClibc/libc/sysdeps/linux/bfin/bits/byteswap.h 2007-11-23 17:14:20 UTC (rev 20506) @@ -25,9 +25,10 @@ if (__builtin_constant_p (__x)) \ __v = __bswap_constant_16 (__x); \ else \ - __asm__ ("%0 <<= 8;" \ - "%1.L = %0.L + %0.H (NS);" \ - : "+d" (__x), "=d" (__v)); \ + __asm__ ("%0 = PACK (%1.L, %1.L);" \ + "%0 >>= 8;" \ + : "=d" (__v) \ + : "d" (__x)); \ __v; })) #else static __inline unsigned short int