Re: Question: Does uclibc support NPTL TLS ?
Hello On 29 May 2015 04:30:46 Junling Zheng zhengjunl...@huawei.com wrote: On 2015/5/29 10:08, Rich Felker wrote: On Fri, May 29, 2015 at 09:58:31AM +0800, Junling Zheng wrote: On 2015/5/29 3:27, Bernhard Reutner-Fischer wrote: On 28 May 2015 at 04:00, Khem Raj raj.k...@gmail.com wrote: Seems like gdb is not able to comprehend the TLS structure that uclibc is putting. So you need to investigate that part, either gdb or libthread-db may be where the issue lies. OE essentially produces broken libs for the uClibc package due to --strip-unneeded. I have tweaked my split_and_strip_files() but as a quick-fix you might want to enable DOSTRIP in the uClibc .config and add I guess you mean *disable* DOSTRIP, not *enable* DOSTRIP, right?:) Probably not. I think the idea is that uclubc's internal stripping does it right, but OE's breaks it. You could disable both, but then you'd have lots of debug bloat in the output, so turning on uclibc's in place of OE's is a good workaround. I could be wrong though; in that case Bernhard will probably jump in to correct me. :-) Rich It sounds so, and we'll try both of disabling and enabling DOSTRIP. I had similar problem when I was stripping uclibc from a SPEC file. DOSTRIP instead does the right thing otherwise you will remove some local symbol used by Thanks for your pointers:-) Cheers, Junling ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Sent with AquaMail for Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] arm: add RESET_PID in the clone impl
Il 04 settembre 2014 00:01:38 Waldemar Brodkorb w...@openadk.org ha scritto:
Hi Carmelo,
Hello,
Carmelo Amoroso wrote,
Hi,
I don't think clone on arm is missing RESET_PID if you use the
correct implementation from
libpthread/nptl/sysdeps/unix/sysv/linux/arm/clone.S.
Can you explain this a little bit more?
What I mean to say is that if the root cause is the lack of RESET_PIN
definition it's not the case.
Then, I did not enter into the details of the patch, but at first glance I
could see several other unrelated changes that could eventually have been
split in more patches, but I could be wrong.
On my platform armv7 I don't remember to have such failures.
cat ./libpthread/nptl/sysdeps/unix/sysv/linux/arm/clone.S
#define RESET_PID
#include tcb-offsets.h
#include ../../../../../../../libc/sysdeps/linux/arm/clone.S
Do you think the test-suite failures on arm come from a buildsystem
problem?
best regards
Waldemar
Carmelo
Cheers
Carmelo
Inviato con AquaMail per Android
http://www.aqua-mail.com
Il 02 settembre 2014 14:12:24 Wangyufen wangyu...@huawei.com ha scritto:
From: Wang Yufen wangyu...@huawei.com
Called getpid() When creating a new process with clone(), getpid() returns
the father_process's value. It should be child_process's value.
The reason is missing a RESET_PID in the arm clone impl.
Signed-off-by: Wang Yufen wangyu...@huawei.com
---
libc/sysdeps/linux/arm/clone.S | 61
++-
libc/sysdeps/linux/arm/sysdep.h | 45
2 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/libc/sysdeps/linux/arm/clone.S b/libc/sysdeps/linux/arm/clone.S
index 03cd10e..29045ef 100644
--- a/libc/sysdeps/linux/arm/clone.S
+++ b/libc/sysdeps/linux/arm/clone.S
@@ -19,12 +19,17 @@
/* clone() is even more special than fork() as it mucks with stacks
and invokes a function in the right context after its all over. */
+#include sysdep.h
#define _ERRNO_H
#include features.h
#include bits/errno.h
#include sys/syscall.h
#include bits/arm_asm.h
#include bits/arm_bx.h
+#include sysdep-cancel.h
+
+#define CLONE_VM 0x0100
+#define CLONE_THREAD 0x0001
#if defined(__NR_clone)
/* int clone(int (*fn)(void *arg), void *child_stack, int flags, void
*arg); */
@@ -87,6 +92,8 @@ __error:
.pool
#else
__clone:
+.fnstart
+.cantunwind
@ sanity check args
cmp r0, #0
IT(te, ne)
@@ -95,32 +102,58 @@ __clone:
beq __error
@ insert the args onto the new stack
- sub r1, r1, #8
- str r3, [r1, #4]
- @ save the function pointer as the 0th element
- str r0, [r1]
+ str r3, [r1, #-4]!
+ str r0, [r1, #-4]!
@ do the system call
@ get flags
mov r0, r2
+#ifdef RESET_PID
+ mov ip, r2
+#endif
@ new sp is already in r1
- @ load remaining arguments off the stack
- stmfd sp!, {r4}
- ldr r2, [sp, #4]
- ldr r3, [sp, #8]
- ldr r4, [sp, #12]
- DO_CALL (clone)
- movsa1, a1
- IT(t, ne)
- ldmnefd sp!, {r4}
+ push{r4, r7}
+ cfi_adjust_cfa_offset (8)
+ cfi_rel_offset (r4, 0)
+ cfi_rel_offset (r7, 4)
+ ldr r2, [sp, #8]
+ ldr r3, [sp, #12]
+ ldr r4, [sp, #16]
+ ldr r7, =SYS_ify(clone)
+ swi 0x0
+ cfi_endproc
+ cmp r0, #0
+ beq 1f
+ pop {r4, r7}
blt __error
- IT(t, ne)
#if defined(__USE_BX__)
bxnelr
#else
movne pc, lr
#endif
+ cfi_startproc
+.fnend
+PSEUDO_END (__clone)
+
+1:
+ .fnstart
+ .cantunwind
+#ifdef RESET_PID
+ tst ip, #CLONE_THREAD
+ bne 3f
+ GET_TLS (lr)
+ mov r1, r0
+ tst ip, #CLONE_VM
+ ldr r7, =SYS_ify(getpid)
+ ite ne
+ movne r0, #-1
+ swieq 0x0
+ NEGOFF_ADJ_BASE (r1, TID_OFFSET)
+ str r0, NEGOFF_OFF1 (r1, TID_OFFSET)
+ str r0, NEGOFF_OFF2 (r1, PID_OFFSET, TID_OFFSET)
+3:
+#endif
@ pick the function arg and call address off the stack and execute
ldr r0, [sp, #4]
mov lr, pc
diff --git a/libc/sysdeps/linux/arm/sysdep.h
b/libc/sysdeps/linux/arm/sysdep.h
index 64f4040..38a131d 100644
--- a/libc/sysdeps/linux/arm/sysdep.h
+++ b/libc/sysdeps/linux/arm/sysdep.h
@@ -213,6 +213,51 @@ __local_syscall_error:
\
sees the right arguments.
*/
+#if __ARM_ARCH 4 || defined (__ARM_ARCH_4T__)
+# define ARCH_HAS_BX
+#endif
+#if __ARM_ARCH 4
+# define ARCH_HAS_BLX
+#endif
+#if __ARM_ARCH 6 || defined (__ARM_ARCH_6K__) || defined
(__ARM_ARCH_6ZK__)
+# define ARCH_HAS_HARD_TP
+#endif
+#if __ARM_ARCH 6 || defined (__ARM_ARCH_6T2__)
+# define ARCH_HAS_T2
+#endif
+
+# ifdef
Re: [PATCH] arm: add RESET_PID in the clone impl
Il 04 settembre 2014 22:32:01 Bernhard Reutner-Fischer rep.dot@gmail.com ha scritto: On 4 September 2014 19:32, Carmelo Amoroso carmel...@gmail.com wrote: Il 04 settembre 2014 00:01:38 Waldemar Brodkorb w...@openadk.org ha scritto: Hi Carmelo, Hello, Carmelo Amoroso wrote, Hi, I don't think clone on arm is missing RESET_PID if you use the correct implementation from libpthread/nptl/sysdeps/unix/sysv/linux/arm/clone.S. Can you explain this a little bit more? What I mean to say is that if the root cause is the lack of RESET_PIN definition it's not the case. No, it's not the define of RESET_PID but nothing in the arm clone.S actually does anything with RESET_PID, i.e. the actual implementation is missing, AFAICS. Indeed by looking at the patch better I've noticed the actual fix. Then, I did not enter into the details of the patch, but at first glance I could see several other unrelated changes that could eventually have been split in more patches, but I could be wrong. On my platform armv7 I don't remember to have such failures. Curious how you get a correct getpid() on arm then? This whole caching stuff is a pain and should be removed instead. I will test and check it again as soon as back from my bz trip... I could not remember correctly. For sure I did not debug it. Carmelo Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] arm: add RESET_PID in the clone impl
Hi,
I don't think clone on arm is missing RESET_PID if you use the correct
implementation from libpthread/nptl/sysdeps/unix/sysv/linux/arm/clone.S.
Cheers
Carmelo
Inviato con AquaMail per Android
http://www.aqua-mail.com
Il 02 settembre 2014 14:12:24 Wangyufen wangyu...@huawei.com ha scritto:
From: Wang Yufen wangyu...@huawei.com
Called getpid() When creating a new process with clone(), getpid() returns
the father_process's value. It should be child_process's value.
The reason is missing a RESET_PID in the arm clone impl.
Signed-off-by: Wang Yufen wangyu...@huawei.com
---
libc/sysdeps/linux/arm/clone.S | 61 ++-
libc/sysdeps/linux/arm/sysdep.h | 45
2 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/libc/sysdeps/linux/arm/clone.S b/libc/sysdeps/linux/arm/clone.S
index 03cd10e..29045ef 100644
--- a/libc/sysdeps/linux/arm/clone.S
+++ b/libc/sysdeps/linux/arm/clone.S
@@ -19,12 +19,17 @@
/* clone() is even more special than fork() as it mucks with stacks
and invokes a function in the right context after its all over. */
+#include sysdep.h
#define _ERRNO_H
#include features.h
#include bits/errno.h
#include sys/syscall.h
#include bits/arm_asm.h
#include bits/arm_bx.h
+#include sysdep-cancel.h
+
+#define CLONE_VM 0x0100
+#define CLONE_THREAD 0x0001
#if defined(__NR_clone)
/* int clone(int (*fn)(void *arg), void *child_stack, int flags, void *arg); */
@@ -87,6 +92,8 @@ __error:
.pool
#else
__clone:
+.fnstart
+.cantunwind
@ sanity check args
cmp r0, #0
IT(te, ne)
@@ -95,32 +102,58 @@ __clone:
beq __error
@ insert the args onto the new stack
- sub r1, r1, #8
- str r3, [r1, #4]
- @ save the function pointer as the 0th element
- str r0, [r1]
+ str r3, [r1, #-4]!
+ str r0, [r1, #-4]!
@ do the system call
@ get flags
mov r0, r2
+#ifdef RESET_PID
+ mov ip, r2
+#endif
@ new sp is already in r1
- @ load remaining arguments off the stack
- stmfd sp!, {r4}
- ldr r2, [sp, #4]
- ldr r3, [sp, #8]
- ldr r4, [sp, #12]
- DO_CALL (clone)
- movsa1, a1
- IT(t, ne)
- ldmnefd sp!, {r4}
+ push{r4, r7}
+ cfi_adjust_cfa_offset (8)
+ cfi_rel_offset (r4, 0)
+ cfi_rel_offset (r7, 4)
+ ldr r2, [sp, #8]
+ ldr r3, [sp, #12]
+ ldr r4, [sp, #16]
+ ldr r7, =SYS_ify(clone)
+ swi 0x0
+ cfi_endproc
+ cmp r0, #0
+ beq 1f
+ pop {r4, r7}
blt __error
- IT(t, ne)
#if defined(__USE_BX__)
bxnelr
#else
movne pc, lr
#endif
+ cfi_startproc
+.fnend
+PSEUDO_END (__clone)
+
+1:
+ .fnstart
+ .cantunwind
+#ifdef RESET_PID
+ tst ip, #CLONE_THREAD
+ bne 3f
+ GET_TLS (lr)
+ mov r1, r0
+ tst ip, #CLONE_VM
+ ldr r7, =SYS_ify(getpid)
+ ite ne
+ movne r0, #-1
+ swieq 0x0
+ NEGOFF_ADJ_BASE (r1, TID_OFFSET)
+ str r0, NEGOFF_OFF1 (r1, TID_OFFSET)
+ str r0, NEGOFF_OFF2 (r1, PID_OFFSET, TID_OFFSET)
+3:
+#endif
@ pick the function arg and call address off the stack and execute
ldr r0, [sp, #4]
mov lr, pc
diff --git a/libc/sysdeps/linux/arm/sysdep.h b/libc/sysdeps/linux/arm/sysdep.h
index 64f4040..38a131d 100644
--- a/libc/sysdeps/linux/arm/sysdep.h
+++ b/libc/sysdeps/linux/arm/sysdep.h
@@ -213,6 +213,51 @@ __local_syscall_error:
\
sees the right arguments.
*/
+#if __ARM_ARCH 4 || defined (__ARM_ARCH_4T__)
+# define ARCH_HAS_BX
+#endif
+#if __ARM_ARCH 4
+# define ARCH_HAS_BLX
+#endif
+#if __ARM_ARCH 6 || defined (__ARM_ARCH_6K__) || defined (__ARM_ARCH_6ZK__)
+# define ARCH_HAS_HARD_TP
+#endif
+#if __ARM_ARCH 6 || defined (__ARM_ARCH_6T2__)
+# define ARCH_HAS_T2
+#endif
+
+# ifdef __thumb2__
+# define NEGOFF_ADJ_BASE(R, OFF) add R, R, $OFF
+# define NEGOFF_ADJ_BASE2(D, S, OFF) add D, S, $OFF
+# define NEGOFF_OFF1(R, OFF) [R]
+# define NEGOFF_OFF2(R, OFFA, OFFB) [R, $((OFFA) - (OFFB))]
+# else
+# define NEGOFF_ADJ_BASE(R, OFF)
+# define NEGOFF_ADJ_BASE2(D, S, OFF) mov D, S
+# define NEGOFF_OFF1(R, OFF) [R, $OFF]
+# define NEGOFF_OFF2(R, OFFA, OFFB) [R, $OFFA]
+# endif
+
+# ifdef ARCH_HAS_HARD_TP
+/* If the cpu has cp15 available, use it. */
+# define GET_TLS(TMP) mrc p15, 0, r0, c13, c0, 3
+# else
+/* At this generic level we have no tricks to pull. Call the ABI routine. */
+# define GET_TLS(TMP) \
+ push{ r1, r2, r3, lr }; \
+ cfi_remember_state; \
+ cfi_adjust_cfa_offset (16); \
+
Re: Prelinking does not work with uClibc anymore?
Hello, we were using prelink on SH4 platform w/o problems (we implemented this support @ST). I will try as soon as some bandwidth how it's behaving on our platform and let you know. Regards, Carmelo On 7/31/2014 2:52 PM, Yann Sionneau wrote: Hello, I'm bumping this topic, no one is using prelinking or just the standalone executable for the dynamic loader on MIPS? I would be glad if someone who uses successfully this on MIPS could give me the list of patches he/she uses to get this working (and the base SHA1) Thanks :) Regards, Yann -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Yann Sionneau Sent: Thursday, January 30, 2014 3:18 PM To: 'Shailesh Panchal'; uclibc@uclibc.org Subject: RE: Prelinking does not work with uClibc anymore? Hello, I have tried using head of 0.9.33 branch (still for MIPS target) and I still get the same issue (standalone dynamic loader not outputting to console). What is your uClibc version? Which exact GIT SHA1? What is your target arch? MIPS as well? Thanks for reporting the same issue, I will report back if I find any solution :) Best regards, Yann Sionneau -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Shailesh Panchal Sent: Thursday, January 30, 2014 5:35 AM To: uclibc@uclibc.org Subject: Re: Prelinking does not work with uClibc anymore? Hi, I am also facing same problem. I am not getting any output on /lib/ld-uclibc.so.0 if u get any solution then update it. Regards. shailesh ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [OpenWrt-Devel] uClibc-ng
Il 24 luglio 2014 23:05:34 Khem Raj raj.k...@gmail.com ha scritto: On Thu, Jul 24, 2014 at 1:48 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote: Il 23 luglio 2014 13:42:38 Jody Bruchon j...@jodybruchon.com ha scritto: On 7/22/2014 11:30 PM, Steve Bennett wrote: I would like to add my support to Thomas' position. Regardless of what happens with glibc and/or musl, an active community supporting regular releases of uClibc is a good thing. Time has spoken that we can't expect this to happen unless something changes. I agree. It is better to have a responsive maintainer releasing periodic stable versions than to have what is essentially no maintainer and sustained long-term fragmentation of what uClibc really is. If the uClibc maintainer wakes up in the future and begins releasing again, the new project's changes can always be merged back to the parent, as they did with eglibc and glibc. For now we need to focus on making a stable release, something which is grossly overdue and harms all projects currently using uClibc. I also agree that musl is an interesting project with a bright future (and a bright present for that matter), but it does not cover all of what uClibc covers and the number of projects that already require uClibc is too large to simply drop uClibc and move to musl. -Jody Bruchon Gents, Are we considering anyway that Bernard has recently restarted with patches review and commit without no contribution from the other co-maintainers (myself the first) ? Likely Bernard is already preparing a release ! Yea, but very very slowly, i know. I just started preparing a meta-changelog for the release notes and then we'll call it an official tarball. Lots of changes, about 10% done, approx. 1h left before bedtime. Any prominent changes we should make absolutely sure to mention? I think ARC support would be one. standalone execution on x86_64 now works math tests are fixed MIPS64R2 support is added Likely handling of *stat64 in case of missing syscall ? ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [OpenWrt-Devel] uClibc-ng
Il 23 luglio 2014 13:42:38 Jody Bruchon j...@jodybruchon.com ha scritto: On 7/22/2014 11:30 PM, Steve Bennett wrote: I would like to add my support to Thomas' position. Regardless of what happens with glibc and/or musl, an active community supporting regular releases of uClibc is a good thing. Time has spoken that we can't expect this to happen unless something changes. I agree. It is better to have a responsive maintainer releasing periodic stable versions than to have what is essentially no maintainer and sustained long-term fragmentation of what uClibc really is. If the uClibc maintainer wakes up in the future and begins releasing again, the new project's changes can always be merged back to the parent, as they did with eglibc and glibc. For now we need to focus on making a stable release, something which is grossly overdue and harms all projects currently using uClibc. I also agree that musl is an interesting project with a bright future (and a bright present for that matter), but it does not cover all of what uClibc covers and the number of projects that already require uClibc is too large to simply drop uClibc and move to musl. -Jody Bruchon Gents, Are we considering anyway that Bernard has recently restarted with patches review and commit without no contribution from the other co-maintainers (myself the first) ? Likely Bernard is already preparing a release ! I understand that some comments from Bernard could help to clarify and re-assure the community that uclibc is an alive project still supported. I'm guilty as well as I'm not contributing so actively since one year when my focus @ STMicro has hugely moved from C lib to kernel, but my bandwidth is too low nowadays. I do really hope this project will continue to be used and receive adequate support from the community also providing some acked-by to patches. I do not frankly like that anytime the community raise correctly I'd say concerns against the slowness of releases, it the occasion to push for other C libs; this is not the way to support uClibc project, so please discuss about the wonderful X lib on its own list, not here. Kind regards, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] gcc: explicitly use CFLAGS_FOR_TARGET instead of --enable-target-optspace
Hello Alexey, I guess you sent it to the wrong list. You need to send to buildroot team. Regards, Carmelo On 7/11/2014 6:31 PM, Alexey Brodkin wrote: Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id= it's impossible to specify custom CFLAGS_FOR_TARGET, it is always gets overriden with values from config/mt-ospace: === CFLAGS_FOR_TARGET = -g -Os CXXFLAGS_FOR_TARGET = -g -Os === But in some situations it's required to pass custom flags on buildong of libgcc: * Default flags -g -Os lead to build isses as with PowerPC on gcc 4.5 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810) * Particular CPU requires specific instructions for HW support * Deep optimizations Tested by toolchain building for ARC, ARM and PowerPC with GCC 4.5 Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Anton Kolesov akole...@synopsys.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Peter Korsgaard pe...@korsgaard.com Cc: Gustavo Zacarias gust...@zacarias.com.ar --- package/gcc/gcc-intermediate/gcc-intermediate.mk | 13 + package/gcc/gcc.mk | 10 -- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/package/gcc/gcc-intermediate/gcc-intermediate.mk b/package/gcc/gcc-intermediate/gcc-intermediate.mk index db84d18..0543574 100644 --- a/package/gcc/gcc-intermediate/gcc-intermediate.mk +++ b/package/gcc/gcc-intermediate/gcc-intermediate.mk @@ -46,4 +46,17 @@ ifeq ($(BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE),y) HOST_GCC_INTERMEDIATE_INSTALL_OPT += install-target-libgcc endif +ifeq ($(ARCH),powerpc) +ifeq ($(findstring x4.5.,x$(GCC_VERSION)),x4.5.) + # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 + # Workaround until it's fixed in 4.5.4 or later + HOST_GCC_INTERMEDIATE_CONF_ENV += CFLAGS_FOR_TARGET=-g -O2 + HOST_GCC_INTERMEDIATE_CONF_ENV += CXXFLAGS_FOR_TARGET=-g -O2 +endif +else + # Defaults are -g -Os from config/mt-ospace + HOST_GCC_INTERMEDIATE_CONF_ENV += CFLAGS_FOR_TARGET=-g -Os + HOST_GCC_INTERMEDIATE_CONF_ENV += CXXFLAGS_FOR_TARGET=-g -Os +endif + $(eval $(host-autotools-package)) diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk index 5b60bc3..c6f6e41 100644 --- a/package/gcc/gcc.mk +++ b/package/gcc/gcc.mk @@ -107,16 +107,6 @@ HOST_GCC_COMMON_CONF_OPT = \ HOST_GCC_COMMON_CONF_ENV = \ MAKEINFO=missing -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 -# Workaround until it's fixed in 4.5.4 or later -ifeq ($(ARCH),powerpc) -ifeq ($(findstring x4.5.,x$(GCC_VERSION)),x4.5.) -HOST_GCC_COMMON_CONF_OPT += --disable-target-optspace -endif -else -HOST_GCC_COMMON_CONF_OPT += --enable-target-optspace -endif - # gcc 4.6.x quadmath requires wchar ifneq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),y) HOST_GCC_COMMON_CONF_OPT += --disable-libquadmath ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: locales woes
Il 20 aprile 2014 18:34:26 Yann E. MORIN yann.morin.1...@free.fr ha
scritto:
Hello!
Hello,
While building postgresql with uClibc, we have locales-related build
failures. Here is a small test-case (by Peter) that breaks on uClibc,
but works on glibc:
---8--- test.c ---8---
#include locale.h
#include ctype.h
int f(int c, locale_t l)
{
return isdigit_l(c, l);
}
---8---
$ gcc -Wall -D_GNU_SOURCE -c test.c
[OK]
$ i686-buildroot-linux-uclibc-gcc -Wall -D_GNU_SOURCE -c test.c
test.c: In function ‘f’:
test.c:5:9: error: dereferencing pointer to incomplete type
test.c:6:1: warning: control reaches end of non-void function
[-Wreturn-type]
What happens is that:
sysroot/usr/include/locale.h:
typedef __locale_t locale_t;
sysroot/usr/include/bits/uClibc_locale.h:
typedef struct __uclibc_locale_struct *__locale_t;
But struct __uclibc_locale_struct is never defined:
What about removing the typedef above ?
$ grep -r '__uclibc_locale_struct' sysroot/
sysroot/usr/include/bits/uClibc_locale.h:struct __uclibc_locale_struct;
sysroot/usr/include/bits/uClibc_locale.h:typedef struct
__uclibc_locale_struct *__locale_t;
So, no actual definition of struct __uclibc_locale_struct, so incomplete
type is being derefenced. :-(
Indeed !
Here are the locales-related options from .config:
$ grep LOCALE .config
UCLIBC_HAS_LOCALE=y
# UCLIBC_BUILD_ALL_LOCALE is not set
UCLIBC_BUILD_MINIMAL_LOCALE=y
# UCLIBC_PREGENERATED_LOCALE_DATA is not set
UCLIBC_BUILD_MINIMAL_LOCALES=en_US
UCLIBC_HAS_XLOCALE=y
Any idea?
Regards,
Yann E. MORIN.
Cheers,
Carmelo
--
.-..--..
| Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics'
conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___
|
| +33 223 225 172 `.---: X AGAINST | \e/ There is
no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v
conspiracy. |
'--^---^--^'
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Inviato con AquaMail per Android
http://www.aqua-mail.com
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: weak symbols
Hi Nicolas, On 10/30/2013 7:10 PM, Nicolas Sauzede wrote: Hi Rich, Thanks for your answer. In fact, my 'abort' example was just to demonstrate the weak issue scenario. We are indeed facing this issue with a lot of other symbols duplication when repurposing the uclibc as a semihosting lib c for a custom embedded linux port. The fact is that the linux kernel defines a lot of standard symbols for its own use, such as : memcpy, memmove, strlen, strnlen, sigprocmask, ... So we had to modify uclibc to turn these symbols to weak, to let linux use its own implementation. Note that I understand that uclibc internally still uses __GI_ symbols, which is expected. I just do not understand why *some* symbols of uclibc are defined weak, and some other not. because the uClibc itself could provide a different implementation for example in libc or in libpthread depending if you are using threads *so you are linking -lpthread) or not. And in my tests against newlib and glibc, it appeared that, at least for 'abort', they both define it as weak, hence my question here, to more about the weak rationale of uclibc.. [amorosoc@lxmcdt5 /opt/STM/STLinux-2.4/devkit]readelf -s armv7/target/lib/libc.so.6 | grep abort 494: 0002b3ec 772 FUNCGLOBAL DEFAULT 11 abort@@GLIBC_2.4 6734: 0002b3ec 772 FUNCLOCAL DEFAULT 11 __GI_abort 8294: 0002b3ec 772 FUNCGLOBAL DEFAULT 11 abort In my build (glibc 2.10.2) it's strong. I would expect a lib c to either define all 'standard' symbols as strong if they should NOT be overriden by the user, or all as weak, to let the user override them. But here we seem to have a mix of the two, and I wanted to understand... BR, NS. Cheers, Carmelo Le 10/30/2013 6:16 PM, Rich Felker a écrit : On Wed, Oct 30, 2013 at 04:13:10PM +0100, Nicolas Sauzede wrote: Hello, This is my first post to the uClibc mailing-list. I have a question related to weak API symbols of the uClibc. I have noticed that, when linking a static binary against the uClibc, that certain symbols, such as 'abort', are not defined as weak symbol. The end result is that this kind of trivial program my_abort.c : Redefining any function in the standard library (formally, in the namespace reserved for external identifiers) invokes undefined behavior. While it would be possible to support this usage for some functions (often it's supported for the malloc functions), in general it's impossible (or at least impractical) to support this kind of usage. Note that even if you could override the abort symbol like you're trying to do, this would not cause uclibc-internal usage of abort to call your function. The reason is exactly the same reason you're getting the error: uclibc references it through the internal __GI_ prefixed symbol. I have no idea whether the uclibc maintainers are willing or able to support this usage for abort, but your overriding it is broken usage anyway. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
Hello Il 14 ottobre 2013 18:43:34 Steve Ellcey sell...@mips.com ha scritto: I am new to building uclibc, but have experience building glibc and newlib, and I have a question about the best way to build multiple versions of uclibc from a script without any user interaction. Currently, I run 'make defconfig' to create a default .config file and then This will assume the arch of the host ... I doubt it will work for MIPS. Pass proper arch and cross prefix. use grep to modify the .config file before each build (strip out some lines and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or I may pick a different MIPS ABI. But what I noticed is that when I run the normal 'make' command after modifying .config is that my .config changes are getting wiped out and .config is getting restored to a default state. Because your changes are not in sync with the build system. Try applying them by menuconfig and than check your final .config. Can someone explain why this is happening and if there is a way to prevent it? Is there a better way to do multiple uclibc builds with different defaults and without requiring any user interaction? Steve Ellcey sell...@mips.com Regards Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Patchwork now available for uclibc
Thanks Khem Good idea ... Already registered ... Now we must respin review and release process. Carmelo Inviato con AquaMail per Android http://www.aqua-mail.com Il 24 settembre 2013 03:03:49 Khem Raj raj.k...@gmail.com ha scritto: Hi All, ozlabs has kindly added uclibc project mailing list to tracked lists for patches, so we will be able to monitor/process the patches on ozlabs patchwork instance here http://patchwork.ozlabs.org/project/uclibc/list/ Right now, I am taking care of keeping it uptodate, and expect more devs to start using it Please use patchwork for tracking the patches Happy patchworking -Khem ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Doing a release?
Il 20 settembre 2013 08:41:25 Rich Felker dal...@aerifal.cx ha scritto: On Wed, Sep 18, 2013 at 06:44:15PM +0200, Thomas Petazzoni wrote: Dear Khem Raj, On Wed, 18 Sep 2013 09:11:43 -0700, Khem Raj wrote: It'd be really nice if uClibc adopted a slightly more frequent release schedule, to more easily allow downstream users to benefit from improvements/fixes. I think, if we decide to do releases biannually maintaining branches for long time can be avoided. To get started I think lets start by planning for a 0.9.34 and then everyone sending the pending patches for subsequent 0.9.35 and so on. Since I'm not a uClibc contributor, it's certainly quite easy for me to just speak, but I would like to advocate for a time-based release schedule. I believe that for many projects, time-based release schedules create a rhythm, that provides well-known deadlines and encourages the entire community to meet those deadlines. Agreed. Time-based release schedule has worked very well for musl, too, but with much shorter release intervals, usually 1-2 months. I agree too but 1 or 2 is too short IMO. A 3 month schedule would be better. Rich Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Doing a release?
Hi Il 20 settembre 2013 11:37:47 Sedat Dilek sedat.di...@gmail.com ha scritto: On Fri, Sep 20, 2013 at 8:41 AM, Rich Felker dal...@aerifal.cx wrote: On Wed, Sep 18, 2013 at 06:44:15PM +0200, Thomas Petazzoni wrote: Dear Khem Raj, On Wed, 18 Sep 2013 09:11:43 -0700, Khem Raj wrote: It'd be really nice if uClibc adopted a slightly more frequent release schedule, to more easily allow downstream users to benefit from improvements/fixes. I think, if we decide to do releases biannually maintaining branches for long time can be avoided. To get started I think lets start by planning for a 0.9.34 and then everyone sending the pending patches for subsequent 0.9.35 and so on. Since I'm not a uClibc contributor, it's certainly quite easy for me to just speak, but I would like to advocate for a time-based release schedule. I believe that for many projects, time-based release schedules create a rhythm, that provides well-known deadlines and encourages the entire community to meet those deadlines. Agreed. Time-based release schedule has worked very well for musl, too, but with much shorter release intervals, usually 1-2 months. I recommend to read Martin's PhD Thesis on this topic. ( Martin is a longterm Debian maintainer and was also Debian project lead, so he should know of what he is talking. ) [ QUOTE ] Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management Martin Michlmayr, University of Cambridge Abstract Free and open source software has had a major impact on the computer industry since the late 1990s and has changed the way software is perceived, developed and deployed in many areas. Free and open source software, or FOSS, is typically developed in a collaborative fashion and the majority of contributors are volunteers. Even though this collaborative form of development has produced a significant body of software, the development process is often described as unstructured and unorganized. This dissertation studies the FOSS phenomenon from a quality perspective and investigates where improvements to the development process are possible. In particular, the focus is on release management since this is concerned with the delivery of a high quality product to end-users. This research has identified considerable interest amongst the FOSS community in a novel release management strategy, time based releases. In contrast to traditional development which is feature-driven, time based releases use time rather than features as the criterion for the creation of a new release. Releases are made after a specific interval, and new features that have been completed and sufficiently tested since the last release are included in the new version. This dissertation explores why, and under which circumstances, the time based release strategy is a viable alternative to feature-driven development and discusses factors that influence a successful implementation of this release strategy. It is argued that this release strategy acts as a coordination mechanism in large volunteer projects that are geographically dispersed. The time based release strategy allows a more controlled development and release process in projects which have little control of their contributors and therefore contributes to the quality of the output. [ /QUOTE ] IMHO, a six months release cycle has shown good success - for developers and endusers. The trend in developing seems to go to a 3-months-cycle. The Linux-kernel as an example has proven this. Can't say if something like Linux-next is do-able and makes sense as uClibc-next. I think that most of users of uclibc tends to rely upon stable release taken from distro builder (buildroot open embedded and others) so master is acting as the next for the kernel. Fact is, a lot of kernel sub-trees (features) mature in Linux-next before they enter upstream. We had similar experience with prelink and nptl branches but it required much more effort at merging than integrating the features in master directly. Just my 0.02EUR. [1] http://www.cyrius.com/publications/michlmayr-phd/ Interesting reading Cheers Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: problem in building ncurses with uclibc
On 9/17/2013 8:38 AM, neutrino network wrote: hi, gcc 4.3.3 ncurses 5.7 I am trying to build(cross compiling for mips) ncurses using a uclibc toolchain but it gives following error; lib64\libc.a(nsswitch.o): (.data.rel+0x18):undefined reference to '_nss_files_endaliasent' are you sure you are linking against a mips libc.a from uClibc ? uclibc does not support nss (it is supported by glibc), how should i solve this? my config command is given below; ./configure --prefix=/ncurses_crosscompiled --disable-static --enable-shared --target=mips64--linux-gnu CC=$_ROOT/tools/bin/mips64--linux-gnu-gcc-4.3.3 LDFLAGS=-L$_ROOT/tools/lib/gcc/mips64--linux-gnu/4.3.3/ plus ncurses mailing list says that ncurses has nothing to do with this symbol _nss_files_endaliasent or library. Kindly guide. -Name of the embeded device concealed ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/3] buildsys: fix handling of CFLAGS-OMIT from global CFLAGS
Hi Florian Il 17 settembre 2013 17:57:00 Florian Fainelli f.faine...@gmail.com ha scritto: Hello, 2013/9/13 Filippo ARCIDIACONO filippo.arcidiac...@st.com: Currently the Makefile rules are not removing from the global CFLAGS any of the OMIT cflags declared at file level. This patch fixes it. Do we really need to have two different ways of achieving the same thing? It seems to me that doing: CFLAGS_foo.c += -fno-bar is equivalent to: CFLAGS-OMIT_foo.c += -fbar Is this always true ? I prefer the first one because we do not need to introduce another infrastructure than the one already existing. CFLAGS-OMIT is a construct already used in several other places in uclibc but only applicable at directory level. This patch just extend it to file. Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com --- Makerules |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makerules b/Makerules index 367daa5..54344c5 100644 --- a/Makerules +++ b/Makerules @@ -230,7 +230,8 @@ collect_multi_flags = $(CFLAGS-$(notdir $(patsubst %/,%,$(dir $(d) CFLAGS_gen.dep = -MT $@ -MD -MP -MF $(dir $@).$(notdir $@).dep -cmd_compile.c = $(CC) -c $ -o $@ $(CFLAGS) \ +cmd_compile.c = $(CC) -c $ -o $@ \ + $(filter-out $(CFLAGS-OMIT-$(notdir $)),$(CFLAGS)) \ $(CFLAGS-$(suffix $@)) \ $(filter-out $(CFLAGS-OMIT-$(notdir $)),$(CFLAGS-$(notdir $(D \ $(CFLAGS-$(subst $(top_srcdir),,$(dir $))) \ -- 1.7.7.6 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Florian Carmelo _ __ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Doing a release?
Il 18 settembre 2013 06:49:44 Thomas Petazzoni thomas.petazz...@free-electrons.com ha scritto: Dear uClibc developers, Hi Thomas The last release of uClibc, 0.9.33.2, has been made well over a year ago. However, there is fairly big number of improvements/fixes in the master branch that would be interesting to have in a release. At the Buildroot level, we now have 53 patches in your patch stack against uClibc 0.9.33.2, all coming from the master branch if I'm correct (see http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2). At a first look it seems you have there some patches not part of any uclibc branches ... Likely it would be nice to include them as well. For sure it's time for a 0.9.33.3 but I do also think that we can start a 0.9.34 release from master. Bernard what do you think ? It'd be really nice if uClibc adopted a slightly more frequent release schedule, to more easily allow downstream users to benefit from improvements/fixes. I agree. I know to have been less active recently as my major tasks are currently on the kernel side and SOC bring up but I'll try to respin my contribution to uclibc and upstream several patches we have in STMicro branch. Thanks a lot! Thomas Cheers Carmelo -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Defining AT_BASE_PLATFORM (24) in the elf.h
Il 08 agosto 2013 23:08:41 Rafał Miłecki zaj...@gmail.com hai scritto: Hi guys, I recently noticed I can't compile oprofile tool when using uClibc instead of the glibc. The problem is uClibc doesn't have AT_BASE_PLATFORM defined in the elf.h Hum... Why should oprofile use this macro ? It was reported as oprofile bug: https://sourceforge.net/p/oprofile/bugs/245/ but it may be uClibc bug actually. Is this OK to define AT_BASE_PLATFORM in uClibc's elf.h? Generally yes. Indeed I have some patch to post that allow the dynamic linker to use it. -- Rafał Cheers Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso: fix dlsym hang when reloading DSOs
On 27/06/2013 8.34, Timo Teräs wrote:
It can happen under certain cases that the DSO had refcount 0,
but was already loaded. (NODELETE flag is set, or it is pulled
in via both NEEDED dependency and explicit dlopen()).
In these cases we must not re-add the DSO to the global symbol
scope as it is already there. Or we end up corrupting the linked
list and further dlsym lookups will hang.
Signed-off-by: Timo Teräs timo.te...@iki.fi
Acked-by: Carmelo Amoroso carmelo.amor...@st.com
Cheers,
Carmelo
---
ldso/libdl/libdl.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/ldso/libdl/libdl.c b/ldso/libdl/libdl.c
index c451b63..c901512 100644
--- a/ldso/libdl/libdl.c
+++ b/ldso/libdl/libdl.c
@@ -543,15 +543,23 @@ static void *do_dlopen(const char *libname, int flag,
ElfW(Addr) from)
#ifdef SHARED
/*
- * Get the tail of the list.
* In the static case doesn't need to extend the global scope, it is
* ready to be used as it is, because _dl_loaded_modules already points
* to the dlopened library.
+ *
+ * Extend the global scope by adding the local scope of the dlopened
DSO.
+ * But only if it's not there. It can happen under certain cases that
the
+ * DSO had refcount = 0, but was already loaded. (NODELETE flag is set,
or
+ * it is pulled in via both NEEDED dependency and explicit dlopen()).
*/
- for (ls = _dl_loaded_modules-symbol_scope; ls ls-next; ls =
ls-next);
-
- /* Extend the global scope by adding the local scope of the dlopened
DSO. */
- ls-next = dyn_chain-dyn-symbol_scope;
+ for (ls = _dl_loaded_modules-symbol_scope; ; ls = ls-next) {
+ if (ls == dyn_chain-dyn-symbol_scope)
+ break;
+ if (ls-next == NULL) {
+ ls-next = dyn_chain-dyn-symbol_scope;
+ break;
+ }
+ }
#endif
#ifdef __mips__
/*
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: 答复: arm_gcc-3.4.6_uClibc-0.9.28 - arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32. compile error
Il giorno 05/giu/2013 06:38, Zhang Yu zhang...@oki.com ha scritto:
Line149: #ifdef __USE_MISC
Line150: /* Old compatibility names for C types. */
Line151: typedef unsigned long int ulong;
Line152: typedef unsigned short int ushort;
Line153: typedef unsigned int uint;
Line154: #endif
Clearly seems that now __USE_MISC is defined. Remove your define and use C
standard types. Do not abuse of macros and typedef just a shortcut.
arm_gcc-3.4.6_uClibc-0.9.28 and arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32,
the header file is the same.
Could you give me some tips?
Thanks.
发件人: Carmelo Amoroso [mailto:carmel...@gmail.com]
发送时间: 2013年6月5日星期三 12:26
收件人: Zhang Yu
抄送: uclibc@uclibc.org
主题: Re: arm_gcc-3.4.6_uClibc-0.9.28 -
arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32. compile error
Il giorno 05/giu/2013 05:04, Zhang Yu zhang...@oki.com ha scritto:
uclibc:
First, thanks for reading my mail.
I encountered a curious problem about the uclibc version issue.
Here is a example.
I edited a C program below
---
#define ushort unsigned short
#include sys/types.h
int main()
{
return 0;
}
---
I compiled this program on toolchain-arm_gcc-3.4.6_uClibc-0.9.28, it
works
well, programs can be compiled.
But I upgrade my toolchain to
toolchain-arm_v7-a_gcc-4.5-linaro_uClibc-0.9.32_eabi and with the same
program.
The program can't be compiled.
Here is the error message:
/work/team-zhangyu/0524/ngn-hgw/OS/staging_dir_arm/bin/arm-openwrt-linux-ucl
ibcgnueabi-gcc -Wall -g -o test -I../../include
../../common/libCOMMON_LIB.a
../../common/com_semaphore.o test.c In file included from test.c:4:0:
/work/team-zhangyu/0524/ngn-hgw/OS_5G/staging_dir/toolchain-arm_v7-a_gcc-4.5
-linaro_uClibc-0.9.32_eabi/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.5.4/../
../../../arm-openwrt-linux-uclibcgnueabi/sys-include/sys/types.h:152:28:
error: duplicate 'unsigned'
Check your header line 152
/work/team-zhangyu/0524/ngn-hgw/OS_5G/staging_dir/toolchain-arm_v7-a_gcc-4.5
-linaro_uClibc-0.9.32_eabi/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.5.4/../
../../../arm-openwrt-linux-uclibcgnueabi/sys-include/sys/types.h:152:28:
error: duplicate 'short'
As above
Can anybody help me solve this problem. Does this problem
related to
the version of the compiler?
Thanks a lot for your help!
I guess you should ask to your toolchain provider
Carmelo ___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] fix for libubacktrace.so build problems introduced in 71c10c484e7dc113396cccb7e503befb759c6346
Patch from Filippo already available. Commit soon. Thanks Carmelo Il giorno 26/mag/2013 19:05, Eugene Rudoy gene.de...@gmail.com ha scritto: Dear all, 71c10c484e7dc113396cccb7e503befb759c6346 broke libubacktrace.so in that way that it doesn't contain backtrace symbol anymore. The attached patch fixes the problem for me. The problem is caused by a couple of typos in libubacktrace/Makefile.in: SRC_SHARED vs. SHARED_SRC, wrong file suffixes. 0.9.33-branch also requires this fix. Best, Gene Eugene Rudoy (1): Fix libubacktrace build problems introduced in 71c10c484e7dc113396cccb7e503befb759c6346 (backtrace is missing in libubacktrace.so) libubacktrace/Makefile.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.8.3 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH V2] libc: deal with aux vect inside __uClibc_main only if !SHARED
Il giorno 20/mag/2013 14:38, Filippo ARCIDIACONO filippo.arcidiac...@st.com ha scritto: On 5/19/2013 7:08 AM, Mike Frysinger wrote: On Friday 14 December 2012 05:40:05 Filippo ARCIDIACONO wrote: --- a/libc/misc/elf/dl-support.c +++ b/libc/misc/elf/dl-support.c @@ -28,6 +28,7 @@ void (*_dl_init_static_tls) (struct link_map *) = _dl_nothread_init_static_tls; ElfW(Phdr) *_dl_phdr; size_t _dl_phnum; +size_t _dl_pagesize; void internal_function _dl_aux_init (ElfW(auxv_t) *av); void internal_function _dl_aux_init (ElfW(auxv_t) *av) @@ -37,6 +38,9 @@ void internal_function _dl_aux_init (ElfW(auxv_t) *av) /* Get the number of program headers from the aux vect */ _dl_phnum = (size_t) av[AT_PHNUM].a_un.a_val; + + /* Get the pagesize from the aux vect */ + _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; you cannot use PAGE_SIZE. pretty much every arch has long ago removed that from their kernel headers exported to userspace. and indeed, this breaks building for at least x86: libc/misc/elf/dl-support.c: In function '_dl_aux_init': libc/misc/elf/dl-support.c:43:68: error: 'PAGE_SIZE' undeclared (first use in this function) _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; ^ libc/misc/elf/dl-support.c:43:68: note: each undeclared identifier is reported only once for each function it appears in make: *** [libc/misc/elf/dl-support.os] Error 1 -mike Ok, you are right for x86 the build fails. What do you think to include bits/uClibc_page.h in dl-support.c to get the PAGE_SIZE value? Filippo. ... But this is not exposed when NPTL is enabled because to the include chain PAGE_SIZE gets to be defined, so this explains why it was not failing to us. I think filippo's proposal is fine. Cheers Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH V2] libc: deal with aux vect inside __uClibc_main only if !SHARED
Il giorno 19/mag/2013 07:08, Mike Frysinger vap...@gentoo.org ha scritto: On Friday 14 December 2012 05:40:05 Filippo ARCIDIACONO wrote: --- a/libc/misc/elf/dl-support.c +++ b/libc/misc/elf/dl-support.c @@ -28,6 +28,7 @@ void (*_dl_init_static_tls) (struct link_map *) = _dl_nothread_init_static_tls; ElfW(Phdr) *_dl_phdr; size_t _dl_phnum; +size_t _dl_pagesize; void internal_function _dl_aux_init (ElfW(auxv_t) *av); void internal_function _dl_aux_init (ElfW(auxv_t) *av) @@ -37,6 +38,9 @@ void internal_function _dl_aux_init (ElfW(auxv_t) *av) /* Get the number of program headers from the aux vect */ _dl_phnum = (size_t) av[AT_PHNUM].a_un.a_val; + + /* Get the pagesize from the aux vect */ + _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; Hello Mike you cannot use PAGE_SIZE. pretty much every arch has long ago removed that from their kernel headers exported to userspace. and indeed, this breaks building for at least x86: This code fragment was actually in __uClibc_main.c so I'm wondering why current HEAD is note failing ... I don't this id failing due to this patch libc/misc/elf/dl-support.c: In function '_dl_aux_init': libc/misc/elf/dl-support.c:43:68: error: 'PAGE_SIZE' undeclared (first use in this function) _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; ^ libc/misc/elf/dl-support.c:43:68: note: each undeclared identifier is reported only once for each function it appears in make: *** [libc/misc/elf/dl-support.os] Error 1 Likely we are missing some include in x86 case. We'll try to re produce and fix. -mike Thanks Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] libubacktrace: fix backtrace for statically linked application
A post commit dic will come sono. Apologies. Carmelo Il giorno 13/mag/2013 10:24, Carmelo Amoroso carmelo.amor...@st.com ha scritto: commit: http://git.uclibc.org/uClibc/commit/?id=71c10c484e7dc113396cccb7e503befb759c6346 branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master libgcc_s.so's unwinder could not access unwind tables of statically linked binaries, so we really want to use _Unwind_* stuff from libgcc_eh.a. It required to build backtrace.c differentiating between shared and static case. Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- libubacktrace/Makefile.in | 23 ++- libubacktrace/arm/Makefile.arch |2 +- libubacktrace/arm/backtrace.c |7 +++ libubacktrace/backtrace.c |7 +++ 4 files changed, 29 insertions(+), 10 deletions(-) diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in index 8a4b081..612bf2d 100644 --- a/libubacktrace/Makefile.in +++ b/libubacktrace/Makefile.in @@ -25,11 +25,13 @@ libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH) -include $(libubacktrace_ARCH_DIR)/Makefile.arch libubacktrace_SRC-y := -libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c backtracesymsfd.c +libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtracesyms.c backtracesymsfd.c +libubacktrace_SRC_SHARED-$(UCLIBC_HAS_BACKTRACE) := backtrace.c # remove generic sources, if arch specific version is present ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),) libubacktrace_SRC-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y)) +libubacktrace_SRC_SHARED-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC_SHARED-y)) endif # -fasynchronous-unwind-tables is required for backtrace to work using dwarf2 @@ -43,12 +45,19 @@ endif libubacktrace_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y)) libubacktrace_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS)) +libubacktrace_SHARED_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SHARED_SRC-y)) +libubacktrace_SHARED_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.s,$(libubacktrace_SHARED_SRCS)) + +libubacktrace-shared-y := $(libubacktrace_SHARED_OBJS:.os=.oS) +libubacktrace-static-y := $(libubacktrace_SHARED_OBJS) + ifeq ($(DOPIC),y) -libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) +libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) $(libubacktrace-static-y:.o=.os) else -libubacktrace-a-y += $(libubacktrace_OBJS) +libubacktrace-a-y += $(libubacktrace_OBJS) $(libubacktrace-static-y) endif -libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) +libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) $(libubacktrace-shared-y) + lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so @@ -56,11 +65,7 @@ lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so objclean-y += CLEAN_libubacktrace ifeq ($(DOMULTI),n) -ifeq ($(DOPIC),y) -$(top_builddir)lib/libubacktrace.so: $(top_builddir)lib/libubacktrace.a $(libdl.depend) -else $(top_builddir)lib/libubacktrace.so: $(libubacktrace_OUT)/libubacktrace_so.a $(libdl.depend) -endif $(call link.so,$(libubacktrace_FULL_NAME),$(ABI_VERSION)) else $(top_builddir)lib/libubacktrace.so: $(libubacktrace_OUT)/libubacktrace.oS | $(libdl.depend) @@ -71,7 +76,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: $(libubacktrace-so-y) $(Q)$(RM) $@ $(do_ar) -$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) +$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) $(libubacktrace_SHARED_SRCS) $(Q)$(RM) $@ $(compile-m) diff --git a/libubacktrace/arm/Makefile.arch b/libubacktrace/arm/Makefile.arch index 53b8c0e..b3fb500 100644 --- a/libubacktrace/arm/Makefile.arch +++ b/libubacktrace/arm/Makefile.arch @@ -14,4 +14,4 @@ libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os) else libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS) endif -libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os) +libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.oS) diff --git a/libubacktrace/arm/backtrace.c b/libubacktrace/arm/backtrace.c index c154496..55689a7 100644 --- a/libubacktrace/arm/backtrace.c +++ b/libubacktrace/arm/backtrace.c @@ -26,6 +26,7 @@ struct trace_arg int cnt, size; }; +#ifdef SHARED static _Unwind_Reason_Code (*unwind_backtrace) (_Unwind_Trace_Fn, void *); static _Unwind_VRS_Result (*unwind_vrs_get) (_Unwind_Context *, _Unwind_VRS_RegClass, @@ -43,6 +44,10 @@ static void backtrace_init (void) abort(); } } +#else +# define
Re: [git commit] libubacktrace: fix backtrace for statically linked application
Il giorno 13/mag/2013 13:59, Carmelo Amoroso carmel...@gmail.com ha scritto: A post commit dic will come sono. Top many typos ... Meant to sa A post commit fix will come sono Apologies. Carmelo Il giorno 13/mag/2013 10:24, Carmelo Amoroso carmelo.amor...@st.com ha scritto: commit: http://git.uclibc.org/uClibc/commit/?id=71c10c484e7dc113396cccb7e503befb759c6346 branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master libgcc_s.so's unwinder could not access unwind tables of statically linked binaries, so we really want to use _Unwind_* stuff from libgcc_eh.a. It required to build backtrace.c differentiating between shared and static case. Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- libubacktrace/Makefile.in | 23 ++- libubacktrace/arm/Makefile.arch |2 +- libubacktrace/arm/backtrace.c |7 +++ libubacktrace/backtrace.c |7 +++ 4 files changed, 29 insertions(+), 10 deletions(-) diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in index 8a4b081..612bf2d 100644 --- a/libubacktrace/Makefile.in +++ b/libubacktrace/Makefile.in @@ -25,11 +25,13 @@ libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH) -include $(libubacktrace_ARCH_DIR)/Makefile.arch libubacktrace_SRC-y := -libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c backtracesymsfd.c +libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtracesyms.c backtracesymsfd.c +libubacktrace_SRC_SHARED-$(UCLIBC_HAS_BACKTRACE) := backtrace.c # remove generic sources, if arch specific version is present ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),) libubacktrace_SRC-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y)) +libubacktrace_SRC_SHARED-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC_SHARED-y)) endif # -fasynchronous-unwind-tables is required for backtrace to work using dwarf2 @@ -43,12 +45,19 @@ endif libubacktrace_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y)) libubacktrace_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS)) +libubacktrace_SHARED_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SHARED_SRC-y)) +libubacktrace_SHARED_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.s,$(libubacktrace_SHARED_SRCS)) + +libubacktrace-shared-y := $(libubacktrace_SHARED_OBJS:.os=.oS) +libubacktrace-static-y := $(libubacktrace_SHARED_OBJS) + ifeq ($(DOPIC),y) -libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) +libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) $(libubacktrace-static-y:.o=.os) else -libubacktrace-a-y += $(libubacktrace_OBJS) +libubacktrace-a-y += $(libubacktrace_OBJS) $(libubacktrace-static-y) endif -libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) +libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) $(libubacktrace-shared-y) + lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so @@ -56,11 +65,7 @@ lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so objclean-y += CLEAN_libubacktrace ifeq ($(DOMULTI),n) -ifeq ($(DOPIC),y) -$(top_builddir)lib/libubacktrace.so: $(top_builddir)lib/libubacktrace.a $(libdl.depend) -else $(top_builddir)lib/libubacktrace.so: $(libubacktrace_OUT)/libubacktrace_so.a $(libdl.depend) -endif $(call link.so,$(libubacktrace_FULL_NAME),$(ABI_VERSION)) else $(top_builddir)lib/libubacktrace.so: $(libubacktrace_OUT)/libubacktrace.oS | $(libdl.depend) @@ -71,7 +76,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: $(libubacktrace-so-y) $(Q)$(RM) $@ $(do_ar) -$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) +$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) $(libubacktrace_SHARED_SRCS) $(Q)$(RM) $@ $(compile-m) diff --git a/libubacktrace/arm/Makefile.arch b/libubacktrace/arm/Makefile.arch index 53b8c0e..b3fb500 100644 --- a/libubacktrace/arm/Makefile.arch +++ b/libubacktrace/arm/Makefile.arch @@ -14,4 +14,4 @@ libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os) else libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS) endif -libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os) +libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.oS) diff --git a/libubacktrace/arm/backtrace.c b/libubacktrace/arm/backtrace.c index c154496..55689a7 100644 --- a/libubacktrace/arm/backtrace.c +++ b/libubacktrace/arm/backtrace.c @@ -26,6 +26,7 @@ struct trace_arg int cnt, size; }; +#ifdef SHARED static _Unwind_Reason_Code (*unwind_backtrace) (_Unwind_Trace_Fn, void *); static _Unwind_VRS_Result (*unwind_vrs_get) (_Unwind_Context *, _Unwind_VRS_RegClass
Re: Troubleshooting statically built application using backtrace.
Andy I'll commit fixes forma backtrace with static applications tomorrow. Thanks forma tour patience Carmelo Il giorno 08/mag/2013 21:24, ANDY KENNEDY andy.kenn...@adtran.com ha scritto: Attempting to backtrace in a simple helloworld app. For the simple app, we are just using the source of the example from man backtrace. We SEEM to be running into an infinite loop around line 296 of file dlso/dlso/dl-hash.c in which there is a loop that (again) SEEMS to walk off into oblivion. BTW, this is the 0.9.33.2 packaged version, if it is fixed later, I don't know it. What we are attempting to do is source level debug (from gdbserver running on a p1014 target) uClibc. I'm using CrossTool-NG to build the toolchain. I've hacked up CTNG to REMOVE the sed scripts that remove the debug information settings in my .config file. Setting the following flags: DODEBUG=y # DOASSERTS is not set SUPPORT_LD_DEBUG=y ends in a build failure in which it appears that one of the .a libs is attempting to link against libgcc_s.so.1 (which contains _Unwind_Backtrace and (I think) _Unwind_Resume. This won't work so good since these are not available static. Here is the error I get: /usr/bin/make -C extra/locale locale_headers make[3]: Nothing to be done for `locale_headers'. true -x -R .note -R .comment libc/libc_so.a rm -f lib/libc.so lib/libc.so.0 lib/libuClibc-0.9.33.2.so powerpc-unknown-linux-uclibcgnuspe-gcc -Wl,-EB -shared -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-init,__uClibc_init -Wl,-soname=libc.so.0 -nostdlib -o lib/libuClib c-0.9.33.2.so -Wl,--whole-archive libc/libc_so.a -Wl,--no-whole-archive ./lib/interp.os ./lib/ld-uClibc.so.0 ./lib/uclibc_nonshared.a /crap/cro sstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buildtools/li b/gcc/powerpc-unknown-linux-uclibcgnuspe/4.7.2/libgcc.a libc/libc_so.a(lockf.os): In function `__GI_lockf': /crap/crosstool-ng-1.18.0/.build/powerpc-unknown-linux-uclibcgnuspe/buil d/build-libc/libc/misc/file/lockf.c:73: undefined reference to `_Unwind_ Resume' libc/libc_so.a(lockf.os):(.sdata.DW.ref.__gcc_personality_v0[DW.ref.__gc c_personality_v0]+0x0): undefined reference to `__gcc_personality_v0' collect2: error: ld returned 1 exit status make[1]: *** [lib/libc.so] Error 1 Is there an easy way to enable source level debugging so that we can work out the issues that dl_* are having with opening up the libgcc_s.so.1 file at run-time? Thanks in advance for any assistance you can give. Andy ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Troubleshooting statically built application using backtrace.
Il giorno 08/mag/2013 22:33, ANDY KENNEDY andy.kenn...@adtran.com ha scritto: -Original Message- From: Carmelo Amoroso [mailto:carmel...@gmail.com] Sent: Wednesday, May 08, 2013 2:36 PM To: ANDY KENNEDY Cc: uclibc@uclibc.org Subject: Re: Troubleshooting statically built application using backtrace. Andy I'll commit fixes forma backtrace with static applications tomorrow. Thanks forma tour patience Carmelo Carmelo, Okay cool! Can you tell me what you've found so far? My next step was to disable the New way of doing the dl_hash. I've just built a new config with that disabled and am completing the toolchain now. We have actually fixed it. Static dlopen was broken Will that do what I'm expecting or am I off base (that is to say, you are doing something that does NOT involve the whole libgcc_s.so.1 library)? Still want to use libgcc Thanks man. I'm being patient. I didn't know you were working on it. I have been working on it since e-mail a week ago or so. I wasn't expecting anything out of the developers of uClibc, but was attempting to fix something and actually (for a change) contribute in place of just use ;). Andy Cheers Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Backtrace on P1014.
Hello Filippo Please post the patch so i'll push int. Carmelo Il giorno 29/apr/2013 10:04, Filippo ARCIDIACONO filippo.arcidiac...@st.com ha scritto: On 4/26/2013 4:51 PM, ANDY KENNEDY wrote: From: Filippo ARCIDIACONO [mailto:filippo.arcidiacono@**st.comfilippo.arcidiac...@st.com ] On 4/26/2013 5:30 AM, ANDY KENNEDY wrote: I'm attempting to link static an app that contains backtrace. I set LDFLAGS to -lubacktrace -ldl and I get a viable file which does run. The app crashes. During the call to backtrace, I get an error: libgcc_s.so.1 must be installed for backtrace to work I have attempted to launch the app with LD_LIBRARY_PATH, however, it appears that this has an unobtainable path: ~/working/uClibc-0.9.33.2$ grep -R __LDSO_LIBRARY_PATH__ . ./ldso/libdl/libdl.c:#if !defined SHARED defined __LDSO_LIBRARY_PATH__ Does anyone know why the __LDSO_LIBRARY_PATH__ is here? Indeed there was a typo error in commit e4aa966cf25e83cd0c72f34f7855a9**95ff93944d /uClibc/commit/ldso/libdl/**libdl.c?id=**e4aa966cf25e83cd0c72f34f7855a9 **95ff93944d. It should be __LDSO_LD_LIBRARY_PATH__, it has been introduced to disable the use of LD_LIBRARY_PATH on hardened systems. We take care to fix it soon. Thanks, Andy Regards, Filippo To answer Carmelo's question: 123456789012345678901234567890**123456789012345678901234567890** 123456789012 This code can never be reached through a standard build of uClibc. Using CrossTool-NG, I have no way to affect the #defines of the build, thus I would be unable to -D__LDSO_LD_LIBRARY_PATH__ and, even with Filippo's suggested changes, this code can still not be reached. You have to enable LDSO_LD_LIBRARY_PATH=y in your .config, then when you build the uClibc, __LDSO_LD_LIBRARY_PATH__ will be defined in uClibc_config.h, as #define __LDSO_LD_LIBRARY_PATH__ 1, this is automatically included by features.h, so you don't need to pass any -D__LDSO_LD_LIBRARY_PATH__ to the build system. /work/uClibc-0.9.33.2# grep -R --color __LDSO_LD_LIBRARY_PATH__ . ./ldso/ldso/ldso.c:#ifdef __LDSO_LD_LIBRARY_PATH__ ./ldso/ldso/ldso.c:#ifdef __LDSO_LD_LIBRARY_PATH__ ./ldso/ldso/ldso.c:#ifdef __LDSO_LD_LIBRARY_PATH__ ./ldso/ldso/ldso.c:#ifdef __LDSO_LD_LIBRARY_PATH__ ./ldso/ldso/dl-elf.c:#ifdef __LDSO_LD_LIBRARY_PATH__ ./ldso/libdl/libdl.c:#ifdef __LDSO_LD_LIBRARY_PATH__ It is _used_ all over the place, but there is never a time when it is _SET_. There is no way to get to any of the code that this #define protects. Should we put in a config option for this somewhere, or set this variable if for building these libraries as the static libraries? This code will not exist in the libdl.a library. As far as a test case goes, no I don't have one to share at the moment, and I'm pressed for time getting this done, but I'll get one for you later. At the moment, however, what can we do to make it so this is not unreachable code? Simply fix the typo error as described in my previous comment. Andy Filippo __**_ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/**mailman/listinfo/uclibchttp://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Backtrace on P1014.
On 26/04/2013 5.30, ANDY KENNEDY wrote: I'm attempting to link static an app that contains backtrace. I set LDFLAGS to -lubacktrace -ldl and I get a viable file which does run. The app crashes. During the call to backtrace, I get an error: libgcc_s.so.1 must be installed for backtrace to work I have attempted to launch the app with LD_LIBRARY_PATH, however, it appears that this has an unobtainable path: ? ~/working/uClibc-0.9.33.2$ grep -R __LDSO_LIBRARY_PATH__ . ./ldso/libdl/libdl.c:#if !defined SHARED defined __LDSO_LIBRARY_PATH__ Does anyone know why the __LDSO_LIBRARY_PATH__ is here? could you elaborate a bit more ? Actually we have tested backtrace() in shared case ... not sure if there could be problem when static libraries are used. It could be that there are problems in using dlopen with static lirabries (even if we have used it in the past). We'll try to give a look. If you have a test case to share, please do. P.S. On which platform are you trying to use it ? Thanks, Andy Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Questions on .config [uClibc for ARM Cortex A9]
On 15/03/2013 17.15, Ramesh Rangavittal wrote: From: Sergei Poselenov [sposele...@emcraft.com] Sent: Friday, March 15, 2013 1:50 AM To: Ramesh Rangavittal Cc: uclibc@uclibc.org Subject: Re: Questions on .config [uClibc for ARM Cortex A9] Hello Ramesh, The following settings work for me (I'm building for Cortex-M3/Thumb): make -s ARCH_CFLAGS= 'CPU_CFLAGS=-mthumb -march=armv7 -mfix-cortex-m3-ldrd' Note the space between ARCH_CFLAGS= and the rest of the string. Regards, Sergei On Thu, 14 Mar 2013 02:44:26 + Ramesh Rangavittal ramesh.rangavit...@ruckuswireless.com wrote: Hello, I am trying to build uClibc for ARM Cortex A9 processor. For the version uClibc-0.9.30.1 powerpc e500, I see the below config options set in a .config found a different email thread. CONFIG_E500=y TARGET_SUBARCH=e500 For the A9, I ran into the below email thread, I am not sure what value should be set? http://lists.uclibc.org/pipermail/uclibc/2011-February/044737.html Can someone please advice. Any pointers to a README doc to have the right settings for this processor is highly appreciated. BTW the uClibc version that I am trying build is uclibc-0.9.33.2. /Ramesh ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Emcraft Systems - uClinux for Cortex-M MCUs | www.emcraft.com | s...@emcraft.com = Thank you Bernhard Sergei for the answers. Our build infrastructure is based on uClibc 0.9.30.1 I am wondering if I really need to use the latest version at this point (0.9.33.2) or 0.9.30.1 itself is good for the a9 processor. Ramesh, latest is preferrable. We use it successfully on Cortex-A9 in a very demanding context like STB, Media Sever and Home Gateway. Regards Ramesh Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc Hardening Guide?
On 28/02/2013 19.52, Jeffrey Walton wrote: Hi All, Hi, Does uClibc have a hardening guide? If so, would someone be able to point me to it? I have not been able to locate one, but I might be missing some key terms. For example, https://www.google.com/#q=hardening+guide+site:uclibc.org Thanks in advance, Jeff you might also consider disabling some feature of the ld.so as part of an hardened toolchain, so you could disable support for LD_LIBRARY_PATH, LD_PRELOAD env variable and LD_PRELOAD file. All of these are configurable into uClibc. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH V2] libc: deal with aux vect inside __uClibc_main only if !SHARED
On 14/12/2012 11.49, Filippo ARCIDIACONO wrote: On 12/14/2012 11:40 AM, Filippo ARCIDIACONO wrote: It's not safe to use the aux vect inside __uClibc_main if we are running with shared libraries, because it could have been already modified. For example, if some constructor plays with environment variables by using unsetenv, the modifications done into the stack to unset an environment variable, have impacts on the aux vect due to the extra NULL entries added. Due to this, __uClibc_main is not able to detect where the aux vect starts, so all the entries that are used by __uClibc_main (AT_UID, AT_EUID, AT_GID, AT_EGID, AT_PAGESZ and possibly other arch specific) are impacted. Same side effect on the aux vect is caused by the ld.so when running a SUID program with some of the unsecure environment variables set, that will be unset by the ld.so itself. In order to fix this issue, it needs to handle aux vect entries into __uClibc_main only if SHARED is not defined. In SHARED case, libc refers to __dl_secure and _dl_pagesize as initialised by the ld.so where the aux vext is still untouched. Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com Reviewed-by: Carmelo Amoroso carmelo.amor...@st.com --- ldso/ldso/ldso.c|2 +- libc/misc/elf/dl-support.c |4 libc/misc/internals/__uClibc_main.c | 22 -- 3 files changed, 21 insertions(+), 7 deletions(-) [SNIP] Please consider this version. It fixes last minute build problem and avoid some compiler warning. regards, Filippo. Hello, I'd like to have some other feedback on this before committing. I have reviewed this Filippo during the debug, so my opinion is not neutral ;-) Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: iozone compilation failure with uclibc due to aio
On 10/12/2012 18.27, Rich Felker wrote: On Mon, Dec 10, 2012 at 05:43:54PM +0530, Madhu koriginja wrote: Hi All, I am facing compilation issue with the iozone compilation failure with uclibc library. I am using the uclibc 0.9.32 version, gcc 4.5 linaro toolchain. The same code is compiling with the gcc 4.5 linaro toolchain and glibc 2.14. Please help me to resolve this issue. Please see the compilation error below: [...] arm-openwrt-linux-uclibcgnueabi-gcc -c -O3 -Dunix -Dlinux -DHAVE_ANSIC_C -DASYNC_IO \ -D_LARGEFILE64_SOURCE -Os -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -msoft-float libasync.c -o libasync.o libasync.c:98:17: fatal error: aio.h: No such file or directory compilation terminated. As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... If there's really no way around it, you could see if someone could help you getting AIO added to uClibc. Rich FYI, We (@ST) do use iozone on uClibc with the AIO support switched off w/o problems. So as Rich suggested, there is a way to use a fallback solution. I guess that not passing -DASYNC_IO should make the trick. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Perf compilation failure with uclibc due to libintl
On 10/12/2012 14.41, kkmmkk wrote: elfutils needs getext to properly build. It looks like you are using OpenWrt, so I would rather direct you to the openwrt development mailing-list, because this has nothing to do with uClibc per se. But I am able to compile with glibc library successfully. You mean do I need to enable some configuration for gettext in the openwrt configuration? you need to build uClibc with UCLIBC_HAS_GETTEXT_AWARENESS enabled. carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] arm: clone: restore stack pointer just after return from syscall
On 11/12/2012 16.32, Filippo ARCIDIACONO wrote:
If the syscall returns with an error the stack pointer and r4 register
are not restored because the instruction 'ldmnefd sp!, {r4}' is executed
after branching to '__error' label.
This bug has been spotted out by running './utstest clone 5' from LTP
built with -fstack-protector-all compiler flag as log below:
root@cortex-a9:/usr/tests/ltp/testcases/bin# ./utstest clone 5
stack smashing detected: ./utstest terminated()
Regression introduced by commit e58798e107d652644629a1daaa95d76430808d53
Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com
Signed-off-by: Giuseppe Di Giore giuseppe.di-gi...@st.com
---
libc/sysdeps/linux/arm/clone.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libc/sysdeps/linux/arm/clone.S b/libc/sysdeps/linux/arm/clone.S
index fdc05b8..e4101ba 100644
--- a/libc/sysdeps/linux/arm/clone.S
+++ b/libc/sysdeps/linux/arm/clone.S
@@ -111,8 +111,8 @@ __clone:
ldr r4, [sp, #12]
DO_CALL (clone)
movsa1, a1
- blt __error
ldmnefd sp!, {r4}
+ blt __error
IT(t, ne)
#if defined(__USE_BX__)
bxnelr
sneaky bug. well spotted.
Applied, thanks.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: dlclose segfaults on x86_64
On 01/11/2012 16.26, Natanael Copa wrote:
On Fri, Oct 5, 2012 at 1:46 PM, Natanael Copa natanael.c...@gmail.com wrote:
building vlc will end up with a segfaulting ./vlc-cache-gen on x86_64.
...
Core was generated by
`/home/ncopa/aports/main/vlc/src/vlc-2.0.3/bin/.libs/lt-vlc-cache-gen
../modules'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
at libc/stdlib/malloc-standard/free.c:324
324 p-fd = *fb;
(gdb) bt
#0 0x7f9e5fc53e30 in free (mem=0x7f9e6056a668)
at libc/stdlib/malloc-standard/free.c:324
#1 0x7f9e5f0843d6 in do_dlclose (vhandle=0x7f9e60ca7be0, need_fini=1)
at ldso/libdl/libdl.c:960
#2 0x7f9e5f084a47 in dlclose (vhandle=0x7f9e60ca7be0)
at ldso/libdl/libdl.c:1063
#3 0x7f9e5ff06e1c in module_Unload (handle=optimized out)
at posix/plugin.c:89
...
Does not seem like anybody really cares, but for the record, Timo
Teräs solved it with:
--- ./ldso/libdl/libdl.c.orig
+++ ./ldso/libdl/libdl.c
@@ -951,8 +951,8 @@
dtv_t *dtv = THREAD_DTV ();
-
_dl_assert(!(dtv[tls_lmap-l_tls_modid].pointer.is_static));
- if
(dtv[tls_lmap-l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
+ if
(!(dtv[tls_lmap-l_tls_modid].pointer.is_static)
+
dtv[tls_lmap-l_tls_modid].pointer.val != TLS_DTV_UNALLOCATED) {
/* Note that free is
called for NULL is well. We
deallocate even if it
is this dtv entry we are
supposed to load. The
reason is that we call
Downloadable patch is available here:
http://git.alpinelinux.org/cgit/aports/plain/main/libc0.9.32/uclibc-dlclose-fix.patch
Can we have a well git formed patch sent to this list, unless I've
missed it ?
Thanks,
Carmelo
I have a relatively small testcase application that can reproduce it
(using vlc's plugins)
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: wrongly auxvt in __uClibc_main
On 26/11/2012 20.45, Rich Felker wrote: On Mon, Nov 26, 2012 at 04:45:18PM +0100, Filippo ARCIDIACONO wrote: Folks, we have seen some issues recently in uClibc related to the way the aux vect is managed inside __uClibc_main. Running a set-[user,group]-ID ELF binaries with some 'unsecure' environment variable set (i.e LD_LIBRARY_PATH or LD_PRELOAD), auxvt is wrongly set in __uClibc_main. The problem is caused by the call to _dl_unsetenv function in ldso.c that pops the specific env variables from the stack adding a corresponding number of NULL entries at the end of the environments stack. Hi Rich, I don't know if anybody wants to tackle this, but I believe the current _dl_unsetenv behavior is non-conforming (the implementation does not have a license to unset environment variables at will). The correct behavior is just ignoring the variables in the current (suid) process, but still making them available to the application which might want to query them with getenv or pass them on to child processes. There is some concern about the safety of the latter, but the issue only arises if the suid program has elevated itself to having both read and effective uid privileged. If the real/effective ids still differ, the child will ignore the environment variables, and if they process has fully dropped privileges down to that of the invoking user (the original real uid), then it's appropriate that the environment variables be honored. I see your concerns, currently I have not a clear idea. I don't believe whoever originally added the _dl_unsetenv logic thought these issues out well... anyway there is another case that is showing the same issue anyway. If one of the constructor of a dependent shared libraries called the C library unsetenv, the side effect would be the same, that is aux vect invalid if used into the __uClibc_main. Beside the issue with suid programs, also the actual value of the pagesize used by the running kernel could be affected. So I think that there are still more valid reason for redesigning this core piece of code. Rich Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: mips64 problems
On 02/11/2012 10.04, Carmelo AMOROSO wrote: On 26/09/2012 16.54, Waldemar Brodkorb wrote: Hi, Hello, when building a buildroot based system for the target qemu-mips64-malta I get following output generated: wbx@neon:~/adk/buildroot $ ./output/host/usr/bin/mips64-linux-readelf -a output/target/bin/busybox |grep interpreter [Requesting program interpreter: /lib/ld64-uClibc.so.0] wbx@neon:~/adk/buildroot $ ls -la output/target/lib/ld-uClibc* -rwxr-xr-x 1 wbx admin 32280 Sep 26 15:51 output/target/lib/ld-uClibc-0.9.33.2.so lrwxr-xr-x 1 wbx admin 21 Sep 26 14:25 output/target/lib/ld-uClibc.so.0 - ld-uClibc-0.9.33.2.so The problem is this line in Rules.mak: ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x sparc64 x86_64 ),) UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 else UCLIBC_LDSO_NAME := ld-uClibc ARCH_NATIVE_BIT := 32 endif TARGET_ARCH can not be set to mips64 via make menuconfig or any .config. How is it supposed to work? it's not working indeed. Would be the use of TARGET_SUBARCH a solution? I don't think so, as it's not a SUBARCH, even if I'm not expert of the MIPS platform. We could add a Config.mips64 to make it selectable as a mips64 arch, but this will have hge impact on the current mips specific code that is generic for the different ABI and implement internally a check wrt to the ABI. Anyway, looking at Config.mips, I can see that is possible to configure it as a 64bit (by setting the Target ABI to CONFIG_MIPS_N64_ABI), but I don't know exactly the implications (the only use I can see is to pass -mips64 to the compiler, that should generate MIPS64 ABI compatible code only). Something like that: diff -Nur uClibc-0.9.33.2.orig/Rules.mak uClibc-0.9.33.2/Rules.mak --- uClibc-0.9.33.2.orig/Rules.mak 2012-05-15 09:20:09.0 +0200 +++ uClibc-0.9.33.2/Rules.mak2012-09-21 19:28:45.0 +0200 @@ -118,7 +118,7 @@ LIBC := libc SHARED_LIBNAME := $(LIBC).so.$(ABI_VERSION) UBACKTRACE_DSO := libubacktrace.so.$(ABI_VERSION) -ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 mips64 powerpc64 s390x sparc64 x86_64 ),) +ifneq ($(findstring $(TARGET_SUBARCH) , hppa64 ia64 mips64 powerpc64 s390x sparc64 x86_64 ),) this will have an overall impact on all others. I think we should do an exception for mips. UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 else diff -Nur uClibc-0.9.33.2.orig/extra/Configs/Config.in uClibc-0.9.33.2/extra/Configs/Config.in --- uClibc-0.9.33.2.orig/extra/Configs/Config.in 2012-05-15 09:20:09.0 +0200 +++ uClibc-0.9.33.2/extra/Configs/Config.in 2012-09-21 19:29:11.0 +0200 @@ -235,6 +235,7 @@ default i486 if CONFIG_486 default i586 if CONFIG_586 || CONFIG_586MMX default i686 if TARGET_ARCH = i386 +default mips64 if CONFIG_MIPS_ISA_MIPS64 this looks fine I meant does not look fine, as I sais, it is not a SUBARCH in my understanding. Carmelo default source extra/Configs/Config.in.arch Any feedback is appreciated. thanks in advance Waldemar I'll try to post a patch. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: why strong symbal not cover weak symbal?
On 02/11/2012 14.54, 风涯 wrote:
first an example
libmya.c
[code]
#includestdio.h
void PrintA()
{
printf(A\n);
}
__attribute__ ((weak))
void myfunc()
{
printf(myfunc in libmya\n);
}
[/code]
libmyb.c
[code]
#includestdio.h
void PrintB()
{
printf(B\n);
}
void myfunc()
{
printf(myfunc in libmyb\n);
}
[/code]
main.c
[code]
void main()
{
PrintA();
PrintB();
myfunc();
}
[/code]
Makefile
[code]
CC=gcc
ALL:main
main:main.c libmya.so libmyb.so
${CC} main.c -L. -Wl,-rpath,. libmya.so libmyb.so -o main -g
libmya.so:libmya.c
${CC} libmya.c -shared -fPIC -o libmya.so
libmyb.so:libmyb.c
${CC} libmyb.c -shared -fPIC -o libmyb.so
clean:
rm main *.so *.o *.s
[/code]
the result is:
A
B
myfunc in libmya
why the strong symbal int libmyb.so didn't cover the weak one in libmya.so?
I know it is becuase the _function dl_find_hash in the dl-hash.c do nothing
with the weak symbal . But I think if there is a strong one,we should
choose it rather than weak one.
And this is the correct behaviour, and the only one supported in uClibc.
glibc behaves similarly, except if you set LD_DYNAMIC_WEAK.
weak are meaningful only for static libraries, not shared.
See, for example: http://sourceware.org/bugzilla/show_bug.cgi?id=3946.
Regards,
Carmelo
sorry for my bad English...
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: dlsym(RTLD_NEXT) failures on ARM and MIPS with LD_PRELOAD w/ 0.9.33.2
On 20/09/2012 8.36, Florian Fainelli wrote: Hi all, Hi Florian, I just updated two systems to uClibc 0.9.33.2/NPTL (ARMv5 and MIPS32r1), and I now see dlsym() returning NULL for a symbol where it should not. Does it mean that with an older version is worked ? if so, which one ? it could help to identify the problem, if any. The situation is the following: 1) application foo links against shared library mylib and in particular the symbol bar 2) mylib2 is a shared library providing a modified bar symbol and performing a dlsym(RTLD_NEXT, bar) to get the bar symbol address in mylib and finally call this symbol. 3) foo is started that way: LD_PRELOAD=libmylib2.so foo I am yet to be able to write down a reduced test-case exposing the issue, because so far, the problem is appearing only in a much larger mylib and foo though they both do not do much more than what is described above. I have not tried uClibc's master yet. Any hints would be appreciated Thanks! cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: uClibc strange segfault
On 21/08/2012 2.11, Joaquim Pedro França Simão wrote: Hello, I am trying to create a system using BuildRoot, but the system generated can not run binaries compiled on himself, gives a segfault. It generates a core dump, I managed to capture some of the code that theoretically would be the source of the problem, but I do not see how this would be the source. Program terminated with signal 11, Segmentation fault. #0 0xf76efe8f in _stdio_init () at libc/stdio/_stdio.c:258 258 int old_errno = errno; (gdb) bt full #0 0xf76efe8f in _stdio_init () at libc/stdio/_stdio.c:258 old_errno = 134563049 #1 0xf771ab44 in *__GI___uClibc_init () at libc/misc/internals/__uClibc_main.c:276 No locals. #2 0xf7744646 in _dl_get_ready_to_run () from /tmp/buildtree/lib/ld-uClibc.so.0 No symbol table info available. #3 0xf77458dd in ?? () from /tmp/buildtree/lib/ld-uClibc.so.0 No symbol table info available. #4 0xf7745b59 in _start () from /tmp/buildtree/lib/ld-uClibc.so.0 No symbol table info available. This would be a bug in uClibc or would something else? which version are you using ? could you try with master ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] libc: make I/O locking cancel-safe with futexes
From: Filippo ARCIDIACONO filippo.arcidiac...@st.com
Current implementation of I/O locking macros using futexes are not
cancel safe, as if a thread is cancelled while doing IO operations,
it does not release the lock on the IO stream. So following
attempts to acquire the IO stream's lock would dead-lock.
In order to make it cancel-safe, it needs to rely upon the
pthread_cleanup push pop protocol, as it is already done for
the pthread_mutex counterpart.
Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/stdio/Makefile.in|3 ++
libc/stdio/io_lock_unlock.c | 16 ++
libc/sysdeps/linux/common/bits/uClibc_mutex.h | 23 +---
libpthread/nptl/sysdeps/pthread/bits/stdio-lock.h |2 +
4 files changed, 36 insertions(+), 8 deletions(-)
create mode 100644 libc/stdio/io_lock_unlock.c
diff --git a/libc/stdio/Makefile.in b/libc/stdio/Makefile.in
index ff77bcb..4652036 100644
--- a/libc/stdio/Makefile.in
+++ b/libc/stdio/Makefile.in
@@ -52,6 +52,9 @@ endif
# pthread functions
CSRC += flockfile.c ftrylockfile.c funlockfile.c
+ifeq ($(UCLIBC_HAS_STDIO_FUTEXES),y)
+CSRC += io_lock_unlock.c
+endif
# Functions with unlocked versions
CUSRC := \
diff --git a/libc/stdio/io_lock_unlock.c b/libc/stdio/io_lock_unlock.c
new file mode 100644
index 000..b414264
--- /dev/null
+++ b/libc/stdio/io_lock_unlock.c
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2012 STMicroelectronics, Ltd
+ *
+ * Author(s): Filippo Arcidiacono filippo.arcidiac...@st.com
+ *
+ * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball
+ */
+
+#include bits/stdio-lock.h
+
+/* Function wrapper needed for I/O locking macros. */
+
+void IO_lock_unlock (_IO_lock_t *lock)
+{
+ _IO_lock_unlock (*lock);
+}
diff --git a/libc/sysdeps/linux/common/bits/uClibc_mutex.h
b/libc/sysdeps/linux/common/bits/uClibc_mutex.h
index 94597e8..c2a1cc1 100644
--- a/libc/sysdeps/linux/common/bits/uClibc_mutex.h
+++ b/libc/sysdeps/linux/common/bits/uClibc_mutex.h
@@ -12,6 +12,7 @@
#ifdef __UCLIBC_HAS_THREADS__
+
#include pthread.h
#ifdef _LIBC
#include bits/uClibc_pthread.h
@@ -79,15 +80,21 @@
#define __UCLIBC_IO_MUTEX_INIT(M) _IO_lock_t M = _IO_lock_initializer
#define __UCLIBC_IO_MUTEX_EXTERN(M)extern _IO_lock_t M
-#define __UCLIBC_IO_MUTEX_CONDITIONAL_LOCK(M,C)\
- if (C) {
\
- _IO_lock_lock(M);
\
- }
+#define __UCLIBC_IO_MUTEX_CONDITIONAL_LOCK(M,C)
\
+ do {
\
+ struct _pthread_cleanup_buffer __infunc_pthread_cleanup_buffer;
\
+ int __infunc_need_locking = (C);
\
+ if (__infunc_need_locking) {
\
+
_pthread_cleanup_push_defer(__infunc_pthread_cleanup_buffer, \
+ (void (*) (void
*))IO_lock_unlock, \
+ (M));
\
+ _IO_lock_lock((M));
\
+ }
\
+ ((void)0)
+
-#define __UCLIBC_IO_MUTEX_CONDITIONAL_UNLOCK(M,C) \
- if (C) {
\
- _IO_lock_unlock(M);
\
- }
+#define __UCLIBC_IO_MUTEX_CONDITIONAL_UNLOCK(M,C) \
+ __UCLIBC_MUTEX_CONDITIONAL_UNLOCK(M,C)
#define __UCLIBC_IO_MUTEX_AUTO_LOCK(M,A,V) \
__UCLIBC_IO_MUTEX_CONDITIONAL_LOCK(M,((A=(V))) == 0)
diff --git a/libpthread/nptl/sysdeps/pthread/bits/stdio-lock.h
b/libpthread/nptl/sysdeps/pthread/bits/stdio-lock.h
index 3437e61..c742644 100644
--- a/libpthread/nptl/sysdeps/pthread/bits/stdio-lock.h
+++ b/libpthread/nptl/sysdeps/pthread/bits/stdio-lock.h
@@ -29,6 +29,8 @@
typedef struct { int lock; int cnt; void *owner; } _IO_lock_t;
+void IO_lock_unlock (_IO_lock_t *lock);
+
#define _IO_lock_initializer { LLL_LOCK_INITIALIZER, 0, NULL }
#define _IO_lock_init(_name) \
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Race condition on SIGCANCEL signal in POSIX timers
On 28/08/2012 18.57, Khem Raj wrote: On Tue, Aug 28, 2012 at 12:16 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 28/08/2012 9.07, mail...@gmx.de wrote: Hi, Hi, [Please keep me on CC:, I'm not subscribed] I'm working with current uClibc and had problems with POSIX timers. I use the timer with SIGEV_THREAD to create one thread each timer event. It seems there is a race condition between the thread waiting on SIGCANCEL signal (timer_helper_thread in timer_routine.c) and the default signal handler for this signal. Many timer events will be lost, because they will be dequeued before rt_sigtimedwait() could catch it. I found a change on creating the helper thread. (Please see: http://git.uclibc.org/uClibc/commit/libpthread/nptl/sysdeps/unix/sysv/linux/timer_routines.c?id=162cfaea20d807f0ae329efe39292a9b22593b41) After reverting this change, it works for me as expected. Could anybody remember, why this change was necessary? I think the comment is wrong: /*__sigaddset (ss, SIGCANCEL); - already done by sigfillset */ Currently SIGCANCEL will not be blocked by sigfillset, I had to reenable the __sidaddset() comment. I already asked Denys Vlasenko via mail, but didn't get an answer so far. Because I'm not subscribed to your bugtracker (and not intent to do so), could anybody please report a bug against uClibc or did I miss something and this change make any sense? Thank you in advance, Erik we have spotted this issue recently as well, indeed the modifications you mentioned have introduced a regression. I have the fix in the STLinux uClibc repo (http://git.stlinux.com/?p=stm/uclibc.git;a=commit;h=1eed623153b5139c8b5dca08030b3a4a1838d4db). It's on my list for upstream to uclibc.org as well. please commit it upstream too. just done. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Race condition on SIGCANCEL signal in POSIX timers
On 28/08/2012 9.07, mail...@gmx.de wrote: Hi, Hi, [Please keep me on CC:, I'm not subscribed] I'm working with current uClibc and had problems with POSIX timers. I use the timer with SIGEV_THREAD to create one thread each timer event. It seems there is a race condition between the thread waiting on SIGCANCEL signal (timer_helper_thread in timer_routine.c) and the default signal handler for this signal. Many timer events will be lost, because they will be dequeued before rt_sigtimedwait() could catch it. I found a change on creating the helper thread. (Please see: http://git.uclibc.org/uClibc/commit/libpthread/nptl/sysdeps/unix/sysv/linux/timer_routines.c?id=162cfaea20d807f0ae329efe39292a9b22593b41) After reverting this change, it works for me as expected. Could anybody remember, why this change was necessary? I think the comment is wrong: /*__sigaddset (ss, SIGCANCEL); - already done by sigfillset */ Currently SIGCANCEL will not be blocked by sigfillset, I had to reenable the __sidaddset() comment. I already asked Denys Vlasenko via mail, but didn't get an answer so far. Because I'm not subscribed to your bugtracker (and not intent to do so), could anybody please report a bug against uClibc or did I miss something and this change make any sense? Thank you in advance, Erik we have spotted this issue recently as well, indeed the modifications you mentioned have introduced a regression. I have the fix in the STLinux uClibc repo (http://git.stlinux.com/?p=stm/uclibc.git;a=commit;h=1eed623153b5139c8b5dca08030b3a4a1838d4db). It's on my list for upstream to uclibc.org as well. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Implementing {get,set,make,swap}context routines for ARM
On 19/08/2012 1.51, Mike Frysinger wrote: On Tuesday 26 June 2012 05:29:29 Timon ter Braak wrote: I am trying to build a gccgo (go language) cross compiler targetting an ARM system. Go uses the context control routines for coorperative multithreading. uClibc however does not implement them, so I am trying to port the functions to uClibc. The routines are available in glibc and eglibc, and for other architectures [1]. My port builds correctly, but segfaults while running. I noticed that (for example) the getcontext routine is quite different from the setjmp routine shipped with uClibc. Can anybody give me some pointers in what should be altered? A patch of my attempt is attached. you'll need to make them depend on UCLIBC_SUSV3_LEGACY as these functions have been removed from the latest POSIX spec and shouldn't be enabled/built by default -mike I have also a patch set for SH4 since time (never upstreamed). I will consider to rebase and post a patch. I do need to use UCLIBC_SUSV3_LEGACY as Mike suggested. carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Trouble compiling uClibc with NPTL support on Ubuntu 12.04
On 26/07/2012 20.41, Scott Moore wrote: Hi all, I'm trying to compile uClibc 0.9.33.2 with NPTL support, but I keep encountering build failures (possibly related to ldso). I have successfully built uClibc in with no thread support or with linuxthreads.old. I appreciate any help you can offer. Please let me know if there are additional details I can provide. Thanks, Scott Some specs: $ uname -a Linux ubuntu 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.3/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.3-12ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.3 (Ubuntu/Linaro 4.5.3-12ubuntu2) $ ld -v GNU ld (GNU Binutils for Ubuntu) 2.22 Here are all of the errors or warnings that appear during compilation, followed by the command that fails and something that seem like it might help: $ make . . . CC ldso/ldso/ldso.oS ldso/ldso/ldso.c: In function '_dl_get_ready_to_run': ldso/ldso/ldso.c:750:22: warning: cast from pointer to integer of different size ldso/ldso/ldso.c:750:16: warning: unused variable 'tmp' . . . make[1]: `lib/ld64-uClibc.so' is up to date. CC ldso/libdl/libdl.oS ldso/libdl/libdl.c: In function 'do_dlsym': ldso/libdl/libdl.c:738:59: warning: cast from pointer to integer of different size . . . CC libc/stdio/popen.os libc/stdio/popen.c:136:2: warning: #warning is pclose correct wrt the new mutex semantics? . . . CC libc/stdio/_stdio.os libc/stdio/_stdio.c: In function '_stdio_term': libc/stdio/_stdio.c:199:2: warning: #warning check . . . CC libc/stdio/_vfprintf_internal.os In file included from libc/stdio/_vfprintf_internal.c:9:0: libc/stdio/_vfprintf.c: In function '_vfprintf_internal': libc/stdio/_vfprintf.c:1448:15: warning: 'argptr$' may be used uninitialized in this function . . . CC libc/stdio/fflush_unlocked.os In file included from libc/stdio/fflush_unlocked.c:9:0: libc/stdio/fflush.c: In function 'fflush_unlocked': libc/stdio/fflush.c:100:2: warning: #warning fix for nonatomic libc/stdio/fflush.c:101:2: warning: #warning unnecessary check if no threads . . . CC libpthread/nptl/forward.oS libpthread/nptl/forward.c: In function '__pthread_unwind': libpthread/nptl/forward.c:158:1: warning: 'noreturn' function does return . . . CC libpthread/nptl/sysdeps/pthread/pt-longjmp.oS libpthread/nptl/sysdeps/pthread/pt-longjmp.c: In function 'longjmp': libpthread/nptl/sysdeps/pthread/pt-longjmp.c:27:3: warning: implicit declaration of function '__libc_longjmp' libpthread/nptl/sysdeps/pthread/pt-longjmp.c:28:1: warning: 'noreturn' function does return . . . CC libpthread/nptl/pt-cleanup.oS libpthread/nptl/pt-cleanup.c:27:1: warning: redeclaration of '__pthread_cleanup_upto' with different visibility (old visibility preserved) libpthread/nptl/pthreadP.h:357:1: note: previous declaration of '__pthread_cleanup_upto' was here . . . CC libpthread/nptl/pthread_getspecific.oS libpthread/nptl/pthread_getspecific.c:27:1: warning: 'visibility' attribute ignored on non-class types . . . CC libpthread/nptl/unwind.oS libpthread/nptl/unwind.c: In function 'unwind_stop': libpthread/nptl/unwind.c:96:5: warning: implicit declaration of function '__libc_longjmp' libpthread/nptl/unwind.c: At top level: libpthread/nptl/unwind.c:123:1: warning: redeclaration of '__pthread_unwind' with different visibility (old visibility preserved) libpthread/nptl/pthreadP.h:250:1: note: previous declaration of '__pthread_unwind' was here CC libpthread/nptl/vars.oS AR cr libpthread/nptl/libpthread_so.a STRIP -x -R .note -R .comment libpthread/nptl/libpthread_so.a CC libpthread/nptl/pthread_atfork.oS AR cr lib/libpthread_nonshared.a STRIP -x -R .note -R .comment lib/libpthread_nonshared.a CC libpthread/nptl/sysdeps/pthread/pt-initfini.s GEN libpthread/nptl/sysdeps/pthread/defs.h GEN libpthread/nptl/sysdeps/pthread/pt-crti.S AS libpthread/nptl/sysdeps/pthread/pt-crti.o GEN
Re: [PATCH 2/2 uClibc++] Fix ARM EABI build failure in include/unwind-cxx.h
On 12/06/2012 16.19, Bernhard Reutner-Fischer wrote: On 12 June 2012 14:23, Felix Fietkau n...@openwrt.org wrote: uClibc++ current does not build using an ARM EABI toolchain with the following build failure: eh_alloc.cpp In file included from ../include/basic_definitions:21:0, from ../include/cstdlib:20, from eh_alloc.cpp:20: ../include/system_configuration.h:17:0: warning: __WARNINGS__ redefined [enabled by default] /opt/toolchains/armeabi-uclibc-std-0.9.30.2-gcc-4.6.0-binutils-2.20.1/arm-linux-uclibcgnueabi/sysroot/usr/include/bits/uClibc_config.h:223:0: note: this is the location of the previous definition In file included from eh_alloc.cpp:25:0: ../include/unwind-cxx.h:176:36: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:177:36: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:178:35: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:179:41: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:180:40: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:181:39: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:182:38: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' ../include/unwind-cxx.h:183:37: error: ISO C++ forbids casting to an array type '_Unwind_Exception_Class' make[1]: *** [eh_alloc.o] Error 1 make[1]: Leaving directory `/home/florian/dev/uclibcxx/uClibc++/src' Workaround this by direclty using the string GNUC++. Signed-off-by: Felix Fietkau n...@openwrt.org Signed-off-by: Florian Fainelli flor...@openwrt.org --- include/unwind-cxx.h |4 1 file changed, 4 insertions(+) diff --git a/include/unwind-cxx.h b/include/unwind-cxx.h index a5f6440..cd5a58e 100644 --- a/include/unwind-cxx.h +++ b/include/unwind-cxx.h @@ -173,6 +173,7 @@ extern std::unexpected_handler __unexpected_handler; // This is the exception class we report -- GNUCC++\0. const _Unwind_Exception_Class __gxx_exception_class +#ifndef __ARM_EABI_UNWINDER__ = _Unwind_Exception_Class) 'G' 8 | (_Unwind_Exception_Class) 'N') 8 | (_Unwind_Exception_Class) 'U') @@ -181,6 +182,9 @@ const _Unwind_Exception_Class __gxx_exception_class 8 | (_Unwind_Exception_Class) '+') 8 | (_Unwind_Exception_Class) '+') 8 | (_Unwind_Exception_Class) '\0'); +#else += GNUC++; IIRC this should be GNUCC++, no? Seems like nobody needs dependent exceptions? *phew* :) I'll push a fixed version of this.. Thanks for the patch! Hi Bernard, this fix is needed to me too, could you apply it asap ? thanks, carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: More 'unused but set variable warnings' on 32 bit mips.
On 10 April 2012 01:46, Anthony G. Basile bas...@opensource.dyc.edu wrote:
Hi everyone,
I hit this warning yesterday after a fresh pull from the repo on a big
endian 32-bit mips compiling with gentoo's mips-gentoo-linux-uclibc-4.6.2.
It was repeat many times.
Hi,
4.6.2 has started enabling more checks and producing more warnings
CC libc/pwd_grp/getpwnam.os
In file included from ./include/bits/libc-lock.h:36:0,
from ./include/bits/stdio-lock.h:23,
from ./include/bits/uClibc_mutex.h:71,
from ./include/bits/uClibc_stdio.h:119,
from ./include/stdio.h:72,
from libc/pwd_grp/pwd_grp.c:23,
from libc/pwd_grp/getpwnam.c:8:
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h: In function
'__lll_cond_lock':
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:194:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:194:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:194:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h: In function
'__lll_timedlock':
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:213:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:213:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:213:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h: In function
'__lll_robust_timedlock':
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:226:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:226:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
./libpthread/nptl/sysdeps/unix/sysv/linux/mips/lowlevellock.h:226:1:
warning: variable '__prev' set but not used [-Wunused-but-set-variable]
I traced it back through the macros
atomic_compare_and_exchange_bool_acq
- __atomic_bool_bysize
- __arch_compare_and_exchange_bool_32_int
- { __typeof (*mem) __prev; int __cmp; \
__arch_compare_and_exchange_xxx_32_int(mem, new, old, rel, acq); \
!__cmp; }
where __arch_compare_and_exchange_xxx_32_int contains the mips asm that sets
__prev. I see why __prev is unused but set, but I'm not sure how to fix
this properly. A hack that works is to comment out
atomic_compare_and_exchange_bool_acq in
libc/sysdeps/linux/mips/bits/atomic.h = include/bits/atomic.h and fall back
on the #define atomic_compare_and_exchange_bool_acq in include/atomic.h, but
that doesn't seem like the right way.
would attribute used help ?
cheers,
Carmelo
Its only a warning and the resulting libs are good.
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Segfault in libdl-0.9.33.so
On 1 April 2012 08:55, PHilip RUshik prus...@gmail.com wrote: On Sat, Mar 31, 2012 at 11:07 PM, PHilip RUshik prus...@gmail.com wrote: On Fri, Mar 30, 2012 at 10:44 PM, PHilip RUshik prus...@gmail.com wrote: On Fri, Mar 30, 2012 at 9:12 PM, Filippo ARCIDIACONO filippo.arcidiac...@st.com wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of PHilip RUshik Sent: Friday, March 30, 2012 1:03 PM To: uclibc@uclibc.org Subject: Segfault in libdl-0.9.33.so Both ncurses and SDL crash whenever an application using them crashes. dmesg tells me that sdl related crashes are segfaults in libdl- 0.9.33.so, which is (correct me if I'm wrong) the library for the dynamic loader? It is the library provide the support to dynamically load shared libraries. There isn't much more info since I didn't build with debugging libraries. Its strange that this is happening, it worked previously, and I don't think I changed anything in my uclibc config except for adding fenv functions, which shouldn't affect SDL since SDL is only written in C. Everything on my system is dynamically linked, and most things run fine including complex applications such as Xfbdev, and even Abiword. Any ideas about what the problem could be? With the info you provide is difficult understand where is the problem, What I suggest you is to build the uClibc with SUPPORT_LD_DEBUG and SUPPORT_LD_DEBUG_EARLY enabled, they could give some useful info. Which arch are you using? If it would be helpful, I could show you my uclibc config file (or some relevant portion of it). --PHil ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc I know its not much information, sorry. The arch is x86_64, I know its an unusual target architecture, sorry about that. It was built with a binutils 2.22 and GCC 4.5.3 / 4.6.3 / 4.7.0 (all three resulted in the same problem). I'll add those debug options and rebuild everything. I'm starting the build now. I'll let you know. --PHil I enabled those config options, but the output (for the SDL crash) was exactly the same. However, strangely enough, nano started working. So I'm rebuilding again with even more debugging enabled. For anybody who is interested, my target is x86_64 and I am building with gcc 4.6.3. I replied earlier, but once again I accidentally only sent it to one person instead of the mailing list. --PHil This is the info that gets printed directly before the segmentation fault: argc=1 argv=0x7fffd3194398 envp=0x7fffd31943a8 ELF header=0x7f69d02d9000 First Dynamic section entry=0x7f69d04e2d90 Scanning DYNAMIC section Done scanning DYNAMIC section About to do library loader relocations Done relocating ldso; we can now use globals and make function calls! _dl_get_ready_to_run:454: Cool, ldso survived making function calls _dl_malloc:246: mmapping more memory _dl_ldsopath_init:162: Lib Loader: (0xd02d9000) /lib/ld64-uClibc.so.0: using path: /lib _dl_get_ready_to_run:660: calling mprotect on the application program _dl_get_ready_to_run:1042: Loading: (0x7f69d00d5000) /usr/lib/libSDL_net-1.2.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfe4) /usr/lib/libSDL-1.2.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfa02000) /usr/lib/libpng14.so.14 _dl_get_ready_to_run:1042: Loading: (0x7f69cf7f3000) /usr/lib/libSDL_mixer-1.2.so.0 _dl_malloc:246: mmapping more memory _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1 _dl_load_elf_shared_library:758: Found TLS header for /lib/libc.so.0 _dl_load_elf_shared_library:785: Relocated TLS initial image from 0x26f758 to 0x7f69cf3cb758 (size = 0x8) _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfe4) /usr/lib/libSDL-1.2.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1 _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cf5e4000) /lib/libm.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69ced54000) /usr/lib/libts-1.0.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cfc28000) /lib/libpthread.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cf3d3000) /lib/libgcc_s.so.1 _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69d02d9000) /lib/ld64-uClibc.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cef57000) /lib/libdl.so.0 _dl_get_ready_to_run:1042: Loading: (0x7f69cf15c000) /lib/libc.so.0
Re: [PATCH V2] inet:rpc: fix build in !NPTL case
On 14/03/2012 15.56, Carmelo AMOROSO wrote:
__libc_once is not available / needed when multithreading support
is not enabled, so authnone_create() calls authnone_create_once()
directly.
When LT.{old,new} is used instead of NPTL, it needs to explicitly
include bits/libc-lock.h to get __libc_once to be visible.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c |6 ++
libc/inet/rpc/rpc_private.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index d066f6b..70bee5b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -68,7 +68,9 @@ struct authnone_private_s {
};
static struct authnone_private_s authnone_private;
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once_define(static, authnone_private_guard);
+#endif
static void authnone_create_once (void);
@@ -95,7 +97,11 @@ authnone_create_once (void)
AUTH *
authnone_create (void)
{
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once (authnone_private_guard, authnone_create_once);
+#else
+ authnone_create_once();
+#endif
return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
diff --git a/libc/inet/rpc/rpc_private.h b/libc/inet/rpc/rpc_private.h
index e1214d2..38ade1c 100644
--- a/libc/inet/rpc/rpc_private.h
+++ b/libc/inet/rpc/rpc_private.h
@@ -12,6 +12,7 @@ extern u_long _create_xid (void) attribute_hidden;
*/
#ifdef __UCLIBC_HAS_THREADS__
#include pthread.h
+#include bits/libc-lock.h
struct rpc_thread_variables {
fd_set svc_fdset_s;/* Global, rpc_common.c */
struct rpc_createerr rpc_createerr_s; /* Global, rpc_common.c */
Applied.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: stpcpy is Posix-2008, not __USE_GNU.
On 25/03/2012 7.38, Mike Frysinger wrote: On Friday 16 March 2012 07:06:47 Rob Landley wrote: The standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html uClibc's include/string.h: #ifdef __USE_GNU ... /* Copy SRC to DEST, returning the address of the terminating '\0' in DEST. */ # if 0 /* uClibc: disabled */ extern char *__stpcpy (char *__restrict __dest, __const char *__restrict __src) __THROW __nonnull ((1, 2)); # endif extern char *stpcpy (char *__restrict __dest, __const char *__restrict __src) __THROW __nonnull ((1, 2)); libc_hidden_proto(stpcpy) That #ifdef is a bug. s/bug/outdated/ -mike likely we need to update the whole header, instead of just fixing the stpcpy case. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: commit c697912b3a9 breaks linuxthreads build
On 27/02/2012 18.44, Carmelo AMOROSO wrote: On 23/02/2012 21.28, Bernhard Reutner-Fischer wrote: On Tue, Feb 21, 2012 at 11:36:11AM +0800, Tony Wu wrote: Carmelo, Commit c697912b3a9 'inet:rpc: fix authnone_marshal in multithreading context' breaks linuxthreads build, LT as in LT.old or LT.new? Seems it doesn't matter. What arch are you using so that you don't use NPTL? __libc_once_define is not defined. Carmelo, can you please have a look please? You broke LT.old, LT.new _and_ !threads.. My fault. I'll look on this end of this week. I'm currently on business trip. I'm sorry for the inconvenient. Carmelo Folks, I've fixed it now... sorry for my delay. I'm going to post a fix (build tested in !threads case). Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] inet:rpc: fix build in !threads case
__libc_once is not available / needed when multithreading support
is not enabled, so authnone_create() calls authnone_create_once()
directly.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index d066f6b..70bee5b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -68,7 +68,9 @@ struct authnone_private_s {
};
static struct authnone_private_s authnone_private;
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once_define(static, authnone_private_guard);
+#endif
static void authnone_create_once (void);
@@ -95,7 +97,11 @@ authnone_create_once (void)
AUTH *
authnone_create (void)
{
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once (authnone_private_guard, authnone_create_once);
+#else
+ authnone_create_once();
+#endif
return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: commit c697912b3a9 breaks linuxthreads build
On 23/02/2012 21.28, Bernhard Reutner-Fischer wrote:
On Tue, Feb 21, 2012 at 11:36:11AM +0800, Tony Wu wrote:
Carmelo,
Commit c697912b3a9 'inet:rpc: fix authnone_marshal in multithreading
context' breaks linuxthreads build,
LT as in LT.old or LT.new? Seems it doesn't matter.
What arch are you using so that you don't use NPTL?
__libc_once_define is not defined.
Carmelo, can you please have a look please?
You broke LT.old, LT.new _and_ !threads..
ok for !threads case where __libc_once is missing at all, but
LT.{old,new} has __libc_once defined in libc-lock.h (as NPTL), so likely
in this case it needs to include explicitly the header file (that some
some side effect is get included in NPTL case).
I've fixed the case !threads now.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] inet:rpc: fix build in !threads case
On 14/03/2012 15.26, Carmelo AMOROSO wrote:
__libc_once is not available / needed when multithreading support
is not enabled, so authnone_create() calls authnone_create_once()
directly.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index d066f6b..70bee5b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -68,7 +68,9 @@ struct authnone_private_s {
};
static struct authnone_private_s authnone_private;
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once_define(static, authnone_private_guard);
+#endif
static void authnone_create_once (void);
@@ -95,7 +97,11 @@ authnone_create_once (void)
AUTH *
authnone_create (void)
{
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once (authnone_private_guard, authnone_create_once);
+#else
+ authnone_create_once();
+#endif
return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
Tony,
could you try with this patch. If you still get the error, please try
including bits/libc-lock.h as let me know.
Unfortunately I can build only NPTL.
Thanks,
Carmel
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] inet:rpc: fix build in !threads case
On 14/03/2012 15.32, Carmelo AMOROSO wrote:
On 14/03/2012 15.26, Carmelo AMOROSO wrote:
__libc_once is not available / needed when multithreading support
is not enabled, so authnone_create() calls authnone_create_once()
directly.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index d066f6b..70bee5b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -68,7 +68,9 @@ struct authnone_private_s {
};
static struct authnone_private_s authnone_private;
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once_define(static, authnone_private_guard);
+#endif
static void authnone_create_once (void);
@@ -95,7 +97,11 @@ authnone_create_once (void)
AUTH *
authnone_create (void)
{
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once (authnone_private_guard, authnone_create_once);
+#else
+ authnone_create_once();
+#endif
return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
Tony,
could you try with this patch. If you still get the error, please try
including bits/libc-lock.h as let me know.
Unfortunately I can build only NPTL.
I've managed to built LT.old, so I've verified that it needs to include
bits/libc-lock.h
I'll post a v2 of the patch
Thanks,
Carmel
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH V2] inet:rpc: fix build in !NPTL case
__libc_once is not available / needed when multithreading support
is not enabled, so authnone_create() calls authnone_create_once()
directly.
When LT.{old,new} is used instead of NPTL, it needs to explicitly
include bits/libc-lock.h to get __libc_once to be visible.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c |6 ++
libc/inet/rpc/rpc_private.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index d066f6b..70bee5b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -68,7 +68,9 @@ struct authnone_private_s {
};
static struct authnone_private_s authnone_private;
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once_define(static, authnone_private_guard);
+#endif
static void authnone_create_once (void);
@@ -95,7 +97,11 @@ authnone_create_once (void)
AUTH *
authnone_create (void)
{
+#ifdef __UCLIBC_HAS_THREADS__
__libc_once (authnone_private_guard, authnone_create_once);
+#else
+ authnone_create_once();
+#endif
return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
diff --git a/libc/inet/rpc/rpc_private.h b/libc/inet/rpc/rpc_private.h
index e1214d2..38ade1c 100644
--- a/libc/inet/rpc/rpc_private.h
+++ b/libc/inet/rpc/rpc_private.h
@@ -12,6 +12,7 @@ extern u_long _create_xid (void) attribute_hidden;
*/
#ifdef __UCLIBC_HAS_THREADS__
#include pthread.h
+#include bits/libc-lock.h
struct rpc_thread_variables {
fd_set svc_fdset_s;/* Global, rpc_common.c */
struct rpc_createerr rpc_createerr_s; /* Global, rpc_common.c */
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: commit c697912b3a9 breaks linuxthreads build
On 23/02/2012 21.28, Bernhard Reutner-Fischer wrote: On Tue, Feb 21, 2012 at 11:36:11AM +0800, Tony Wu wrote: Carmelo, Commit c697912b3a9 'inet:rpc: fix authnone_marshal in multithreading context' breaks linuxthreads build, LT as in LT.old or LT.new? Seems it doesn't matter. What arch are you using so that you don't use NPTL? __libc_once_define is not defined. Carmelo, can you please have a look please? You broke LT.old, LT.new _and_ !threads.. My fault. I'll look on this end of this week. I'm currently on business trip. I'm sorry for the inconvenient. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH V2] lstat/stat/fstat: Use 64bit version of syscall if available
Please commit
Cheers
Carmelo
Inviato da iPod
Il giorno 04/feb/2012, alle ore 05:42, Khem Raj raj.k...@gmail.com ha scritto:
This is needed for stat'ing loop devices 255
since otherwise kernel returns EOVERFLOW becasue
it needs st_rdev/st_dev to be larger than 16bits but
in kernel it uses __old_kernel_stat for stat
syscall which has st_rdev/st_dev as unsigned short
Add a testcase
Signed-off-by: Khem Raj raj.k...@gmail.com
---
libc/sysdeps/linux/common/fstat.c | 18 ++
libc/sysdeps/linux/common/lstat.c | 19 ++-
libc/sysdeps/linux/common/stat.c | 18 ++
test/stat/stat-loop256.c | 32
4 files changed, 74 insertions(+), 13 deletions(-)
create mode 100644 test/stat/stat-loop256.c
diff --git a/libc/sysdeps/linux/common/fstat.c
b/libc/sysdeps/linux/common/fstat.c
index acc639b..4726a68 100644
--- a/libc/sysdeps/linux/common/fstat.c
+++ b/libc/sysdeps/linux/common/fstat.c
@@ -12,18 +12,28 @@
#include sys/stat.h
#include xstatconv.h
-#define __NR___syscall_fstat __NR_fstat
-static __inline__ _syscall2(int, __syscall_fstat, int, fd, struct
kernel_stat *, buf)
-
int fstat(int fd, struct stat *buf)
{
int result;
+#ifdef __NR_fstat64
+/* normal stat call has limited values for various stat elements
+ * e.g. uid device major/minor etc.
+ * so we use 64 variant if available
+ * in order to get newer versions of stat elements
+ */
+struct kernel_stat64 kbuf;
+result = INLINE_SYSCALL(fstat64, 2, fd, kbuf);
+if (result == 0) {
+__xstat32_conv(kbuf, buf);
+}
+#else
struct kernel_stat kbuf;
-result = __syscall_fstat(fd, kbuf);
+result = INLINE_SYSCALL(fstat, 2, fd, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
}
libc_hidden_def(fstat)
diff --git a/libc/sysdeps/linux/common/lstat.c
b/libc/sysdeps/linux/common/lstat.c
index aa77447..db72d1f 100644
--- a/libc/sysdeps/linux/common/lstat.c
+++ b/libc/sysdeps/linux/common/lstat.c
@@ -12,19 +12,28 @@
#include sys/stat.h
#include xstatconv.h
-#define __NR___syscall_lstat __NR_lstat
-static __inline__ _syscall2(int, __syscall_lstat,
-const char *, file_name, struct kernel_stat *, buf)
-
int lstat(const char *file_name, struct stat *buf)
{
int result;
+#ifdef __NR_lstat64
+/* normal stat call has limited values for various stat elements
+ * e.g. uid device major/minor etc.
+ * so we use 64 variant if available
+ * in order to get newer versions of stat elements
+ */
+struct kernel_stat64 kbuf;
+result = INLINE_SYSCALL(lstat64, 2, file_name, kbuf);
+if (result == 0) {
+__xstat32_conv(kbuf, buf);
+}
+#else
struct kernel_stat kbuf;
-result = __syscall_lstat(file_name, kbuf);
+result = INLINE_SYSCALL(lstat, 2, file_name, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
}
libc_hidden_def(lstat)
diff --git a/libc/sysdeps/linux/common/stat.c
b/libc/sysdeps/linux/common/stat.c
index a6ab291..829f35a 100644
--- a/libc/sysdeps/linux/common/stat.c
+++ b/libc/sysdeps/linux/common/stat.c
@@ -12,20 +12,30 @@
#include sys/stat.h
#include xstatconv.h
-#define __NR___syscall_stat __NR_stat
#undef stat
-static __inline__ _syscall2(int, __syscall_stat,
-const char *, file_name, struct kernel_stat *, buf)
int stat(const char *file_name, struct stat *buf)
{
int result;
+#ifdef __NR_stat64
+/* normal stat call has limited values for various stat elements
+ * e.g. uid device major/minor etc.
+ * so we use 64 variant if available
+ * in order to get newer versions of stat elements
+ */
+struct kernel_stat64 kbuf;
+result = INLINE_SYSCALL(stat64, 2, file_name, kbuf);
+if (result == 0) {
+__xstat32_conv(kbuf, buf);
+}
+#else
struct kernel_stat kbuf;
-result = __syscall_stat(file_name, kbuf);
+result = INLINE_SYSCALL(stat, 2, file_name, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
}
libc_hidden_def(stat)
diff --git a/test/stat/stat-loop256.c b/test/stat/stat-loop256.c
new file mode 100644
index 000..14284c1
--- /dev/null
+++ b/test/stat/stat-loop256.c
@@ -0,0 +1,32 @@
+#include stdio.h
+#include unistd.h
+#include stdlib.h
+#include sys/stat.h
+int main()
+{
+struct stat statbuf;
+int ret = 0;
+char* loop255 = /dev/loop255;
+char* loop256 = /dev/loop256;
+mode_t mode = 0660;
+mknod(loop255, mode, 0x7ff);
+mknod(loop256, mode, 0x100700);
+ret = stat(loop255, statbuf);
+if(ret 0) {
+printf(stat: Cant stat %s\n,loop255);
+unlink(loop255);
+exit(1);
+}
+ret = stat(loop256, statbuf);
+if(ret 0) {
+printf(stat: Cant stat %s\n,loop256);
+
Re: [PATCH] stat: Use stat64 syscall if available
On 03/02/2012 13.58, Mike Frysinger wrote:
On Thursday 02 February 2012 19:12:00 Khem Raj wrote:
--- a/libc/sysdeps/linux/common/stat.c +++
b/libc/sysdeps/linux/common/stat.c
int stat(const char *file_name, struct stat *buf) { int result;
+#ifdef __NR_stat64 +struct kernel_stat64 kbuf; +result =
INLINE_SYSCALL(stat64, 2, file_name, kbuf); + if (result == 0)
{ + __xstat32_conv(kbuf, buf); + } +#else struct kernel_stat
kbuf;
-result = __syscall_stat(file_name, kbuf); +result =
INLINE_SYSCALL(stat, 2, file_name, kbuf); if (result == 0) {
__xstat_conv(kbuf, buf); } +#endif return result; }
might be useful to add a comment why you're calling stat64 ...
because that fills out more fields than stat does typically -mike
___ uClibc mailing
list uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
We were addressing a similar issue on fstat in these days.
see https://bugzilla.stlinux.com/show_bug.cgi?id=16578
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: future branch
On 02/02/2012 23.04, Khem Raj wrote: On Thu, Feb 2, 2012 at 1:38 PM, Peter Mazinger p...@gmx.net wrote: they are already rebased on master here https://github.com/kraj/uClibc so i will start from there and if you can help in issues as we find that will be useful i want to avoid breakages fine, tell me about problems you encounter... The current tree from khem does not compile with SUPPORT_LD_DEBUG=n Didn't look yet which change is the culprit. Khem, have you left out anything from the future branch? I can compile with and without the above option the future branch, haven't tested your tree... well. I have not left anything out intentionally. But I have to patch some stuff locally. I have patches around for some arches on top. It does compile for me with those patches applied but does not boot. I'll give a try on SH4... asap ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] inet:rpc: fix authnone_marshal in multithreading context
This is a port of glibc's fix by Zack Weinberg as reported
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=142312,
and discussed in http://sourceware.org/ml/libc-alpha/2002-04/msg00069.html
and following.
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
libc/inet/rpc/auth_none.c | 59 +--
libc/inet/rpc/rpc_private.h |2 -
libc/inet/rpc/rpc_thread.c |1 -
3 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/libc/inet/rpc/auth_none.c b/libc/inet/rpc/auth_none.c
index c48bbfe..d066f6b 100644
--- a/libc/inet/rpc/auth_none.c
+++ b/libc/inet/rpc/auth_none.c
@@ -66,49 +66,48 @@ struct authnone_private_s {
char marshalled_client[MAX_MARSHAL_SIZE];
u_int mcnt;
};
-#ifdef __UCLIBC_HAS_THREADS__
-#define authnone_private (*(struct authnone_private_s
**)RPC_THREAD_VARIABLE(authnone_private_s))
-#else
-static struct authnone_private_s *authnone_private;
-#endif
-AUTH *
-authnone_create (void)
+static struct authnone_private_s authnone_private;
+__libc_once_define(static, authnone_private_guard);
+
+static void authnone_create_once (void);
+
+static void
+authnone_create_once (void)
{
struct authnone_private_s *ap;
XDR xdr_stream;
XDR *xdrs;
- ap = (struct authnone_private_s *) authnone_private;
- if (ap == NULL)
-{
- ap = (struct authnone_private_s *) calloc (1, sizeof (*ap));
- if (ap == NULL)
- return NULL;
- authnone_private = ap;
-}
- if (!ap-mcnt)
-{
- ap-no_client.ah_cred = ap-no_client.ah_verf = _null_auth;
- ap-no_client.ah_ops = (struct auth_ops *)ops;
- xdrs = xdr_stream;
- xdrmem_create (xdrs, ap-marshalled_client, (u_int) MAX_MARSHAL_SIZE,
-XDR_ENCODE);
- (void) xdr_opaque_auth (xdrs, ap-no_client.ah_cred);
- (void) xdr_opaque_auth (xdrs, ap-no_client.ah_verf);
- ap-mcnt = XDR_GETPOS (xdrs);
- XDR_DESTROY (xdrs);
-}
- return (ap-no_client);
+ ap = authnone_private;
+
+ ap-no_client.ah_cred = ap-no_client.ah_verf = _null_auth;
+ ap-no_client.ah_ops = (struct auth_ops *) ops;
+ xdrs = xdr_stream;
+ xdrmem_create(xdrs, ap-marshalled_client,
+(u_int) MAX_MARSHAL_SIZE, XDR_ENCODE);
+ (void) xdr_opaque_auth(xdrs, ap-no_client.ah_cred);
+ (void) xdr_opaque_auth(xdrs, ap-no_client.ah_verf);
+ ap-mcnt = XDR_GETPOS (xdrs);
+ XDR_DESTROY (xdrs);
+}
+
+AUTH *
+authnone_create (void)
+{
+ __libc_once (authnone_private_guard, authnone_create_once);
+ return authnone_private.no_client;
}
libc_hidden_def(authnone_create)
static bool_t
-authnone_marshal (AUTH *client attribute_unused, XDR *xdrs)
+authnone_marshal (AUTH *client, XDR *xdrs)
{
struct authnone_private_s *ap;
- ap = authnone_private;
+ /* authnone_create returned authnone_private-no_client, which is
+ the first field of struct authnone_private_s. */
+ ap = (struct authnone_private_s *) client;
if (ap == NULL)
return FALSE;
return (*xdrs-x_ops-x_putbytes) (xdrs, ap-marshalled_client, ap-mcnt);
diff --git a/libc/inet/rpc/rpc_private.h b/libc/inet/rpc/rpc_private.h
index ede3ddf..e1214d2 100644
--- a/libc/inet/rpc/rpc_private.h
+++ b/libc/inet/rpc/rpc_private.h
@@ -18,8 +18,6 @@ struct rpc_thread_variables {
struct pollfd *svc_pollfd_s; /* Global, rpc_common.c */
int svc_max_pollfd_s; /* Global, rpc_common.c */
- void*authnone_private_s;/* auth_none.c */
-
void*clnt_perr_buf_s; /* clnt_perr.c */
void*clntraw_private_s; /* clnt_raw.c */
diff --git a/libc/inet/rpc/rpc_thread.c b/libc/inet/rpc/rpc_thread.c
index 71303b2..3367659 100644
--- a/libc/inet/rpc/rpc_thread.c
+++ b/libc/inet/rpc/rpc_thread.c
@@ -32,7 +32,6 @@ __rpc_thread_destroy (void)
__rpc_thread_svc_cleanup ();
__rpc_thread_clnt_cleanup ();
/*__rpc_thread_key_cleanup (); */
- free (tvp-authnone_private_s);
free (tvp-clnt_perr_buf_s);
free (tvp-clntraw_private_s);
free (tvp-svcraw_private_s);
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: How to avoid symbol alias names?
On 23/01/2012 11.43, stl wrote: Hello, if I want to statically cross-compiled a file, what should I do to avoid symbol alias names? Thanks for your answers. what kind of problem/scenario you are trying to address ? what do you mean with avoiding alias ? carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] buildsys: fixup sigaction handling
On 28/01/2012 21.28, Bernhard Reutner-Fischer wrote:
commit:
http://git.uclibc.org/uClibc/commit/?id=83ce0cc4d5e93549f0a9447a9bd6b051f5f1b62f
branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
Thanks Bernhard,
I couldn't complete my patch last Friday. I was doing something similar.
Few comments inlined:
---
libc/signal/Makefile.in|2 +-
libc/sysdeps/linux/arm/Makefile.arch |6 +-
libc/sysdeps/linux/i386/Makefile.arch |6 +-
libc/sysdeps/linux/mips/Makefile.arch |3 +--
libc/sysdeps/linux/sparc/Makefile.arch |3 +--
libc/sysdeps/linux/x86_64/Makefile.arch|6 +-
libpthread/nptl/.gitignore |1 -
libpthread/nptl/sysdeps/pthread/Makefile.in| 10 ++
.../pthread/{sigaction.c = pt-sigaction.c}| 15 +++
9 files changed, 11 insertions(+), 41 deletions(-)
diff --git a/libc/signal/Makefile.in b/libc/signal/Makefile.in
index bb5ba8f..46c2af7 100644
--- a/libc/signal/Makefile.in
+++ b/libc/signal/Makefile.in
@@ -17,7 +17,7 @@ CSRC-$(UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL) += sysv_signal.c
CSRC-$(UCLIBC_SUSV4_LEGACY) += sigintr.c
ifeq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC-y:=$(filter-out raise.c sigaction.c,$(CSRC-y))
+CSRC-y:=$(filter-out raise.c,$(CSRC-y))
endif
ifneq ($(strip $(ARCH_OBJS)),)
diff --git a/libc/sysdeps/linux/arm/Makefile.arch
b/libc/sysdeps/linux/arm/Makefile.arch
index ddd104d..cd1710a 100644
--- a/libc/sysdeps/linux/arm/Makefile.arch
+++ b/libc/sysdeps/linux/arm/Makefile.arch
@@ -5,11 +5,7 @@
# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
#
-CSRC := brk.c ioperm.c iopl.c mmap.c __syscall_error.c
-
-ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC += sigaction.c
-endif
+CSRC := brk.c ioperm.c iopl.c mmap.c __syscall_error.c sigaction.c
SSRC := \
__longjmp.S setjmp.S bsd-setjmp.S \
diff --git a/libc/sysdeps/linux/i386/Makefile.arch
b/libc/sysdeps/linux/i386/Makefile.arch
index 668cca7..966f8b5 100644
--- a/libc/sysdeps/linux/i386/Makefile.arch
+++ b/libc/sysdeps/linux/i386/Makefile.arch
@@ -5,11 +5,7 @@
# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
#
-CSRC := brk.c __syscall_error.c
-
-ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC += sigaction.c
-endif
+CSRC := brk.c __syscall_error.c sigaction.c
SSRC := \
__longjmp.S setjmp.S bsd-setjmp.S bsd-_setjmp.S \
diff --git a/libc/sysdeps/linux/mips/Makefile.arch
b/libc/sysdeps/linux/mips/Makefile.arch
index 8bbc0bc..738cdd0 100644
--- a/libc/sysdeps/linux/mips/Makefile.arch
+++ b/libc/sysdeps/linux/mips/Makefile.arch
@@ -7,7 +7,7 @@
CSRC := \
__longjmp.c brk.c setjmp_aux.c mmap.c \
- cacheflush.c pread_write.c sysmips.c _test_and_set.c \
+ cacheflush.c pread_write.c sigaction.c sysmips.c _test_and_set.c \
readahead.c
SSRC := bsd-_setjmp.S bsd-setjmp.S setjmp.S syscall.S pipe.S syscall_error.S
@@ -17,7 +17,6 @@ CSRC += posix_fadvise.c posix_fadvise64.c
endif
ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC += sigaction.c
SSRC += vfork.S clone.S
endif
diff --git a/libc/sysdeps/linux/sparc/Makefile.arch
b/libc/sysdeps/linux/sparc/Makefile.arch
index 820b2fa..aa58756 100644
--- a/libc/sysdeps/linux/sparc/Makefile.arch
+++ b/libc/sysdeps/linux/sparc/Makefile.arch
@@ -5,14 +5,13 @@
# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
#
-CSRC := brk.c __syscall_error.c
+CSRC := brk.c __syscall_error.c sigaction.c
SSRC := \
__longjmp.S setjmp.S bsd-setjmp.S bsd-_setjmp.S \
syscall.S urem.S udiv.S umul.S sdiv.S rem.S pipe.S
ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC += sigaction.c
SSRC += fork.S vfork.S clone.S
endif
diff --git a/libc/sysdeps/linux/x86_64/Makefile.arch
b/libc/sysdeps/linux/x86_64/Makefile.arch
index 0d14650..3243d86 100644
--- a/libc/sysdeps/linux/x86_64/Makefile.arch
+++ b/libc/sysdeps/linux/x86_64/Makefile.arch
@@ -5,11 +5,7 @@
# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
#
-CSRC := brk.c __syscall_error.c mmap.c
-
-ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
-CSRC += sigaction.c
-endif
+CSRC := brk.c __syscall_error.c sigaction.c mmap.c
SSRC := \
__longjmp.S setjmp.S syscall.S bsd-setjmp.S bsd-_setjmp.S
diff --git a/libpthread/nptl/.gitignore b/libpthread/nptl/.gitignore
index 0a86898..6565dcd 100644
--- a/libpthread/nptl/.gitignore
+++ b/libpthread/nptl/.gitignore
@@ -26,6 +26,5 @@ sysdeps/pthread/pt-crtn.S
#
# symlinks
#
-sysdeps/pthread/pt-sigaction.c
sysdeps/pthread/pt-sigfillset.c
sysdeps/pthread/pt-sigprocmask.c
diff --git a/libpthread/nptl/sysdeps/pthread/Makefile.in
b/libpthread/nptl/sysdeps/pthread/Makefile.in
index
Re: static link with NPTL on ARM fails
On 26/01/2012 17.08, Johannes Stezenbach wrote: On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote: On 16/12/2011 18.36, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I have now some free time to look at pending patches. It's on my queue. I don't want to nag, but since I just had some time to work on my ARM toolchain crosstool-ng build I thought to let you know that with yesterday's git eb72efd this issue is still present. Johannes Hello, I don't think this fix is the best one; is rather a w/a. I'm reviewing the code as it seems we have a mess with sigaction symbols/aliased between libc and libpthread. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 12.13, Carmelo AMOROSO wrote:
On 26/01/2012 17.08, Johannes Stezenbach wrote:
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
On 16/12/2011 18.36, Johannes Stezenbach wrote:
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
On 16/12/11 15:57, Johannes Stezenbach wrote:
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c
2011-12-14 11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
...
I have now some free time to look at pending patches. It's on my queue.
I don't want to nag, but since I just had some time to work on my
ARM toolchain crosstool-ng build I thought to let you know that
with yesterday's git eb72efd this issue is still present.
Johannes
Hello,
I don't think this fix is the best one; is rather a w/a.
I'm reviewing the code as it seems we have a mess with sigaction
symbols/aliased between libc and libpthread.
Carmelo
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Feedback are welcome.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 15.55, Johannes Stezenbach wrote:
On Fri, Jan 27, 2012 at 02:17:25PM +0100, Carmelo AMOROSO wrote:
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Sounds good, but one question: When libc internally calls sigaction
and libpthread is also linked, which one should be called?
I would think it should call the pthread version.
frankly not sure. In the current implementation, when pthread are
enabled at build time (even if not used at runtime), the implementation
is taken from the pthread directory. So it should work as you expect.
Indeed, I'm thinking that there is not need at all to duplicate the
symbol into the pthread library, as the libc implementation is already
properly handling SIGCANCEL/SIGSETXID.
So, likely we should get rid of pt-sigaction.c... simply.
If libc wants
to call the libc version it would use __libc_sigaction explicitly.
However, with libc_hidden_proto(sigaction) in signal.h, libc
would end up calling __GI_sigaction which is the libc version, isn't it?
yes
Instead there could be a __GI___libc_sigaction.
- libc_hidden_proto(sigaction)
+ libc_hidden_proto(__libc_sigaction)
Thanks
Johannes
carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 14.17, Carmelo AMOROSO wrote:
On 27/01/2012 12.13, Carmelo AMOROSO wrote:
On 26/01/2012 17.08, Johannes Stezenbach wrote:
On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
On 16/12/2011 18.36, Johannes Stezenbach wrote:
On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
On 16/12/11 15:57, Johannes Stezenbach wrote:
I was able to fix the issue like this:
--- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig
2011-12-03 18:55:45.0 +0100
+++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c
2011-12-14 11:48:52.0 +0100
@@ -38,9 +38,9 @@
return __libc_sigaction (sig, act, oact);
}
-libc_hidden_proto(sigaction)
+hidden_proto(sigaction)
weak_alias (__sigaction, sigaction)
-libc_hidden_weak(sigaction)
+hidden_weak(sigaction)
#else
...
I have now some free time to look at pending patches. It's on my queue.
I don't want to nag, but since I just had some time to work on my
ARM toolchain crosstool-ng build I thought to let you know that
with yesterday's git eb72efd this issue is still present.
Johannes
Hello,
I don't think this fix is the best one; is rather a w/a.
I'm reviewing the code as it seems we have a mess with sigaction
symbols/aliased between libc and libpthread.
Carmelo
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
--- __libc_sigaction (global)
--- sigaction (weak alias of __libc_sigaction)
--- __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
--- sigaction (global)
--- __libc_sigaction (undefined)
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
and nothing duplicated into libpthread.
make more sense ?
carmelo
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Feedback are welcome.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 27/01/2012 16.54, Bernhard Reutner-Fischer wrote:
On Jan 27, 2012 4:47 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
So, to summarise I'd expect
libc.{so,a}
--- __libc_sigaction (global)
--- __GI_sigaction (hidden alias for internal use)
--- sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
I think that should be a strong alias if NO_THREADS.
indeed.. not expected to be overridden.
and nothing duplicated into libpthread.
make more sense ?
Yes.
:)
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: kernel_types.h really needed ?
On 24/01/2012 3.17, Mike Frysinger wrote: On Monday 23 January 2012 13:26:44 Carmelo AMOROSO wrote: I'm wondering if we do still need to have in uclibc a version of kernel_types.h, any idea ? the alternative is ... ? relying on linux/types.h ? linux/posix_types.h for example if we don't care about things older than like linux-2.6.18, then we prob can drop kernel_types.h. but i suspect some people do care about older targets. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: remove pointless inclusion of kernel_types.
On 24/01/2012 7.56, Bernhard Reutner-Fischer wrote: On Jan 24, 2012 2:04 AM, Khem Raj raj.k...@gmail.com wrote: On (23/01/12 19:59), Carmelo AMOROSO wrote: Indeed, the common, mips and xtensa version of pread_write.c do not refer any of types defined in kernel_types.h, so not needed to include this header. (Build untested on mips, xtensa) looks ok to me. There are further patches in future branch which unify pread_write.c It is better to start off the version that we will pickup shortly from the future branch so please defer this for now. as you prefer (it was just a simple tidy-up). Thanks cheers ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
kernel_types.h really needed ?
Folks, I'm wondering if we do still need to have in uclibc a version of kernel_types.h, any idea ? thanks, carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] libc: remove pointless inclusion of kernel_types.
Indeed, the common, mips and xtensa version of pread_write.c do not refer any of types defined in kernel_types.h, so not needed to include this header. (Build untested on mips, xtensa) Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com CC: Chris Zankel ch...@zankel.net CC: Khem Raj raj.k...@gmail.com --- libc/sysdeps/linux/common/pread_write.c |2 -- libc/sysdeps/linux/mips/pread_write.c |3 --- libc/sysdeps/linux/xtensa/pread_write.c |2 -- 3 files changed, 0 insertions(+), 7 deletions(-) diff --git a/libc/sysdeps/linux/common/pread_write.c b/libc/sysdeps/linux/common/pread_write.c index 88e6957..855b1c8 100644 --- a/libc/sysdeps/linux/common/pread_write.c +++ b/libc/sysdeps/linux/common/pread_write.c @@ -25,8 +25,6 @@ extern __typeof(pread64) __libc_pread64; extern __typeof(pwrite64) __libc_pwrite64; #endif -#include bits/kernel_types.h - #ifdef __NR_pread # define __NR___syscall_pread __NR_pread diff --git a/libc/sysdeps/linux/mips/pread_write.c b/libc/sysdeps/linux/mips/pread_write.c index ea6b15f..5518844 100644 --- a/libc/sysdeps/linux/mips/pread_write.c +++ b/libc/sysdeps/linux/mips/pread_write.c @@ -33,9 +33,6 @@ extern __typeof(pread64) __libc_pread64; extern __typeof(pwrite64) __libc_pwrite64; #endif -#include bits/kernel_types.h - - #ifdef __NR_pread # if _MIPS_SIM == _MIPS_SIM_ABI64 diff --git a/libc/sysdeps/linux/xtensa/pread_write.c b/libc/sysdeps/linux/xtensa/pread_write.c index 71ba22b..beeb203 100644 --- a/libc/sysdeps/linux/xtensa/pread_write.c +++ b/libc/sysdeps/linux/xtensa/pread_write.c @@ -25,8 +25,6 @@ extern __typeof(pread64) __libc_pread64; extern __typeof(pwrite64) __libc_pwrite64; #endif -#include bits/kernel_types.h - #ifdef __NR_pread # define __NR___syscall_pread __NR_pread -- 1.7.4.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libubacktrace: Add arm implementation
On 21/01/12 20:42, Khem Raj wrote: On Sat, Jan 21, 2012 at 6:47 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 21/01/2012 15.08, Khem Raj wrote: Arm has a different mechanism of getting _Unwind_GetIP. Therefore we profile arch specific backtrace file. Signed-off-by: Khem Raj raj.k...@gmail.com --- libubacktrace/Makefile.in | 26 -- libubacktrace/arm/Makefile.arch | 21 libubacktrace/arm/backtrace.c | 104 +++ 3 files changed, 145 insertions(+), 6 deletions(-) create mode 100644 libubacktrace/arm/Makefile.arch create mode 100644 libubacktrace/arm/backtrace.c diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in index b18e3e6..f675bf5 100644 --- a/libubacktrace/Makefile.in +++ b/libubacktrace/Makefile.in @@ -6,7 +6,7 @@ # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. # -subdirs += libubacktrace +subdirs += libubacktrace libubacktrace/$(TARGET_ARCH) CFLAGS-libubacktrace := -DNOT_IN_libc -DIS_IN_libubacktrace $(SSP_ALL_CFLAGS) @@ -23,22 +23,36 @@ libubacktrace_FULL_NAME := libubacktrace-$(VERSION).so libubacktrace_DIR := $(top_srcdir)libubacktrace libubacktrace_OUT := $(top_builddir)libubacktrace +libubacktrace_ARCH_DIR:=$(libubacktrace_DIR)/$(TARGET_ARCH) +libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH) + +-include $(libubacktrace_ARCH_DIR)/Makefile.arch + libubacktrace_SRC-y := libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c backtracesymsfd.c +# remove generic sources, if arch specific version is present +ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),) +libubacktrace_SRC-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y)) +endif + # -fasynchronous-unwind-tables is required for backtrace to work using dwarf2 CFLAGS-backtrace.c := -fasynchronous-unwind-tables +# pass common flags to arch dirs +ifneq ($(strip $(libubacktrace_ARCH_OBJS)),) +CFLAGS-libubacktrace/$(TARGET_ARCH)/ := $(CFLAGS-libubacktrace) +endif -libubacktrace_SRCS := $(addprefix $(libubacktrace_DIR)/,$(libubacktrace_SRC-y)) +libubacktrace_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y)) libubacktrace_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS)) ifeq ($(DOPIC),y) -libubacktrace-a-y := $(libubacktrace_OBJS:.o=.os) +libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) else -libubacktrace-a-y := $(libubacktrace_OBJS) +libubacktrace-a-y += $(libubacktrace_OBJS) endif -libubacktrace-so-y := $(libubacktrace_OBJS:.o=.os) +libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so @@ -61,7 +75,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: $(libubacktrace-so-y) $(Q)$(RM) $@ $(do_ar) -$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) +$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) $(Q)$(RM) $@ $(compile-m) diff --git a/libubacktrace/arm/Makefile.arch b/libubacktrace/arm/Makefile.arch new file mode 100644 index 000..dab3637 --- /dev/null +++ b/libubacktrace/arm/Makefile.arch @@ -0,0 +1,21 @@ +# Makefile for uClibc (libubacktrace) +# +# Author: Khem Raj raj.k...@gmail.com + +# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. +# + +libubacktrace_ARCH_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c +libubacktrace_ARCH_SRCS := $(addprefix $(libubacktrace_ARCH_DIR)/,$(libubacktrace_ARCH_SRC-y)) +libubacktrace_ARCH_OBJS := $(patsubst $(libubacktrace_ARCH_DIR)/%.c,$(libubacktrace_ARCH_OUT)/%.o,$(libubacktrace_ARCH_SRCS)) + +ifeq ($(DOPIC),y) +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os) +else +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS) +endif +libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os) + +ifeq ($(CONFIG_ARM_EABI),y) +LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a) +endif with my proposed patch to move __aeabi_unwind_cpp_pr in uclibc_shared.a should not be needed. lets make this change after you have installed that patch. For now I will keep it. so, do we agree on that patch ? thanks, carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations
On 21/01/2012 9.28, Khem Raj wrote: On (20/01/12 10:36), Carmelo AMOROSO wrote: On 20/01/2012 7.55, Khem Raj wrote: On Thu, Jan 19, 2012 at 6:42 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 19/01/2012 15.28, Carmelo AMOROSO wrote: Fill properly the sym_ref fields when invoking _dl_find_hash to lookup symbols this did not make the segfault go away. Although this patch is ok. this problem is a crash in libstdc++ I did not have debug info to get more info but I am building an image with debug info I can't help with mips. As soon as you have some debug out, I can try to figure out where the problem is. I've looked at the change history of mips/elfinterp.c, I'm not seeing currently other fix than this one, but I'll keep on looking at this. I see the problem and attached patch fixed it. Relocations on mips were being resolved before the new module scope was added to scope map and it was causing the libstdc++ constructors to fail to run since the symbols were not resolved properly. great fine. Fix makes sense. Acked-by: Carmelo Amoroso carmelo.amor...@st.com I will push the three fixes we have in this series soon unless someone has objections none from me. -Khem Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libubacktrace: Add arm implementation
On 21/01/2012 15.08, Khem Raj wrote: Arm has a different mechanism of getting _Unwind_GetIP. Therefore we profile arch specific backtrace file. Signed-off-by: Khem Raj raj.k...@gmail.com --- libubacktrace/Makefile.in | 26 -- libubacktrace/arm/Makefile.arch | 21 libubacktrace/arm/backtrace.c | 104 +++ 3 files changed, 145 insertions(+), 6 deletions(-) create mode 100644 libubacktrace/arm/Makefile.arch create mode 100644 libubacktrace/arm/backtrace.c diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in index b18e3e6..f675bf5 100644 --- a/libubacktrace/Makefile.in +++ b/libubacktrace/Makefile.in @@ -6,7 +6,7 @@ # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. # -subdirs += libubacktrace +subdirs += libubacktrace libubacktrace/$(TARGET_ARCH) CFLAGS-libubacktrace := -DNOT_IN_libc -DIS_IN_libubacktrace $(SSP_ALL_CFLAGS) @@ -23,22 +23,36 @@ libubacktrace_FULL_NAME := libubacktrace-$(VERSION).so libubacktrace_DIR := $(top_srcdir)libubacktrace libubacktrace_OUT := $(top_builddir)libubacktrace +libubacktrace_ARCH_DIR:=$(libubacktrace_DIR)/$(TARGET_ARCH) +libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH) + +-include $(libubacktrace_ARCH_DIR)/Makefile.arch + libubacktrace_SRC-y := libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c backtracesymsfd.c +# remove generic sources, if arch specific version is present +ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),) +libubacktrace_SRC-y := $(filter-out $(notdir $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y)) +endif + # -fasynchronous-unwind-tables is required for backtrace to work using dwarf2 CFLAGS-backtrace.c := -fasynchronous-unwind-tables +# pass common flags to arch dirs +ifneq ($(strip $(libubacktrace_ARCH_OBJS)),) +CFLAGS-libubacktrace/$(TARGET_ARCH)/ := $(CFLAGS-libubacktrace) +endif -libubacktrace_SRCS := $(addprefix $(libubacktrace_DIR)/,$(libubacktrace_SRC-y)) +libubacktrace_SRCS := $(patsubst %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y)) libubacktrace_OBJS := $(patsubst $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS)) ifeq ($(DOPIC),y) -libubacktrace-a-y := $(libubacktrace_OBJS:.o=.os) +libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os) else -libubacktrace-a-y := $(libubacktrace_OBJS) +libubacktrace-a-y += $(libubacktrace_OBJS) endif -libubacktrace-so-y := $(libubacktrace_OBJS:.o=.os) +libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os) lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so @@ -61,7 +75,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: $(libubacktrace-so-y) $(Q)$(RM) $@ $(do_ar) -$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) +$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) $(libubacktrace_ARCH_SRCS) $(Q)$(RM) $@ $(compile-m) diff --git a/libubacktrace/arm/Makefile.arch b/libubacktrace/arm/Makefile.arch new file mode 100644 index 000..dab3637 --- /dev/null +++ b/libubacktrace/arm/Makefile.arch @@ -0,0 +1,21 @@ +# Makefile for uClibc (libubacktrace) +# +# Author: Khem Raj raj.k...@gmail.com + +# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. +# + +libubacktrace_ARCH_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c +libubacktrace_ARCH_SRCS := $(addprefix $(libubacktrace_ARCH_DIR)/,$(libubacktrace_ARCH_SRC-y)) +libubacktrace_ARCH_OBJS := $(patsubst $(libubacktrace_ARCH_DIR)/%.c,$(libubacktrace_ARCH_OUT)/%.o,$(libubacktrace_ARCH_SRCS)) + +ifeq ($(DOPIC),y) +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os) +else +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS) +endif +libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os) + +ifeq ($(CONFIG_ARM_EABI),y) +LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a) +endif with my proposed patch to move __aeabi_unwind_cpp_pr in uclibc_shared.a should not be needed. diff --git a/libubacktrace/arm/backtrace.c b/libubacktrace/arm/backtrace.c new file mode 100644 index 000..8a18c6c --- /dev/null +++ b/libubacktrace/arm/backtrace.c @@ -0,0 +1,104 @@ +/* + * Perform stack unwinding by using the _Unwind_Backtrace. + * + * User application that wants to use backtrace needs to be + * compiled with -fexceptions option and -rdynamic to get full + * symbols printed. + * + * Copyright (C) 2009, 2010 STMicroelectronics Ltd. + * + * Author(s): Giuseppe Cavallaro peppe.cavall...@st.com + * - Initial implementation for glibc + * + * Author(s): Carmelo Amoroso carmelo.amor...@st.com + * - Reworked for uClibc + * - use dlsym/dlopen from libdl + * - rewrite initialisation to not use libc_once + * - make it available in static link too + * fell free to remove old authorship + * Author(s): Khem Raj raj.k
Re: [PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations
On 20/01/2012 7.55, Khem Raj wrote:
On Thu, Jan 19, 2012 at 6:42 AM, Carmelo AMOROSO carmelo.amor...@st.com
wrote:
On 19/01/2012 15.28, Carmelo AMOROSO wrote:
Fill properly the sym_ref fields when invoking _dl_find_hash to lookup
symbols
this did not make the segfault go away. Although this patch is ok.
this problem is a crash in libstdc++ I did not have debug info to
get more info but I am building an image with debug info
I can't help with mips. As soon as you have some debug out, I can try to
figure out where the problem is.
I've looked at the change history of mips/elfinterp.c, I'm not seeing
currently other fix than this one, but I'll keep on looking at this.
Carmelo
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/ldso/mips/elfinterp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c
index b748839..5d0eff5 100644
--- a/ldso/ldso/mips/elfinterp.c
+++ b/ldso/ldso/mips/elfinterp.c
@@ -161,7 +161,7 @@ int _dl_parse_relocation_information(struct dyn_elf
*xpnt,
unsigned long old_val=0;
#endif
- struct symbol_ref sym_ref = { NULL, NULL };
+ struct symbol_ref sym_ref;
/* Now parse the relocation information */
rel_size = rel_size / sizeof(ElfW(Rel));
rpnt = (ELF_RELOC *) rel_addr;
@@ -187,6 +187,8 @@ int _dl_parse_relocation_information(struct dyn_elf
*xpnt,
#endif
if (reloc_type == R_MIPS_JUMP_SLOT || reloc_type ==
R_MIPS_COPY) {
+ sym_ref.tpnt = NULL;
+ sym_ref.sym = symtab[symtab_index];
symbol_addr = (unsigned long)_dl_find_hash(symname,
scope,
tpnt,
Khem,
not sure, but this could be a problem. Unfortunately the code that
handle relocations for mips is enough different from all other
architectures.
The symbol scope redesign was mixed with another big change to handle
protected symbols, so the risk of breakage on some archs were high.
Please let me know if it helps.
Thanks,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libdl: fix dlclose handling of symbol scope
On 19/01/2012 0.10, Khem Raj wrote: On Wed, Jan 18, 2012 at 9:42 AM, Filippo ARCIDIACONO filippo.arcidiac...@st.com wrote: With your fix was ok? I did not try mips with my fix but I will try soon In our sh4 target pango-querymodules runs without any problem. yes it runs fine on ppc, x86,amd64 here as well. armv7 is fine as well (with new patch). carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations
Fill properly the sym_ref fields when invoking _dl_find_hash to lookup
symbols
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/ldso/mips/elfinterp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c
index b748839..5d0eff5 100644
--- a/ldso/ldso/mips/elfinterp.c
+++ b/ldso/ldso/mips/elfinterp.c
@@ -161,7 +161,7 @@ int _dl_parse_relocation_information(struct dyn_elf *xpnt,
unsigned long old_val=0;
#endif
- struct symbol_ref sym_ref = { NULL, NULL };
+ struct symbol_ref sym_ref;
/* Now parse the relocation information */
rel_size = rel_size / sizeof(ElfW(Rel));
rpnt = (ELF_RELOC *) rel_addr;
@@ -187,6 +187,8 @@ int _dl_parse_relocation_information(struct dyn_elf *xpnt,
#endif
if (reloc_type == R_MIPS_JUMP_SLOT || reloc_type ==
R_MIPS_COPY) {
+ sym_ref.tpnt = NULL;
+ sym_ref.sym = symtab[symtab_index];
symbol_addr = (unsigned long)_dl_find_hash(symname,
scope,
tpnt,
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations
On 19/01/2012 15.28, Carmelo AMOROSO wrote:
Fill properly the sym_ref fields when invoking _dl_find_hash to lookup
symbols
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/ldso/mips/elfinterp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c
index b748839..5d0eff5 100644
--- a/ldso/ldso/mips/elfinterp.c
+++ b/ldso/ldso/mips/elfinterp.c
@@ -161,7 +161,7 @@ int _dl_parse_relocation_information(struct dyn_elf *xpnt,
unsigned long old_val=0;
#endif
- struct symbol_ref sym_ref = { NULL, NULL };
+ struct symbol_ref sym_ref;
/* Now parse the relocation information */
rel_size = rel_size / sizeof(ElfW(Rel));
rpnt = (ELF_RELOC *) rel_addr;
@@ -187,6 +187,8 @@ int _dl_parse_relocation_information(struct dyn_elf *xpnt,
#endif
if (reloc_type == R_MIPS_JUMP_SLOT || reloc_type ==
R_MIPS_COPY) {
+ sym_ref.tpnt = NULL;
+ sym_ref.sym = symtab[symtab_index];
symbol_addr = (unsigned long)_dl_find_hash(symname,
scope,
tpnt,
Khem,
not sure, but this could be a problem. Unfortunately the code that
handle relocations for mips is enough different from all other
architectures.
The symbol scope redesign was mixed with another big change to handle
protected symbols, so the risk of breakage on some archs were high.
Please let me know if it helps.
Thanks,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 17/01/2012 2.59, Khem Raj wrote: On Mon, Jan 16, 2012 at 1:36 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 16/01/2012 9.09, Carmelo Amoroso wrote: On 16/01/2012 8.53, Khem Raj wrote: On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo I have a patch (sort of) which fixes this issue have a look at it. Problem is that its trying to unload sub scopes after it has been removed from global scope so I just delayed the removal of dlopened library what is triggering the problem is the use of atexit() I'd ask.. is it correct that a dlopen-ed shared library install a function via atexit() to be called at program exit, if the shared library could be un-loaded at any time during the program's life ? does library know if it will be dlopened all the time ? no it doesn't obviously. I've read again atexit man pages, initially it simply refers to the use of atexit in binaries (so the reason of my doubts), later in the Note I've read a reference to the use of atexit in shared libraries acting as a destructor so my concerns are invalid. I'd say that with the old it was just working fortunately ! The shared library image is actually un-mapped from the system, why we should expect to have some of its symbols still alive ? how about the dependencies that it loaded again I was wrong. Looking at the code more carefully, inded in the loop where
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 17/01/2012 9.41, Carmelo AMOROSO wrote: On 17/01/2012 2.59, Khem Raj wrote: On Mon, Jan 16, 2012 at 1:36 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 16/01/2012 9.09, Carmelo Amoroso wrote: On 16/01/2012 8.53, Khem Raj wrote: On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo I have a patch (sort of) which fixes this issue have a look at it. Problem is that its trying to unload sub scopes after it has been removed from global scope so I just delayed the removal of dlopened library what is triggering the problem is the use of atexit() I'd ask.. is it correct that a dlopen-ed shared library install a function via atexit() to be called at program exit, if the shared library could be un-loaded at any time during the program's life ? does library know if it will be dlopened all the time ? no it doesn't obviously. I've read again atexit man pages, initially it simply refers to the use of atexit in binaries (so the reason of my doubts), later in the Note I've read a reference to the use of atexit in shared libraries acting as a destructor so my concerns are invalid. I'd say that with the old it was just working fortunately ! The shared library image is actually un-mapped from the system, why we should expect to have some of its symbols still alive ? how about the dependencies that it loaded again I was wrong
[PATCH] libdl: fix dlclose handling of symbol scope
Defer removal of the local scope of a dl-opened library after
all the destructors (of itself and related dependencies) are actually
get unloaded, otherwise any function registered via atexit()
won't be resolved.
Signed-off-by: Khem Raj raj.k...@gmail.com
Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/libdl/libdl.c | 33 +
1 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/ldso/libdl/libdl.c b/ldso/libdl/libdl.c
index bc3ef8a..da3c405 100644
--- a/ldso/libdl/libdl.c
+++ b/ldso/libdl/libdl.c
@@ -780,7 +780,9 @@ static int do_dlclose(void *vhandle, int need_fini)
struct dyn_elf *handle;
unsigned int end = 0, start = 0x;
unsigned int i, j;
- struct r_scope_elem *ls;
+ struct r_scope_elem *ls, *ls_next = NULL;
+ struct elf_resolve **handle_rlist;
+
#if defined(USE_TLS) USE_TLS
bool any_tls = false;
size_t tls_free_start = NO_TLS_OFFSET;
@@ -813,6 +815,19 @@ static int do_dlclose(void *vhandle, int need_fini)
free(handle);
return 0;
}
+
+ /* Store the handle's local scope array for later removal */
+ handle_rlist = handle-dyn-symbol_scope.r_list;
+
+ /* Store references to the local scope entries for later removal */
+ for (ls = _dl_loaded_modules-symbol_scope; ls ls-next; ls =
ls-next)
+ if (ls-next-r_list[0] == handle-dyn) {
+ break;
+ }
+ /* ls points to the previous local symbol scope */
+ if(ls ls-next)
+ ls_next = ls-next-next;
+
/* OK, this is a valid handle - now close out the file */
for (j = 0; j handle-init_fini.nlist; ++j) {
tpnt = handle-init_fini.init_fini[j];
@@ -974,16 +989,6 @@ static int do_dlclose(void *vhandle, int need_fini)
}
}
- if (handle-dyn == tpnt) {
- /* Unlink the local scope from global one */
- for (ls = _dl_loaded_modules-symbol_scope;
ls; ls = ls-next)
- if (ls-next-r_list[0] == tpnt) {
- _dl_if_debug_print(removing
symbol_scope: %s\n, tpnt-libname);
- break;
- }
- ls-next = ls-next-next;
- }
-
/* Next, remove tpnt from the global symbol table list
*/
if (_dl_symbol_tables) {
if (_dl_symbol_tables-dyn == tpnt) {
@@ -1005,10 +1010,14 @@ static int do_dlclose(void *vhandle, int need_fini)
}
}
free(tpnt-libname);
- free(tpnt-symbol_scope.r_list);
free(tpnt);
}
}
+ /* Unlink and release the handle's local scope from global one */
+ if(ls)
+ ls-next = ls_next;
+ free(handle_rlist);
+
for (rpnt1 = handle-next; rpnt1; rpnt1 = rpnt1_tmp) {
rpnt1_tmp = rpnt1-next;
free(rpnt1);
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libdl: fix dlclose handling of symbol scope
On 17/01/2012 19.24, Mike Frysinger wrote: On Tuesday 17 January 2012 12:23:43 Carmelo AMOROSO wrote: Defer removal of the local scope of a dl-opened library after all the destructors (of itself and related dependencies) are actually get unloaded, otherwise any function registered via atexit() won't be resolved. test case ? :) -mike Khem's one (http://www.uclibc.org/~kraj/reproducer_v2.tar.gz) Do you mean to add to the test-suite ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libdl: fix dlclose handling of symbol scope
On 18/01/2012 7.58, Khem Raj wrote:
On Tue, Jan 17, 2012 at 9:23 AM, Carmelo AMOROSO carmelo.amor...@st.com
wrote:
Defer removal of the local scope of a dl-opened library after
all the destructors (of itself and related dependencies) are actually
get unloaded, otherwise any function registered via atexit()
won't be resolved.
this patch works nicely. I so far tried it on x86 but I will test
other arches soon
I've tested on armv7 and sh4.
but the patch is good to go in with testcase added as Mike pointed
ok, I'll manage to integrate your one in the testsuite infrastructure.
As a note aside, we have discovered some minor problems (not blocking)
in the way the symbol scope is managed in libdl when a library is
already present in the start-up list (not dlopen-ed). I haven't yet a
test case to show the issue anyway.
It's not blocking anyway the 0.9.33 IMO.
Further there is probably a mem leak in the local scope of the
dependencies. We'll see to fix.
Carmelo
Signed-off-by: Khem Raj raj.k...@gmail.com
Signed-off-by: Filippo Arcidiacono filippo.arcidiac...@st.com
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/libdl/libdl.c | 33 +
1 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/ldso/libdl/libdl.c b/ldso/libdl/libdl.c
index bc3ef8a..da3c405 100644
--- a/ldso/libdl/libdl.c
+++ b/ldso/libdl/libdl.c
@@ -780,7 +780,9 @@ static int do_dlclose(void *vhandle, int need_fini)
struct dyn_elf *handle;
unsigned int end = 0, start = 0x;
unsigned int i, j;
- struct r_scope_elem *ls;
+ struct r_scope_elem *ls, *ls_next = NULL;
+ struct elf_resolve **handle_rlist;
+
#if defined(USE_TLS) USE_TLS
bool any_tls = false;
size_t tls_free_start = NO_TLS_OFFSET;
@@ -813,6 +815,19 @@ static int do_dlclose(void *vhandle, int need_fini)
free(handle);
return 0;
}
+
+ /* Store the handle's local scope array for later removal */
+ handle_rlist = handle-dyn-symbol_scope.r_list;
+
+ /* Store references to the local scope entries for later removal */
+ for (ls = _dl_loaded_modules-symbol_scope; ls ls-next; ls =
ls-next)
+ if (ls-next-r_list[0] == handle-dyn) {
+ break;
+ }
+ /* ls points to the previous local symbol scope */
+ if(ls ls-next)
+ ls_next = ls-next-next;
+
/* OK, this is a valid handle - now close out the file */
for (j = 0; j handle-init_fini.nlist; ++j) {
tpnt = handle-init_fini.init_fini[j];
@@ -974,16 +989,6 @@ static int do_dlclose(void *vhandle, int need_fini)
}
}
- if (handle-dyn == tpnt) {
- /* Unlink the local scope from global one */
- for (ls = _dl_loaded_modules-symbol_scope;
ls; ls = ls-next)
- if (ls-next-r_list[0] == tpnt) {
- _dl_if_debug_print(removing
symbol_scope: %s\n, tpnt-libname);
- break;
- }
- ls-next = ls-next-next;
- }
-
/* Next, remove tpnt from the global symbol table
list */
if (_dl_symbol_tables) {
if (_dl_symbol_tables-dyn == tpnt) {
@@ -1005,10 +1010,14 @@ static int do_dlclose(void *vhandle, int need_fini)
}
}
free(tpnt-libname);
- free(tpnt-symbol_scope.r_list);
free(tpnt);
}
}
+ /* Unlink and release the handle's local scope from global one */
+ if(ls)
+ ls-next = ls_next;
+ free(handle_rlist);
+
for (rpnt1 = handle-next; rpnt1; rpnt1 = rpnt1_tmp) {
rpnt1_tmp = rpnt1-next;
free(rpnt1);
--
1.7.4.4
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 16/01/2012 8.53, Khem Raj wrote: On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo I have a patch (sort of) which fixes this issue have a look at it. Problem is that its trying to unload sub scopes after it has been removed from global scope so I just delayed the removal of dlopened library what is triggering the problem is the use of atexit() http://www.uclibc.org/~kraj/fix_libdl.patch looking at it ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 16/01/2012 9.09, Carmelo Amoroso wrote: On 16/01/2012 8.53, Khem Raj wrote: On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo I have a patch (sort of) which fixes this issue have a look at it. Problem is that its trying to unload sub scopes after it has been removed from global scope so I just delayed the removal of dlopened library what is triggering the problem is the use of atexit() I'd ask.. is it correct that a dlopen-ed shared library install a function via atexit() to be called at program exit, if the shared library could be un-loaded at any time during the program's life ? I'd say that with the old it was just working fortunately ! The shared library image is actually un-mapped from the system, why we should expect to have some of its symbols still alive ? http://www.uclibc.org/~kraj/fix_libdl.patch looking at it not considering the concerns on the use of atexit, this patch is correct. Could we avoid to use the unlink_local_scope guard and test the stored_ls pointer directly ? carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 16/01/2012 10.36, Carmelo Amoroso wrote: On 16/01/2012 9.09, Carmelo Amoroso wrote: On 16/01/2012 8.53, Khem Raj wrote: On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo I have a patch (sort of) which fixes this issue have a look at it. Problem is that its trying to unload sub scopes after it has been removed from global scope so I just delayed the removal of dlopened library what is triggering the problem is the use of atexit() I'd ask.. is it correct that a dlopen-ed shared library install a function via atexit() to be called at program exit, if the shared library could be un-loaded at any time during the program's life ? I'd say that with the old it was just working fortunately ! The shared library image is actually un-mapped from the system, why we should expect to have some of its symbols still alive ? http://www.uclibc.org/~kraj/fix_libdl.patch looking at it not considering the concerns on the use of atexit, this patch is correct. Could we avoid to use the unlink_local_scope guard and test the stored_ls pointer directly ? carmelo hum still wondering how original lookup mechanism worked !? ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity
On 15/01/2012 1.31, Mike Frysinger wrote: On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote: Test clean can be invoked with -j to exploits parallelism. why don't you use `make -j` then ? i don't think -j munging belongs in any Makefile here. I do already use, but this one improved a lot more the clean on test due to how they have been implemented Verbosity mechanism aligned to main libc one. this is probably OK, but i feel like we should work on merging the two frameworks instead of expanding. good point, indeed. -mike carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity
On 15/01/2012 1.33, Mike Frysinger wrote: On Saturday 14 January 2012 19:31:16 Mike Frysinger wrote: On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote: Test clean can be invoked with -j to exploits parallelism. why don't you use `make -j` then ? i don't think -j munging belongs in any Makefile here. also, you might be interested in the commit i just pushed which brings `make clean` down from ~20 seconds to ~2 seconds. the underlying issue wasn't really lack of parallelism in the make system. -mike noted (later). I'' give it a try. cheers ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: skip compiler flag checking for clean targets
On 15/01/2012 19.37, Mike Frysinger wrote: On Sunday 15 January 2012 13:23:54 Mike Frysinger wrote: On Sunday 15 January 2012 13:11:58 Mike Frysinger wrote: As suggested by Bernhard, there is no point in evaluating the compiler's flag availability when cleaning, so skip things in that case. If there are variables that change targets based on the flags, then things are already broken and need fixing independently. this improves my `make clean` time from ~2.4s to ~1.5s. i should be able shave some more off that by fixing up the include_clean target. ok, that's been committed. the biggest slowdown now is just the recursive makes (mostly in test/). this is where -j helped in the original patch. carmelo -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj raj.k...@gmail.com wrote: On Fri, Jan 13, 2012 at 1:37 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. I tried to reverse it as well but the problem remained. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? this is potentially possible. I will try to debug it through This is the problem that happens with the new scoping and does not happen without it Error reading Pango modules file (matchbox-desktop:1058): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/etc/pango/pango.modules' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:1058): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' here is the error /usr/bin/pango-querymodules: can't resolve symbol '_ZNSt14error_categoryD2Ev' in lib '/usr/lib/libstdc++.so.6'. this does not happen without scope patch pango-querymodules loads a shared library /usr/lib/pango/1.6.0/modules/pango-basic-fc.so using dlopen and this library had libstdc++.so.6 in its DT_NEEDED entries I was trying to create a small testcase where I created a small binary which would dlopen another .so which has libstdc++ in DT_NEEDED in its header so not able to reproduce a small testcase but making some progress I might have a test case here http://uclibc.org/~kraj/reproducer_v2.tar.gz untar it on target and run make and the ./run.sh with buggy libraries i get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so /home/root/rep/reproducer_v2/main: can't resolve symbol '_libC_fini' in lib './/libC.so'. whereas without the scopes patch I get root@qemux86:~/rep/reproducer_v2# ./run.sh 1)main:dlopen libA.so 4)libC:dlopen libB.so 5)libC:atexit(libC_fini) 6)main:dlclose libA.so 7)libC:finish - atexit() 8)main:finish main root@qemux86:~/rep/reproducer_v2# I think thats the problem that I am facing in pango-querymodules as well another data point is if I use BIND_NOW then it works too. let me know if you can reproduce it with this testcase Thanks -Khem Thanks khem for your effort in reproducing. I-ll let you know asap. We will focus on this 100% since now. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] tests: speed up make invocation in test clean and fix verbosity
From: Salvatore CRO salvatore@st.com Test clean can be invoked with -j to exploits parallelism. Verbosity mechanism aligned to main libc one. Signed-off-by: Salvatore Cro salvatore@st.com Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- Makefile.in|2 +- test/Rules.mak | 10 ++ 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/Makefile.in b/Makefile.in index b7b4917..9512032 100644 --- a/Makefile.in +++ b/Makefile.in @@ -481,7 +481,7 @@ include_clean: clean: include_clean $(Q)$(RM) -r $(top_builddir)lib $(top_builddir)include/bits @$(MAKE) -C utils CLEAN_utils - +$(MAKE) -s -C test clean + +$(MAKE) -j -C test clean @$(RM) $(top_builddir)include/linux $(top_builddir)include/asm* $(Q)$(RM) $(top_builddir)extra/scripts/unifdef $(Q)$(RM) -r $(LOCAL_INSTALL_PATH) diff --git a/test/Rules.mak b/test/Rules.mak index 2131a7b..efec928 100644 --- a/test/Rules.mak +++ b/test/Rules.mak @@ -104,9 +104,15 @@ Q:= @ SCAT := -@true else ifneq ($(V)$(VERBOSE),) +ifeq ($(V),1) +DISP := bri# brief, currently same as pur +Q := @ +SCAT := -@true +else DISP := ver Q:= SCAT := cat +endif else DISP := pur Q:= @ @@ -130,6 +136,10 @@ ver_showclean = ver_showdiff = true echo ver_showlink = true echo ver_showtest = printf \n$(banner)\nTEST $(notdir $(CURDIR))/ $(@:.exe=)\n$(banner)\n +bri_showclean = $(pur_showclean) +bri_showdiff = $(pur_showdiff) +bri_showlink = $(pur_showlink) +bri_showtest = $(pur_showtest) do_showclean = $($(DISP)_showclean) do_showdiff = $($(DISP)_showdiff) do_showlink = $($(DISP)_showlink) -- 1.7.4.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On 11/01/2012 8.44, Khem Raj wrote: khem ? any news ? no unfortunately, had no time to delve further. once I have turned a merge into patch which was causing the regression, let me go down that path. let hi Carmelo Hi khem Attached patch is causing the trouble. and I have ok # LDSO_STANDALONE_SUPPORT is not set # LDSO_PRELINK_SUPPORT is not set ok and since I see the same issue on all architectures probably its not elfinterp changes too. Mostly it seems likely that it could be in the way the scopes are being handled we have reviewed several times this change before committing. Anyway we will review it again. We have not ever seen any failure in the lookup with all of our tests. The only change in the way the symbol scope is created is in where the ld.so is added. In the original code it was the last entry of the global scope, while with the new structure in place it was added as soon as found (as glibc actually does) and I don't really think this could have some impact. We are trying to startup a X system on our platform. Is there any simple X app we can run to show the failure ? Is some .so failing to be dl-opened due to unresolved symbol ? I can reproduce it by exchanging ld.so and libdl.so it is reasonable considering the code impacted by the offending patch while I keep looking more can you see anything visually in this patch would help I'll re-re-look again i tried with latest master and problem happens there too. yes, not changes have been applied to the symbol scope logic further. Thanks -Khem to you. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: static link with NPTL on ARM fails
On 16/12/2011 18.36, Johannes Stezenbach wrote: On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote: On 16/12/11 15:57, Johannes Stezenbach wrote: I was able to fix the issue like this: --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.0 +0100 +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.0 +0100 @@ -38,9 +38,9 @@ return __libc_sigaction (sig, act, oact); } -libc_hidden_proto(sigaction) +hidden_proto(sigaction) weak_alias (__sigaction, sigaction) -libc_hidden_weak(sigaction) +hidden_weak(sigaction) #else ... I think that the proper fix is to remove sigaction from libpthread,a instead. But they are not identical, libpthread/nptl/sysdeps/pthread/sigaction.c has this comment: /* We use the libc implementation but we tell it to not allow SIGCANCEL or SIGTIMER to be handled. */ you're right. I have now some free time to look at pending patches. It's on my queue. Carmelo Johannes ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] libubacktrace: use -funwind-tables rather than -fexecptions
On 04/01/2012 23.36, Mike Frysinger wrote: On Tuesday 03 January 2012 11:34:40 Carmelo AMOROSO wrote: On 01/01/2012 0.10, Mike Frysinger wrote: On Thursday 22 December 2011 13:19:22 Carmelo AMOROSO wrote: On 22/12/2011 15.30, Carmelo Amoroso wrote: For backtrace to work is enough to use -funwind-tables instead of -fexceptions. Indeed, I'm wondering if -fasynchrous-unwind-tables should be used rather then funwind-tables. On my arh SH4 the generated code is exactly the same. I'm not expert of DWARF, neither gcc documentation regarding the differences between -fexceptions, -funwind-tables or -fasynchronous-unwind-tables helped me so much. someone else has clearer idea ? for backtrace, we just want unwind-tables, so using that over -fexceptions is good (since we don't have to handle exceptions in this code). as for the async vs non-async unwind-tables, i don't know the answer to that. I've reported here below the extract from gcc manual. Reading it again, it seems to me that using -fasynchronous-unwind-tables is the best as it's purpose is actually to create the dwarf2 information, in the other two cases (-fexceptions or -funwind-tables) it seems to be a side effect. glibc seems to prefer -fasynchronous-unwind-tables, so that's probably good for us too we need -fexceptions if the funcs themselves need to handle exceptions. but if we only want other things to be able to build a backtrace across the call, then -fasynchronous-unwind-tables should be sufficient. -mike agreed. I'll commit an update shortly. carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: allow to backtrace out of abort call
On 03/01/2012 20.23, Bernhard Reutner-Fischer wrote: On Jan 3, 2012 7:11 PM, Carmelo AMOROSO carmelo.amor...@st.com wrote: Build raise and abort function with dwarf2 info by using -fasynchronous-unwind-tables to make backtrace() working across a call to abort. A scenario where it could be useful is within a signal handler that wants to dump a backtrace when catching some signal (i.e SIGABRT). Without having abort raise built with DWARF2 information, it is not possible for the libgcc stack unwinder to walk through the call stack out of the abort/raise function. Impacts in terms of size are really limited Please use busybox's incarnation of bloat-o-meter to report size changes in the future. sure Acked-by: Bernhard Reutner-Fischer rep.dot@gmail.com thanks. I'll commit shortly. cheers, Carmelo Current textdata bss dec hex filename 164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os 164 0 0 164 a4 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS 220 24 4 248 f8 ./libc/stdlib/abort.os With (-fasynchronous-unwind-tables) textdata bss dec hex filename 216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.os 216 0 0 216 d8 ./libpthread/nptl/sysdeps/unix/sysv/linux/raise.oS 280 24 4 308 134 ./libc/stdlib/abort.os Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- libc/signal/Makefile.in|2 ++ libc/stdlib/Makefile.in|2 ++ .../sysdeps/unix/sysv/linux/Makefile.commonarch|2 ++ 3 files changed, 6 insertions(+), 0 deletions(-) diff --git a/libc/signal/Makefile.in b/libc/signal/Makefile.in index a7e3078..ed8598b 100644 --- a/libc/signal/Makefile.in +++ b/libc/signal/Makefile.in @@ -24,6 +24,8 @@ ifneq ($(strip $(ARCH_OBJS)),) CSRC-y := $(filter-out $(notdir $(ARCH_OBJS:.o=.c)),$(CSRC-y)) endif +CFLAGS-raise.c = -fasynchronous-unwind-tables + SIGNAL_DIR := $(top_srcdir)libc/signal SIGNAL_OUT := $(top_builddir)libc/signal diff --git a/libc/stdlib/Makefile.in b/libc/stdlib/Makefile.in index 73e5462..9e96f03 100644 --- a/libc/stdlib/Makefile.in +++ b/libc/stdlib/Makefile.in @@ -27,6 +27,8 @@ CSRC-$(if $(findstring yy,$(UCLIBC_HAS_FLOATS)$(UCLIBC_SUSV3_LEGACY)),y) += \ gcvt.c CSRC-$(UCLIBC_SUSV3_LEGACY) += mktemp.c +CFLAGS-abort.c = -fasynchronous-unwind-tables + # multi source stdlib.c CSRC-y += abs.c labs.c atoi.c atol.c strtol.c strtoul.c _stdlib_strto_l.c \ qsort.c qsort_r.c bsearch.c \ diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch index e28cec2..b32bc9b 100644 --- a/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch +++ b/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch @@ -128,6 +128,8 @@ CFLAGS-timer_gettime.c = -I$(top_srcdir)librt -DIS_IN_librt CFLAGS-timer_routines.c = -I$(top_srcdir)librt -DIS_IN_librt CFLAGS-timer_settime.c = -I$(top_srcdir)librt -DIS_IN_librt +CFLAGS-raise.c = -fasynchronous-unwind-tables + CFLAGS-linux = -DNOT_IN_libc -DIS_IN_libpthread $(SSP_ALL_CFLAGS) CFLAGS-OMIT-libc_pthread_init.c = -DNOT_IN_libc -DIS_IN_libpthread -- 1.7.4.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] libc_arm: avoid multiple version of __aeabi_unwind_cpp_pr dummy code
Do not pollute libraries with its own implementation of __aeabi_unwind_cpp_pr1 code. Just add it to uclibc_nonshared.a archive and share it. This fixes build issue with static linking of application due to multiple symbol definition in libgcc_eh-a and libpthread.a or librt.a Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- libc/sysdeps/linux/arm/Makefile.arch |3 +-- libpthread/nptl/sysdeps/arm/Makefile.arch |1 - libpthread/nptl/sysdeps/arm/aeabi_unwind_cpp_pr1.c |1 - .../sysv/linux/arm/nptl-aeabi_unwind_cpp_pr1.c |1 - libubacktrace/Makefile.in |4 5 files changed, 1 insertions(+), 9 deletions(-) delete mode 100644 libpthread/nptl/sysdeps/arm/aeabi_unwind_cpp_pr1.c delete mode 100644 libpthread/nptl/sysdeps/unix/sysv/linux/arm/nptl-aeabi_unwind_cpp_pr1.c diff --git a/libc/sysdeps/linux/arm/Makefile.arch b/libc/sysdeps/linux/arm/Makefile.arch index 14279e0..ddd104d 100644 --- a/libc/sysdeps/linux/arm/Makefile.arch +++ b/libc/sysdeps/linux/arm/Makefile.arch @@ -46,6 +46,5 @@ ifeq ($(IS_EABI),y) libc-static-y += $(ARCH_OUT)/aeabi_lcsts.o $(ARCH_OUT)/aeabi_math.o \ $(ARCH_OUT)/aeabi_sighandlers.o libc-nonshared-y += $(ARCH_OUT)/aeabi_lcsts.os $(ARCH_OUT)/aeabi_math.os \ - $(ARCH_OUT)/aeabi_sighandlers.os -libc-shared-y += $(ARCH_OUT)/aeabi_unwind_cpp_pr1.os + $(ARCH_OUT)/aeabi_sighandlers.os $(ARCH_OUT)/aeabi_unwind_cpp_pr1.o endif diff --git a/libpthread/nptl/sysdeps/arm/Makefile.arch b/libpthread/nptl/sysdeps/arm/Makefile.arch index 284dba4..fbe4975 100644 --- a/libpthread/nptl/sysdeps/arm/Makefile.arch +++ b/libpthread/nptl/sysdeps/arm/Makefile.arch @@ -7,7 +7,6 @@ # librt_arch_SSRC = aeabi_read_tp.S thumb_atomics.S -librt_arch_CSRC = aeabi_unwind_cpp_pr1.c CFLAGS-pt-raise.c = -DNOT_IN_libc -DIS_IN_libpthread diff --git a/libpthread/nptl/sysdeps/arm/aeabi_unwind_cpp_pr1.c b/libpthread/nptl/sysdeps/arm/aeabi_unwind_cpp_pr1.c deleted file mode 100644 index 8468362..000 --- a/libpthread/nptl/sysdeps/arm/aeabi_unwind_cpp_pr1.c +++ /dev/null @@ -1 +0,0 @@ -#include ../../../../libc/sysdeps/linux/arm/aeabi_unwind_cpp_pr1.c diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/nptl-aeabi_unwind_cpp_pr1.c b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/nptl-aeabi_unwind_cpp_pr1.c deleted file mode 100644 index 7b83522..000 --- a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/nptl-aeabi_unwind_cpp_pr1.c +++ /dev/null @@ -1 +0,0 @@ -#include aeabi_unwind_cpp_pr1.c diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in index b18e3e6..3e2073b 100644 --- a/libubacktrace/Makefile.in +++ b/libubacktrace/Makefile.in @@ -12,10 +12,6 @@ CFLAGS-libubacktrace := -DNOT_IN_libc -DIS_IN_libubacktrace $(SSP_ALL_CFLAGS) LDFLAGS-libubacktrace.so := $(LDFLAGS) $(top_builddir)lib/libdl-$(VERSION).so -ifeq ($(UCLIBC_HAS_BACKTRACE)$(CONFIG_ARM_EABI),yy) -LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a) -endif - LIBS-libubacktrace.so := $(LIBS) libubacktrace_FULL_NAME := libubacktrace-$(VERSION).so -- 1.7.4.4 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: NPTL on ARM isseu with __aeabi_unwind_cpp_pr0
On 29/11/2011 17.05, Johannes Stezenbach wrote: Hi, static linking on ARM with NPTL causes duplicate symbol errors for __aeabi_unwind_cpp_pr0. I think it is both gcc and uClibc issue. See also https://bugs.busybox.net/show_bug.cgi?id=4117 gcc version 4.6.2 20111004 (prerelease) (linaro version) uClibc-0.9.32 or git master - gcc defines __aeabi_unwind_cpp_pr0/pr1/pr2 - uClibc-0.9.32/libc/sysdeps/linux/arm/aeabi_unwind_cpp_pr1.c defines stubs, the comment says This routine will never actually be called. I think the gcc versions of these functions must not be weak, but the uClibc stubs need to be weak, so that when linking statically the gcc versions will be used. However, gcc makes __aeabi_unwind_cpp_pr1/pr2 weak, with the weak attr on __aeabi_unwind_cpp_pr0 left in a comment: http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6/annotate/head:/gcc/config/arm/unwind-arm.c#L223 Confusing, isn't it? Johannes I've posted a patch... it works for me. Comments ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: NPTL on ARM isseu with __aeabi_unwind_cpp_pr0
On 05/01/12 14:42, Johannes Stezenbach wrote: On Mon, Dec 12, 2011 at 12:13:49PM +0100, Johannes Stezenbach wrote: On Thu, Dec 01, 2011 at 08:58:24AM +0100, Carmelo AMOROSO wrote: On 01/12/2011 6.29, Khem Raj wrote: On (29/11/11 17:05), Johannes Stezenbach wrote: static linking on ARM with NPTL causes duplicate symbol errors for __aeabi_unwind_cpp_pr0. I think it is both gcc and uClibc issue. hmm this object is added to libc-shared-y so I think it should not be part of static libc however I see that it does not make that distinction for librt or libpthread so if you link with librt.a then this object will get in way probably it should not exist in static versions of these libs as well. I' think to have a clean fix for this. Let me send the patch so you can look at it. Do you have the patch ready for testing? I have some time to test it this week. Just a reminder that this issue is still open. If you have a patch, please send it. Thanks Johannes it's on my todo list, but I'm a bit busy in thee days. not needed to remind it again. thanks for your patience. carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
