[PATCH 1/1] stdio: fix named pipe issue
This is follow-up of my investigation and proposed
fix at
http://old.nabble.com/named-pipe-is-borken-and-proposed-fix-td31753483.html#a31753483
The testing programs worked well with glibc, but failed in uClibc-0.9.32.
As Laurent pointed out, this is undefined in standard. For the sake of
application developers who want to port apps from glibc to uClibc without
worrying about the subtle difference, it is nice to help them out with
following patch.
The problem is that FIFO is a special file type, and the conventional EOF
is useless, and should not be set.
The fix is to avoid setting __FLAG_EOF for stream associated with FIFO file
after all senders were closed.
Signed-off-by: Jian Peng jipeng2...@gmail.com
---
libc/stdio/_READ.c| 29 -
libc/sysdeps/linux/common/bits/uClibc_stdio.h |1 +
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/libc/stdio/_READ.c b/libc/stdio/_READ.c
index 02601c0..2ecc920 100644
--- a/libc/stdio/_READ.c
+++ b/libc/stdio/_READ.c
@@ -6,7 +6,25 @@
*/
#include _stdio.h
+#include sys/syscall.h
+#include unistd.h
+#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 _my_fstat(int fd, struct stat *buf)
+{
+ int result;
+ struct kernel_stat kbuf;
+
+ result = __syscall_fstat(fd, kbuf);
+ if (result == 0) {
+ __xstat_conv(kbuf, buf);
+ }
+ return result;
+}
/* Given a reading stream without its end-of-file indicator set and
* with no buffered input or ungots, read at most 'bufsize' bytes
@@ -44,7 +62,16 @@ size_t attribute_hidden __stdio_READ(register FILE *stream,
/* RETRY: */
if ((rv = __READ(stream, (char *) buf, bufsize)) = 0) {
if (rv == 0) {
- __STDIO_STREAM_SET_EOF(stream);
+ struct stat stat;
+
+ if( (stream-__modeflags __FLAG_FIFOFILE) ||
+ _my_fstat(stream-__filedes, stat) =
0) {
+ if(S_ISFIFO(stat.st_mode))
+ stream-__modeflags |=
__FLAG_FIFOFILE;
+ }
+
+ if(!(stream-__modeflags __FLAG_FIFOFILE))
+ __STDIO_STREAM_SET_EOF(stream);
} else {
/* if (errno == EINTR) goto RETRY; */
__STDIO_STREAM_SET_ERROR(stream);
diff --git a/libc/sysdeps/linux/common/bits/uClibc_stdio.h
b/libc/sysdeps/linux/common/bits/uClibc_stdio.h
index a8cf4eb..1d2cc11 100644
--- a/libc/sysdeps/linux/common/bits/uClibc_stdio.h
+++ b/libc/sysdeps/linux/common/bits/uClibc_stdio.h
@@ -331,6 +331,7 @@ struct __STDIO_FILE_STRUCT {
#define __FLAG_FREEBUF 0x4000U
#define __FLAG_LARGEFILE 0x8000U /* fixed! == 0_LARGEFILE for linux */
#define __FLAG_FAILED_FREOPEN __FLAG_LARGEFILE
+#define __FLAG_FIFOFILE0x1000U /* handle FIFO differently */
/* Note: In no-buffer mode, it would be possible to pack the necessary
* flags into one byte. Since we wouldn't be buffering and there would
--
1.7.4.1
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH 1/1] stdio: fix named pipe issue
Unfortunately, glibc is the most widely used C library and de facto testing environment used by most application developers. I am not familiar with C standard, but every standard had evolved to meet the requirement of its end users, so to this point, glibc implemented in the way that satisfied its end users. In case that uClibc was used as a replacement of glibc, this kind of subtle discrepancy just hinder this migration. -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rich Felker Sent: Thursday, June 16, 2011 3:39 PM To: uclibc@uclibc.org Subject: Re: [PATCH 1/1] stdio: fix named pipe issue On Thu, Jun 16, 2011 at 11:54:45AM -0700, Jian Peng wrote: This is follow-up of my investigation and proposed fix at http://old.nabble.com/named-pipe-is-borken-and-proposed-fix-td31753483.html#a31753483 The testing programs worked well with glibc, but failed in uClibc-0.9.32. As Laurent pointed out, this is undefined in standard. For the sake of application developers who want to port apps from glibc to uClibc without worrying about the subtle difference, it is nice to help them out with following patch. The problem is that FIFO is a special file type, and the conventional EOF is useless, and should not be set. The fix is to avoid setting __FLAG_EOF for stream associated with FIFO file after all senders were closed. This patch adds bloat and as far as I can tell it's wrong. The standard (C) says that the EOF indicator is set when EOF is reached, that it is not cleared until you call clearerr or fseek/rewind, and that fgetc returns EOF if the EOF indicator is set. If glibc does not behave this way for fifos, that's a glibc bug. 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: [PATCH 1/1] stdio: fix named pipe issue
Fully agree. -Original Message- From: Yann E. MORIN [mailto:yann.morin.1...@anciens.enib.fr] Sent: Thursday, June 16, 2011 4:18 PM To: uclibc@uclibc.org Cc: Jian Peng; Rich Felker Subject: Re: [PATCH 1/1] stdio: fix named pipe issue Jian, Rich, All, On Friday 17 June 2011 01:04:44 Jian Peng wrote: Unfortunately, glibc is the most widely used C library and de facto testing environment used by most application developers. I am not familiar with C standard, but every standard had evolved to meet the requirement of its end users, so to this point, glibc implemented in the way that satisfied its end users. In case that uClibc was used as a replacement of glibc, this kind of subtle discrepancy just hinder this migration. I would suggest that this be /protected/ by a config option, that the user can set in the menuconfig. I am not saying that the patch is correct or wrong, nor am I saying that it should be applied or dumped. I'm only suggesting that this compatibility stuff might have more chance to get in if it is protected by a config option. We already have a few compatibility knobs, so either we add that new compatibility stuff to an existing knob, or we add a new one. I for one believe standards have a role to play, so we should stick to them as much as possible; OTOH, usability is a must, and if people expect a certain behavior that diverges from the standard because it is been done as such in the most widely deployed systems, then offering those users that care the option to enable that compatibility stuff is good, but we should also cover the case for those users that want to abide by the standards. My 2 eurocents. ;-) Regards, Yann E. MORIN. -- .-..--.. | 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
RE: [PATCH 1/1] stdio: fix named pipe issue
I really like to see this kind of glibc to uClibc migration guide that has enough detail to cover similar problems. If I saw it before, I will not spend my time on this problem by then. Very unfortunately, this documents did not exist, at least not searchable. This seems a really big missing piece in www.uclibc.org -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rich Felker Sent: Thursday, June 16, 2011 4:11 PM To: uclibc@uclibc.org Subject: Re: [PATCH 1/1] stdio: fix named pipe issue On Thu, Jun 16, 2011 at 04:04:44PM -0700, Jian Peng wrote: Unfortunately, glibc is the most widely used C library and de facto testing environment used by most application developers. I am not familiar with C standard, but every standard had evolved to meet the requirement of its end users, so to this point, glibc implemented in the way that satisfied its end users. In case that uClibc was used as a replacement of glibc, this kind of subtle discrepancy just hinder this migration. Certainly these broken apps will also fail on other OS's, perhaps BSD's or commercial unices. Wouldn't it be better to just fix them? It's probably a one-line patch, adding clearerr() after the EOF is encountered. By the way, I don't think glibc special-cases fifos like this. Rather, it merely ignores the rule that read functions are supposed to fail if the EOF flag for the stream is set, and thus retries reading. For normal files this gives the same results as the standard requires, but for fifos and such, it can be different. I believe this behavior difference is documented somewhere in the various writings about the differences between glibc and uClibc (and glibc intentional/WONTFIX bugs), so somebody will probably be unhappy if you go breaking uClibc like this - especially if you do it the bloated expensive way rather than just having read functions ignore the EOF flag. 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: named pipe is borken and proposed fix
Hi, Laurent, I tried your suggestion in pipetest-server.c The generally accepted, portable way to handle sequential reads on a FIFO is for the reader to also open the writing end of the FIFO (and do nothing with it) for as long as it wants to read. It did not work. I am not sure whether it is possible to open same FIFO, and use one as reader, and use second as writer, in same user process. Do you have sample codes to demo your suggestion? Thanks, Jian -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Laurent Bercot Sent: Wednesday, June 01, 2011 11:00 PM To: uclibc@uclibc.org Subject: Re: named pipe is borken and proposed fix The problem is that FIFO is a special file type, and the conventional EOF is useless, and should not be set. My proposed fix is to avoid setting __FLAG_EOF for stream associated with FIFO after sender was closed. Good findings, and good call. It's worth noting that the Linux kernel exhibits the same behaviour with FIFOs: - EOF will be sent when the last writer closes - subsequent read()s by the same reader will always return EOF - that includes select() and poll(): after the last writer closes, select() and poll() will always return readability/EOF on the reading end of a FIFO, until the reader closes and opens it again. Some other operating systems behave the same way; others don't. The standard does not specify what is right; it allows a lot of implementation-defined behaviour with FIFOs. The generally accepted, portable way to handle sequential reads on a FIFO is for the reader to also open the writing end of the FIFO (and do nothing with it) for as long as it wants to read. The reader is then certain to never get EOF, which only happens when the last writer closes. FIFOs are tricky beasts. They should be used with extreme caution by programmers; leaving low-level FIFO handling to stdio is a good way to shoot yourself in the foot. Which does not mean that stdio should not try to do the right thing, of course. I just have no idea what the right thing is, because different situations call for different answers, and some cases will require EOF while others won't. I suspect that glibc does unholy magic inside stdio for your test case to work with glibc despite the Linux behaviour. And unfortunately, I'm not sure it's avoidable. -- Laurent ___ 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: named pipe is borken and proposed fix
This is the nice trick. It works! Thank you so much. Jian -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rich Felker Sent: Thursday, June 02, 2011 4:44 PM To: uclibc@uclibc.org Subject: Re: named pipe is borken and proposed fix On Thu, Jun 02, 2011 at 02:00:41PM -0700, Jian Peng wrote: The generally accepted, portable way to handle sequential reads on a FIFO is for the reader to also open the writing end of the FIFO (and do nothing with it) for as long as it wants to read. It did not work. I am not sure whether it is possible to open same FIFO, and use one as reader, and use second as writer, in same user process. Of course it can. The easiest way to do this is open the FIFO with the O_RDWR flag. Then you will never get EOF. 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
named pipe is borken and proposed fix
Testing procedure
=
Using following named pipe testing program, the testing process is as follow
In console A, run pipetest-server
$ ./pipetest-server
pipetest-server got req (req from CL-A)
pipetest-server got req (req from CL-B)
In console B, run pipetest-client
$ ./pipetest-client CL-A 2000
pipetest-client: CL-A: got rsp ack rsp
waiting for 2000 microseconds...
ending...
$ ./pipetest-client CL-B 2000
pipetest-client: CL-B: got rsp ack rsp
waiting for 2000 microseconds...
ending...
The above is the expected result.
But in uClibc, after ./pipetest-client CL-B 2000, It hung, and there is
no pipetest-server got req (req from CL-B) on pipetest-server.
This works on x86_64 host using glibc, and also works on MIPS using
glibc-1.8.2, but it failed on MIPS using uClibc-0.9.32-rc3.
Testing programs pipetest-server.c
==
Here is testing program pipetest-server.c
#include stdlib.h
#include stdio.h
#include signal.h
#include unistd.h
#include sys/stat.h
#include sys/select.h
#define REQNAME /tmp/pipetest_req
#define RSPNAME /tmp/pipetest_rsp
int main( int argc, char **argv)
{
int rc = 0;
FILE *pReq= 0;
FILE *pRsp= 0;
char buff[128];
// Remove any existing file
remove( REQNAME );
remove( RSPNAME );
rc= mknod( REQNAME, S_IFIFO|0666, 0);
if ( rc ) goto exit;
rc= mknod( RSPNAME, S_IFIFO|0666, 0);
if ( rc ) goto exit;
pReq= fopen( REQNAME, r );
if ( pReq )
{
fd_set rfds;
int fd= fileno( pReq );
pRsp= fopen( RSPNAME, w );
for( ; ; )
{
FD_ZERO(rfds);
FD_SET(fd, rfds);
rc= select( fd+1, rfds, 0, 0, 0);
// Read next request
if ( fgets( buff, sizeof(buff), pReq ) != NULL )
{
printf( pipetest-server got req (%s)\n, buff );
fprintf( pRsp, ack rsp\n );
fflush( pRsp );
}
}
}
exit:
return rc;
}
Testing programs pipetest-client.c
==
Here is testing program pipetest-client.c
#include stdlib.h
#include stdio.h
#include signal.h
#include unistd.h
#define REQNAME /tmp/pipetest_req
#define RSPNAME /tmp/pipetest_rsp
int readIPCResponse( FILE *file, char *buff, int buffSize )
{
int retryCount= 0;
while( retryCount 10 )
{
if ( fgets( buff, buffSize, file ) != NULL )
{
return 1;
}
usleep( 5000 );
++retryCount;
}
return 0;
}
int main( int argc, char **argv)
{
int rc = 0;
FILE *pReq= 0;
FILE *pRsp= 0;
int timeout= 1000;
char *arg= 0;
char buff[128];
arg = ( argc 2 ) ? ClientA : argv[1];
timeout= ( argc 3 ) ? 1000 : atoi(argv[2]);
pReq= fopen( REQNAME, w );
if ( pReq )
{
pRsp= fopen( RSPNAME, r );
if ( pRsp )
{
fprintf( pReq, req from %s\n, arg );
fflush( pReq );
rc= readIPCResponse( pRsp, buff, sizeof(buff) );
if ( rc )
{
printf( pipetest-client: %s: got rsp %s\n, arg, buff );
}
printf( waiting for %d microseconds...\n, timeout );
usleep( timeout );
printf( ending...\n );
fclose( pRsp );
}
fclose( pReq );
}
return rc;
}
Debugging result
=
My debugging showed that in pipetest-server.c, after ./pipetest-client CL-A
2000 finished, fgets() return NULL forever.
The problem is that after ./pipetest-client CL-A 2000 finished, in stream
associated with FIFO /tmp/pipetest_req, fgets() will call __stdio_READ()
internally
24 size_t attribute_hidden __stdio_READ(register FILE *stream,
25 unsigned char *buf, size_t bufsize)
26 {
27 ssize_t rv = 0;
28
36 if (!__FEOF_UNLOCKED(stream)) {
37 if (bufsize SSIZE_MAX) {
38 bufsize = SSIZE_MAX;
39 }
40
41 #ifdef __UCLIBC_MJN3_ONLY__
42 #warning EINTR?
43 #endif
44 /* RETRY: */
45 if ((rv = __READ(stream, (char *) buf, bufsize)) = 0) {
46 if (rv == 0) {
47 __STDIO_STREAM_SET_EOF(stream);
At line 45, rv return 0, then at line 47, it set __FLAG_EOF in
stream-__modeflags.
After ./pipetest-client CL-B 2000 was started, it writed req from CL-B
to FIFO /tmp/pipetest_req,
but since __FLAG_EOF was set in stream-__modeflags in above stream, it failed
at line 36, and no longer call __READ() at line 45 to read new message from
FIFO.
The problem is that FIFO is a special file type, and the conventional EOF is
useless, and should not be set.
My proposed fix is to avoid setting __FLAG_EOF for stream associated with FIFO
after sender was closed.
My patch
This is my patch to fix it. Sorry that git server of uClibc.org is
RE: [ANNOUNCE] 0.9.32-rc3 released
This is obviously a safe option to fix this sort of static linking issues, and build time should never be a big issue. Can we go for it and merge into 0.9.32 release using this approach? And leave other more elegant solution in the future branch. It is better to have a solution, even if it is tentative, than leave it broken for 0.9.32 release, right? -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Peter Mazinger Sent: Tuesday, May 10, 2011 2:35 PM To: uclibc@uclibc.org Subject: Re: [ANNOUNCE] 0.9.32-rc3 released Original-Nachricht Datum: Tue, 10 May 2011 20:31:12 +0100 Von: Will Newton will.new...@gmail.com An: Bernhard Reutner-Fischer rep.dot@gmail.com CC: uclibc@uclibc.org Betreff: Re: [ANNOUNCE] 0.9.32-rc3 released On Tue, May 10, 2011 at 8:21 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 07:57:12PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 7:44 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On Tue, May 10, 2011 at 05:49:02PM +0100, Will Newton wrote: On Tue, May 10, 2011 at 5:38 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Hi, We are shaking out some bugs still, but it will be released RSN (TM). Are there any plans to fix this bug? https://bugs.uclibc.org/2089 This is supposed to work just fine with NPTL. So is support for linuxthreads dropped with this release? It seems a shame when people are willing to support it. Thing is that you can only workaround it unless you have TLS. For arches that already have NPTL i suggest you use it. If folks find it clearer we can reflect that recommendation in the configury. The patch in the bug from Peter works and I have yet to see a clear statement of what is wrong with it. Without the patch linuxthreads is pretty much unusable. generally speaking of this sort of failures: - it would be better, if we would disable *hidden_proto/def/attribute_hidden for static builds (but that would mean double time for the build) Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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: sigprocmask testing program failed with static linking
Thank you, Austin. Since I am not familiar with internal design of libc and libpthread, I am afraid of messing it up by reimplementing those pieces. Looking forward to testing your patch. Jian On Apr 21, 2011, at 6:23 PM, Austin Foxley aust...@cetoncorp.com wrote: On 03/27/2011 12:27 AM, Jian Peng wrote: This is one of many potential static linking problems in uClibc. Last time, I reported a bug on sigaction and submitted a patch, but similar multiple definition error could happen to any function that was defined as GLOBAL in both libc.a and libpthread.a while certain runtime supporting function from libc, like abort(), also call it. For example, sigprocmask-test.c is a simple testing program and $ gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread Since sigprocmask is GLOBAL in both libc.a and libpthread.a, sigprocmask called in main function will pull in pt-sigprocmask.os from libpthread.a, but later, another sigprocmask called in abort (part of libc) will pull in sigprocmask.os from libc.a and leads to multiple definition error. To fix it, sigprocmask has to be defined as weak symbol. The same solution could be applied to other functions in libc/sysdeps/linux/common that will be called in both main and runtime supporting function in libc. I will identify them and post patch later. Here is my patch to fix sigprocmask, and it was tested on gcc-4.5.2 based toolchain on MIPS. I've also ran into this problem recently but I fixed it by simply removing the libpthread version entirely and forcing the calls to go through libc. The calls I had trouble with were sigaction, sigprocmask, and sigfillset. I think this is what Peter meant was his preferred solution in the reply to your earlier email? Peter can you comment? I can put together a patch of what I've been using and push it to future if that is what you meant. -Austin ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: sigprocmask testing program failed with static linking
Hi, Mike,
Do you have time to review this patch? Any suggestion? Or it is ready to be
pushed?
Thanks,
Jian
-Original Message-
From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of
Jian Peng
Sent: Monday, March 28, 2011 3:09 PM
To: Mike Frysinger; uclibc@uclibc.org
Subject: RE: sigprocmask testing program failed with static linking
I chose Plain Text mode in Outlook, but not sure why line wrap failed.
Here is my new patch using weak_function.
From 4ebcbb392994e5a8a310d59ca5541fe97c4babdd Mon Sep 17 00:00:00 2001
From: Jian Peng jipeng2...@gmail.com
Date: Mon, 28 Mar 2011 15:00:23 -0700
Subject: [PATCH 1/1] common: fix sigprocmask static linking bug
simple sigprocmask testing program will fail to be compiled due to
multiple definition of sigprocmask in libpthread.a and libc.a
$ gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread
sigprocmask.c:(.text+0x0): multiple definition of `sigprocmask'
The solution is to define sigprocmask as weak symbol.
Signed-off-by: Jian Peng jipeng2...@gmail.com
---
libc/sysdeps/linux/common/sigprocmask.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libc/sysdeps/linux/common/sigprocmask.c
b/libc/sysdeps/linux/common/sigprocmask.c
index 011d7b3..1d0d51a 100644
--- a/libc/sysdeps/linux/common/sigprocmask.c
+++ b/libc/sysdeps/linux/common/sigprocmask.c
@@ -23,7 +23,7 @@ static __always_inline
_syscall4(int, __rt_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset, size_t, size)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int weak_function sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
@@ -58,7 +58,7 @@ static __always_inline
_syscall3(int, __syscall_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int weak_function sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
--
1.7.4.1
-Original Message-
From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of
Mike Frysinger
Sent: Sunday, March 27, 2011 1:01 AM
To: uclibc@uclibc.org
Subject: Re: sigprocmask testing program failed with static linking
On Sun, Mar 27, 2011 at 3:27 AM, Jian Peng wrote:
please fix your e-mail client to properly wrap long lines.
From 2e435b037624eff8c0daaa146d6feca57ce1eecf Mon Sep 17 00:00:00 2001
From: Jian Peng jipeng2...@gmail.com
Date: Sat, 26 Mar 2011 23:44:52 -0700
Subject: [PATCH 1/1] common: fix sigprocmask static linking bug
simple sigprocmask testing program will fail to be compiled due to multiple
definition of sigprocmask in libpthread.a and libc.a
you need to manually line wrap your changelog to like 74 chars
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int __attribute__((weak)) sigprocmask(int how, const sigset_t * set,
sigset_t * oldset)
you need to use weak_function. raw __attribute__((...)) is rarely the
way to go anymore.
-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
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH 1/1] [PATCH v1] need fallback to libm-test-ulps-generic
Under test/math/, there is libm-test-ulps-generic used as fallback in case that libm-test-ulps-$(TARGET_ARCH) does not exist. The fallback logic is missing in test/math/Makefile.in. Signed-off-by: Jian Peng jipeng2...@gmail.com --- test/math/Makefile.in |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/test/math/Makefile.in b/test/math/Makefile.in index e76cbdb..4ab1d93 100644 --- a/test/math/Makefile.in +++ b/test/math/Makefile.in @@ -23,9 +23,11 @@ EXTRA_LDFLAGS := -lm PERL := /usr/bin/perl +MATH_TARGET := $(if $(wildcard libm-test-ulps-$(TARGET_ARCH)),$(TARGET_ARCH),generic) + $(TESTS): libm-test.c -libm-test.c: libm-test-ulps-$(TARGET_ARCH) libm-test.inc gen-libm-test.pl - $(Q)$(PERL) ./gen-libm-test.pl -u libm-test-ulps-$(TARGET_ARCH) ./libm-test.inc -o . 21 /dev/null +libm-test.c: libm-test-ulps-$(MATH_TARGET) libm-test.inc gen-libm-test.pl +$(Q)$(PERL) ./gen-libm-test.pl -u libm-test-ulps-$(MATH_TARGET) ./libm-test. inc -o . 21 /dev/null EXTRA_CLEAN := libm-test.c libm-test-ulps.h -- 1.7.4.1 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH 1/1] [PATCH v1] math-test: missing libm-test-ulps-mips
Under test/math, libm-test-ulps-mips is missing or build for MIPS is broken Simply copy it from glibc-ports-2.9/sysdeps/mips/fpu/libm-test-ulps to fix this. Signed-off-by: Jian Peng jipeng2...@gmail.com --- test/math/libm-test-ulps-mips | 890 + 1 files changed, 890 insertions(+), 0 deletions(-) create mode 100644 test/math/libm-test-ulps-mips diff --git a/test/math/libm-test-ulps-mips b/test/math/libm-test-ulps-mips new file mode 100644 index 000..b514496 --- /dev/null +++ b/test/math/libm-test-ulps-mips @@ -0,0 +1,890 @@ +# Begin of automatic generation + +# atan2 +Test atan2 (-0.75, -1.0) == -2.49809154479650885165983415456218025: +float: 3 +ifloat: 3 +Test atan2 (0.75, -1.0) == 2.49809154479650885165983415456218025: +float: 3 +ifloat: 3 +Test atan2 (1.390625, 0.9296875) == 0.981498387184244311516296577615519772: +float: 1 +ifloat: 1 + +# atanh +Test atanh (0.75) == 0.972955074527656652552676371721589865: +float: 1 +ifloat: 1 + +# cacosh +Test Real part of: cacosh (-2 - 3 i) == 1.9833870299165354323470769028940395 - 2.141449159960199416055713254211 i: +double: 1 +float: 7 +idouble: 1 +ifloat: 7 +Test Imaginary part of: cacosh (-2 - 3 i) == 1.9833870299165354323470769028940395 - 2.141449159960199416055713254211 i: +double: 1 +float: 3 +idouble: 1 +ifloat: 3 + +# casin +Test Real part of: casin (0.75 + 1.25 i) == 0.453276177638793913448921196101971749 + 1.13239363160530819522266333696834467 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# casinh +Test Real part of: casinh (-2 - 3 i) == -1.9686379257930962917886650952454982 - 0.96465850440760279204541105949953237 i: +double: 5 +float: 1 +idouble: 5 +ifloat: 1 +Test Imaginary part of: casinh (-2 - 3 i) == -1.9686379257930962917886650952454982 - 0.96465850440760279204541105949953237 i: +double: 3 +float: 6 +idouble: 3 +ifloat: 6 +Test Real part of: casinh (0.75 + 1.25 i) == 1.03171853444778027336364058631006594 + 0.911738290968487636358489564316731207 i: +float: 1 +ifloat: 1 +Test Imaginary part of: casinh (0.75 + 1.25 i) == 1.03171853444778027336364058631006594 + 0.911738290968487636358489564316731207 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# catan +Test Real part of: catan (-2 - 3 i) == -1.4099210495965755225306193844604208 - 0.22907268296853876629588180294200276 i: +float: 3 +ifloat: 3 +Test Imaginary part of: catan (-2 - 3 i) == -1.4099210495965755225306193844604208 - 0.22907268296853876629588180294200276 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Real part of: catan (0.75 + 1.25 i) == 1.10714871779409050301706546017853704 + 0.549306144334054845697622618461262852 i: +float: 4 +ifloat: 4 + +# catanh +Test Real part of: catanh (-2 - 3 i) == -0.1469422552975204743278515471595 - 1.3389725222944935611241935759091443 i: +double: 4 +idouble: 4 +Test Imaginary part of: catanh (-2 - 3 i) == -0.1469422552975204743278515471595 - 1.3389725222944935611241935759091443 i: +float: 4 +ifloat: 4 +Test Real part of: catanh (0.75 + 1.25 i) == 0.261492138795671927078652057366532140 + 0.996825126463918666098902241310446708 i: +double: 1 +idouble: 1 +Test Imaginary part of: catanh (0.75 + 1.25 i) == 0.261492138795671927078652057366532140 + 0.996825126463918666098902241310446708 i: +float: 6 +ifloat: 6 + +# cbrt +Test cbrt (-27.0) == -3.0: +double: 1 +idouble: 1 +Test cbrt (0.75) == 0.908560296416069829445605878163630251: +double: 1 +idouble: 1 +Test cbrt (0.9921875) == 0.997389022060725270579075195353955217: +double: 1 +idouble: 1 + +# ccos +Test Imaginary part of: ccos (-2 - 3 i) == -4.18962569096880723013255501961597373 - 9.10922789375533659797919726277886212 i: +float: 1 +ifloat: 1 +Test Real part of: ccos (0.75 + 1.25 i) == 1.38173873063425888530729933139078645 - 1.09193013555397466170919531722024128 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Imaginary part of: ccos (0.75 + 1.25 i) == 1.38173873063425888530729933139078645 - 1.09193013555397466170919531722024128 i: +float: 1 +ifloat: 1 + +# ccosh +Test Real part of: ccosh (-2 - 3 i) == -3.72454550491532256547397070325597253 + 0.511822569987384608834463849801875634 i: +float: 1 +ifloat: 1 +Test Imaginary part of: ccosh (-2 - 3 i) == -3.72454550491532256547397070325597253 + 0.511822569987384608834463849801875634 i: +float: 1 +ifloat: 1 +Test Real part of: ccosh (0.75 + 1.25 i) == 0.408242591877968807788852146397499084 + 0.780365930845853240391326216300863152 i: +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test Imaginary part of: ccosh (0.75 + 1.25 i) == 0.408242591877968807788852146397499084 + 0.780365930845853240391326216300863152 i: +float: 1 +ifloat: 1 + +# cexp +Test Imaginary part of: cexp (-2.0 - 3.0 i) == -0.13398091492954261346140525546115575 - 0.019098516261135196432576240858800925 i: +float: 1 +ifloat: 1 +Test Real part of: cexp (0.75 + 1.25 i) == 0.667537446429131586942201977015932112 + 2.00900045494094876258347228145863909 i: +float: 1 +ifloat: 1 + +# clog +Test Imaginary
[PATCH 1/1] [PATCH resend] need fallback to libm-test-ulps-generic
Under test/math/, there is libm-test-ulps-generic used as fallback in case that libm-test-ulps-$(TARGET_ARCH) does not exist. The fallback logic is missing in test/math/Makefile.in. Signed-off-by: Jian Peng jipeng2...@gmail.com --- test/math/Makefile.in |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/test/math/Makefile.in b/test/math/Makefile.in index e76cbdb..4ab1d93 100644 --- a/test/math/Makefile.in +++ b/test/math/Makefile.in @@ -23,9 +23,11 @@ EXTRA_LDFLAGS := -lm PERL := /usr/bin/perl +MATH_TARGET := $(if $(wildcard libm-test-ulps-$(TARGET_ARCH)),$(TARGET_ARCH),generic) + $(TESTS): libm-test.c -libm-test.c: libm-test-ulps-$(TARGET_ARCH) libm-test.inc gen-libm-test.pl - $(Q)$(PERL) ./gen-libm-test.pl -u libm-test-ulps-$(TARGET_ARCH) ./libm-test.inc -o . 21 /dev/null +libm-test.c: libm-test-ulps-$(MATH_TARGET) libm-test.inc gen-libm-test.pl +$(Q)$(PERL) ./gen-libm-test.pl -u libm-test-ulps-$(MATH_TARGET) ./libm-test.inc -o . 21 /dev/null EXTRA_CLEAN := libm-test.c libm-test-ulps.h -- 1.7.4.1 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: patch to fix build issue in uClibc testsuite
Thank you, Bernhard. I came across a discussion on similar issue at http://www.mail-archive.com/uclibc@uclibc.org/msg04245.html I like to understand what is the purpose of $(KERNEL_HEADERS). In my case, KERNEL_HEADERS was used to point to what my own kernel header files (may be slightly different from installed one for debugging purpose). Those kernel header files were used to build my own lib*.so based on different .config in uClibc (from that was used to build cross toolchain), and install my customized *.so onto target. I have to use $(KERNEL_HEAERS) to point to both linux/include and linux/arch/mips/include since linux/arch/mips/include has unistd.h that will be used to generate syscall table in uClibc. In other words, if KERNEL_HEADERS has to be set to point to installed kernel headers, then there is no need for this option, and there is no need to generate install_dir since you can simply create a symlink to sysroot directory as install_dir. How do you think? Jian From: Bernhard Reutner-Fischer [mailto:rep.dot@gmail.com] Sent: Saturday, April 09, 2011 1:43 PM To: Jian Peng; uclibc@uclibc.org Subject: Re: patch to fix build issue in uClibc testsuite Jian Peng jip...@broadcom.com wrote: In test/Rules.mak, $(KERNEL_HEADERS) will be checked and used to generate $(KERNEL_INCLUDES) based on absolute or relative path. The problem is that this check assumes that $(KERNEL_HEADERS) is single word like /user/me/kernel/include, in case that it is /user/me/kernel/include -I/user/me/kernel/arch/mips/include, $(KERNEL_INCLUDES) will be wrong and leads to unable to find out kernel header files in build process. Here I reworked the logic to check each path in $(KERNEL_HEADERS) individually, then combine them. Signed-off-by: Jian Peng jipeng2...@gmail.com --- test/Rules.mak | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/test/Rules.mak b/test/Rules.mak index 2131a7b..e144b0f 100644 --- a/test/Rules.mak +++ b/test/Rules.mak @@ -46,14 +46,10 @@ export TARGET_ARCH RM_R = $(Q)$(RM) -r LN_S = $(Q)$(LN) -fs +# handle absolute and relative path on each path in $(KERNEL_HEADERS) separately ifneq ($(KERNEL_HEADERS),) -ifeq ($(patsubst /%,/,$(KERNEL_ HEADERS)),/) -# Absolute path in KERNEL_HEADERS -KERNEL_INCLUDES += -I$(KERNEL_HEADERS) -else -# Relative path in KERNEL_HEADERS -KERNEL_INCLUDES += -I$(top_builddir)$(KERNEL_HEADERS) -endif +KERNEL_HEADERS := $(patsubst -I%,%,$(KERNEL_HEADERS)) +KERNEL_INCLUDES += $(addprefix -I,$(foreach i,$(KERNEL_HEADERS),$(patsubst .%,$(top_builddir).%,$i))) endif XCOMMON_CFLAGS := -I$(top_builddir)test -D_GNU_SOURCE -- 1.7.4.1 uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Hi, You need to use installed kernel headers. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
patch to fix build issue in uClibc testsuite
In test/Rules.mak, $(KERNEL_HEADERS) will be checked and used to generate $(KERNEL_INCLUDES) based on absolute or relative path. The problem is that this check assumes that $(KERNEL_HEADERS) is single word like /user/me/kernel/include, in case that it is /user/me/kernel/include -I/user/me/kernel/arch/mips/include, $(KERNEL_INCLUDES) will be wrong and leads to unable to find out kernel header files in build process. Here I reworked the logic to check each path in $(KERNEL_HEADERS) individually, then combine them. Signed-off-by: Jian Peng jipeng2...@gmail.com --- test/Rules.mak | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/test/Rules.mak b/test/Rules.mak index 2131a7b..e144b0f 100644 --- a/test/Rules.mak +++ b/test/Rules.mak @@ -46,14 +46,10 @@ export TARGET_ARCH RM_R = $(Q)$(RM) -r LN_S = $(Q)$(LN) -fs +# handle absolute and relative path on each path in $(KERNEL_HEADERS) separately ifneq ($(KERNEL_HEADERS),) -ifeq ($(patsubst /%,/,$(KERNEL_HEADERS)),/) -# Absolute path in KERNEL_HEADERS -KERNEL_INCLUDES += -I$(KERNEL_HEADERS) -else -# Relative path in KERNEL_HEADERS -KERNEL_INCLUDES += -I$(top_builddir)$(KERNEL_HEADERS) -endif +KERNEL_HEADERS := $(patsubst -I%,%,$(KERNEL_HEADERS)) +KERNEL_INCLUDES += $(addprefix -I,$(foreach i,$(KERNEL_HEADERS),$(patsubst .%,$(top_builddir).%,$i))) endif XCOMMON_CFLAGS := -I$(top_builddir)test -D_GNU_SOURCE -- 1.7.4.1 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
missing libm-test-ulps-mips under test/math/
Under test/math, libm-test-ulps-mips is missing or build for MIPS is broken Simply copy it from glibc-ports-2.9/sysdeps/mips/fpu/libm-test-ulps to fix this. The patch is attached. 0001-PATCH-v1-math-test-missing-libm-test-ulps-mips.patch Description: 0001-PATCH-v1-math-test-missing-libm-test-ulps-mips.patch ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: sigprocmask testing program failed with static linking
I chose Plain Text mode in Outlook, but not sure why line wrap failed.
Here is my new patch using weak_function.
From 4ebcbb392994e5a8a310d59ca5541fe97c4babdd Mon Sep 17 00:00:00 2001
From: Jian Peng jipeng2...@gmail.com
Date: Mon, 28 Mar 2011 15:00:23 -0700
Subject: [PATCH 1/1] common: fix sigprocmask static linking bug
simple sigprocmask testing program will fail to be compiled due to
multiple definition of sigprocmask in libpthread.a and libc.a
$ gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread
sigprocmask.c:(.text+0x0): multiple definition of `sigprocmask'
The solution is to define sigprocmask as weak symbol.
Signed-off-by: Jian Peng jipeng2...@gmail.com
---
libc/sysdeps/linux/common/sigprocmask.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libc/sysdeps/linux/common/sigprocmask.c
b/libc/sysdeps/linux/common/sigprocmask.c
index 011d7b3..1d0d51a 100644
--- a/libc/sysdeps/linux/common/sigprocmask.c
+++ b/libc/sysdeps/linux/common/sigprocmask.c
@@ -23,7 +23,7 @@ static __always_inline
_syscall4(int, __rt_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset, size_t, size)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int weak_function sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
@@ -58,7 +58,7 @@ static __always_inline
_syscall3(int, __syscall_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int weak_function sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
--
1.7.4.1
-Original Message-
From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of
Mike Frysinger
Sent: Sunday, March 27, 2011 1:01 AM
To: uclibc@uclibc.org
Subject: Re: sigprocmask testing program failed with static linking
On Sun, Mar 27, 2011 at 3:27 AM, Jian Peng wrote:
please fix your e-mail client to properly wrap long lines.
From 2e435b037624eff8c0daaa146d6feca57ce1eecf Mon Sep 17 00:00:00 2001
From: Jian Peng jipeng2...@gmail.com
Date: Sat, 26 Mar 2011 23:44:52 -0700
Subject: [PATCH 1/1] common: fix sigprocmask static linking bug
simple sigprocmask testing program will fail to be compiled due to multiple
definition of sigprocmask in libpthread.a and libc.a
you need to manually line wrap your changelog to like 74 chars
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int __attribute__((weak)) sigprocmask(int how, const sigset_t * set,
sigset_t * oldset)
you need to use weak_function. raw __attribute__((...)) is rarely the
way to go anymore.
-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
sigprocmask testing program failed with static linking
This is one of many potential static linking problems in uClibc. Last time, I
reported a bug on sigaction and submitted a patch, but similar multiple
definition error could happen to any function that was defined as GLOBAL in
both libc.a and libpthread.a while certain runtime supporting function from
libc, like abort(), also call it.
For example, sigprocmask-test.c is a simple testing program and
$ gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread
Since sigprocmask is GLOBAL in both libc.a and libpthread.a, sigprocmask called
in main function will pull in pt-sigprocmask.os from libpthread.a, but later,
another sigprocmask called in abort (part of libc) will pull in sigprocmask.os
from libc.a and leads to multiple definition error.
To fix it, sigprocmask has to be defined as weak symbol. The same solution
could be applied to other functions in libc/sysdeps/linux/common that will be
called in both main and runtime supporting function in libc. I will identify
them and post patch later.
Here is my patch to fix sigprocmask, and it was tested on gcc-4.5.2 based
toolchain on MIPS.
From 2e435b037624eff8c0daaa146d6feca57ce1eecf Mon Sep 17 00:00:00 2001
From: Jian Peng jipeng2...@gmail.com
Date: Sat, 26 Mar 2011 23:44:52 -0700
Subject: [PATCH 1/1] common: fix sigprocmask static linking bug
simple sigprocmask testing program will fail to be compiled due to multiple
definition of sigprocmask in libpthread.a and libc.a
mipsel-linux-gcc sigprocmask-test.c -o sigprocmask-test -static -lpthread
sigprocmask.c:(.text+0x0): multiple definition of `sigprocmask'
The solution is to define sigprocmask as weak symbol.
Signed-off-by: Jian Peng jipeng2...@gmail.com
---
libc/sysdeps/linux/common/sigprocmask.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libc/sysdeps/linux/common/sigprocmask.c
b/libc/sysdeps/linux/common/sigprocmask.c
index 011d7b3..35fa6df 100644
--- a/libc/sysdeps/linux/common/sigprocmask.c
+++ b/libc/sysdeps/linux/common/sigprocmask.c
@@ -23,7 +23,7 @@ static __always_inline
_syscall4(int, __rt_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset, size_t, size)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int __attribute__((weak)) sigprocmask(int how, const sigset_t * set, sigset_t
* oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
@@ -58,7 +58,7 @@ static __always_inline
_syscall3(int, __syscall_sigprocmask, int, how, const sigset_t *, set,
sigset_t *, oldset)
-int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
+int __attribute__((weak)) sigprocmask(int how, const sigset_t * set, sigset_t
* oldset)
{
#ifdef SIGCANCEL
sigset_t local_newmask;
--
1.7.4.1
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
static linking failed with sigaction testing program
This is a follow-up of my previous bug report on static linking failed with
sigaction testing program.
With 0.9.32-rc3, following testing program failed with static linking on MIPS.
The result is same with gcc-4.4.5 and gcc-4.5.2. While my old 0.9.29 uClibc
plus gcc-4.4.5 works well.
Here is static-test.c
#include signal.h
int main(void)
{
struct sigaction old, new;
sigaction(11, new, old);
return 3;
}
$ mipsel-linux-gcc static-test.c -o static-test -static -lpthread
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libc.a(sigaction.os):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text+0x0):
first defined here
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libc.a(sigaction.os):
In function `sigaction':
sigaction.c:(.text+0x18): multiple definition of `__sigaction'
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text+0x18):
first defined here
collect2: ld returned 1 exit status
$ mipsel-linux-gcc static-test.c -o static-test -static -lc -lpthread
has no problem.
The reason is that after sigaction was pulled in from
libpthread.a:pt-sigaction.os, another runtime supporting function abort() in
libc calls sigaction that will be pulled from libc.a:sigaction.os, and cause
multiple definitions.
In case that -static -lc -lpthread, sigaction was pulled from
libc.a:sigaction.os to resolve undefined sigaction for both the one called in
abort and main already.
To fix it, __libc_sigaction and __sigaction should not be GLOBAL in both libc.a
and libpthread.a.
Here is my patch to fix it.
From a322d80e01137f8d8287ffda716dbff05960cdab Mon Sep 17 00:00:00 2001
From: Jian Peng jpeng2...@gmail.com
Date: Fri, 25 Mar 2011 16:12:58 -0700
Subject: [PATCH 1/1] MIPS: sigaction static linking failed
With simple sigaction testing program, mipsel-linux-gcc prog.c -o prog -static
-lpthread failed to compile due to multiple definition error of
__libc_sigaction and __sigaction.
The problem is that __libc_sigaction and __sigaction should not be GLOBAL in
both libc.a and libpthread.a.
Signed-off-by: Jian Peng jipeng2...@gmail.com
---
libc/sysdeps/linux/mips/sigaction.c | 19 +++
libpthread/nptl/sysdeps/pthread/sigaction.c |3 +--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/libc/sysdeps/linux/mips/sigaction.c
b/libc/sysdeps/linux/mips/sigaction.c
index f2d2747..26b816c 100644
--- a/libc/sysdeps/linux/mips/sigaction.c
+++ b/libc/sysdeps/linux/mips/sigaction.c
@@ -27,8 +27,9 @@
#define SA_RESTORER0x0400
-extern __typeof(sigaction) __libc_sigaction;
-
+#ifdef NOT_IN_libc
+extern __typeof(sigaction) __libc_sigaction;
+#endif
#ifdef __NR_rt_sigaction
@@ -43,7 +44,12 @@ static void restore(void) __asm__ (__restore);
/* If ACT is not NULL, change the action for SIG to *ACT.
If OACT is not NULL, put the old action for SIG in *OACT. */
-int __libc_sigaction(int sig, const struct sigaction *act, struct sigaction
*oact)
+#ifdef NOT_IN_libc
+int
+#else
+static int
+#endif
+__libc_sigaction(int sig, const struct sigaction *act, struct sigaction *oact)
{
# if _MIPS_SIM != _ABIO32
struct sigaction kact;
@@ -65,7 +71,12 @@ extern void restore(void) __asm__ (__restore)
attribute_hidden;
/* If ACT is not NULL, change the action for SIG to *ACT.
If OACT is not NULL, put the old action for SIG in *OACT. */
-int __libc_sigaction(int sig, const struct sigaction *act, struct sigaction
*oact)
+#ifdef NOT_IN_libc
+int
+#else
+static int
+#endif
+__libc_sigaction(int sig, const struct sigaction *act, struct sigaction *oact)
{
int result;
struct old_kernel_sigaction kact, koact;
diff --git a/libpthread/nptl/sysdeps/pthread/sigaction.c
b/libpthread/nptl/sysdeps/pthread/sigaction.c
index e004a39..190a3ab 100644
--- a/libpthread/nptl/sysdeps/pthread/sigaction.c
+++ b/libpthread/nptl/sysdeps/pthread/sigaction.c
@@ -26,8 +26,7 @@
#define LIBC_SIGACTION 1
#include sigaction.c
-extern __typeof(sigaction) __sigaction;
-int
+static int
__sigaction (int sig, const struct sigaction *act, struct sigaction *oact)
{
if (__builtin_expect (sig == SIGCANCEL || sig == SIGSETXID, 0))
--
1.7.4.1
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
static linking failed on MIPS due to multiple definitions
With 0.9.32-rc3, following testing program failed with static linking on MIPS.
The result is same with gcc-4.4.5 and gcc-4.5.2. While my old 0.9.29 uClibc
plus gcc-4.4.5 works well.
Here is static-test.c
#include signal.h
int main(void)
{
struct sigaction old, new;
sigaction(11, new, old);
return 3;
}
$ mipsel-linux-gcc static-test.c -o static-test -static -lpthread
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libc.a(sigaction.os):
In function `__libc_sigaction':
sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text+0x0):
first defined here
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libc.a(sigaction.os):
In function `sigaction':
sigaction.c:(.text+0x18): multiple definition of `__sigaction'
/big/toolchains/stbgcc-4.5.2-0.2/bin/../mipsel-linux-uclibc/sys-root/usr/lib/libpthread.a(pt-sigaction.os):pt-sigaction.c:(.text+0x18):
first defined here
collect2: ld returned 1 exit status
It is weird here since both __libc_sigaction and __sigaction are hidden, but
somehow got pulled in by linker and spit error as above.
The similar problem happened on most sig* functions, like sigprocmask, etc.
Thanks,
Jian
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: A modest proposal: call it 1.0
My testing showed that protected symbol feature is still broken on MIPS. If you run cancel23 in testsuite, you can see it. I check ELF binary of libc and libpthread and attributes are expected, but not sure whether gcc I used really works nicely with ldso in rc2 in terms of protected symbol. The inlined forwarder make debugging this to be very hard too. I am using rc2 built with gcc-4.5.2. If any other can successfully run cancel23 on MIPS, please let me know which gcc you used. Thanks, Jian -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Khem Raj Sent: Friday, February 11, 2011 4:37 PM To: Bernhard Reutner-Fischer Cc: uclibc@uclibc.org Subject: Re: A modest proposal: call it 1.0 On (09/02/11 20:48), Bernhard Reutner-Fischer wrote: On Wed, Feb 09, 2011 at 01:38:00PM -0600, ANDY KENNEDY wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Bernhard Reutner- Fischer Sent: Wednesday, February 09, 2011 1:33 PM To: ander...@codepoet.org; Rob Landley; uclibc@uclibc.org Subject: Re: A modest proposal: call it 1.0 Where '+' means ported, 'o' means TODO/needs verification o mips I'm using NPTL on Mips, if you consider this verification, then you have it. i've updated the TODO file accordingly. I too support the bump to 1.0 -- why wait? why not wait. Remember that it's a version number, nothing more. See TODO Its just not number IMHO. Its a statement which reflects our progress and stating 1.0 is right at present. We have had major feature in form of nptl and I have always been suggesting that we call it 1.0 when we release nptl. TODO list can be adjusted to be part of 1.2 for SuS compatibility Thanks -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 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH 4/5] Add protected symbols support for all architectures
Hi, Carmelo,
I tried to apply the patch after git pull to update from master, but it failed
$ patch -p1 ../uClibc-0.9.32-protected-symbol-1.patch
patching file ldso/ldso/i386/elfinterp.c
Hunk #1 FAILED at 175.
Hunk #2 FAILED at 188.
2 out of 2 hunks FAILED -- saving rejects to file ldso/ldso/i386/elfinterp.c.rej
The line 175 mismatched as shown in ldso/ldso/i386/elfinterp.c.rej
*** _dl_do_reloc(struct elf_resolve *tpnt, struct dyn_elf *scope,
*** 175,183
symbol_addr = 0;
symname = strtab + symtab[symtab_index].st_name;
-if (symtab_index
-(ELF32_ST_VISIBILITY(symtab[symtab_index].st_other)
- != STV_PROTECTED)) {
symbol_addr = (unsigned long)_dl_find_hash(symname, scope,
tpnt,
elf_machine_type_class(reloc_type), tls_tpnt);
--- 175,181
symbol_addr = 0;
symname = strtab + symtab[symtab_index].st_name;
+if (symtab_index) {
symbol_addr = (unsigned long)_dl_find_hash(symname, scope,
tpnt,
elf_machine_type_class(reloc_type), tls_tpnt);
*** _dl_do_reloc(struct elf_resolve *tpnt, struct dyn_elf *scope,
*** 190,200
ELF32_ST_BIND(symtab[symtab_index].st_info) != STB_WEAK))
return 1;
} else {
-if (symtab_index)
-symbol_addr = DL_FIND_HASH_VALUE(tpnt,
elf_machine_type_class(reloc_type),
-
symtab[symtab_index]);
-else
-symbol_addr = symtab[symtab_index].st_value;
tls_tpnt = tpnt;
}
--- 188,194
ELF32_ST_BIND(symtab[symtab_index].st_info) != STB_WEAK))
return 1;
} else {
+symbol_addr = symtab[symtab_index].st_value;
tls_tpnt = tpnt;
}
Any suggestion?
Thanks,
Jian
From: uclibc-boun...@uclibc.org [uclibc-boun...@uclibc.org] On Behalf Of
Carmelo AMOROSO [carmelo.amor...@st.com]
Sent: Wednesday, January 12, 2011 7:48 AM
To: Natanael Copa
Cc: uclibc@uclibc.org
Subject: Re: [PATCH 4/5] Add protected symbols support for all architectures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/12/2011 4:31 PM, Natanael Copa wrote:
On Wed, Jan 12, 2011 at 12:22 PM, Carmelo AMOROSO
carmelo.amor...@st.com wrote:
From: Salvatore Cro salvatore@st.com
Protected symbols are global symbols for which interposition is not
allowed.
We manage them in generic _dl_lookup_hash function. To handle protected
symbols
we need to get a reference to the module that defines the symbol itself.
So we pass a new parameter 'struct symbol_ref' to the __dl_lookup_hash
that is defined as below:
struct symbol_ref {
const ElfW(Sym) *sym;
struct elf_resolve *tpnt;
};
The tpnt field is used as an ouput parameter and refers to the module which
defines
the protected symbol.
Further it can be used as output parameter for TLS relocations and FDPIC
case.
The sym field is instead used as an input parameter to detect the
visibility
of the
symbol we are looking-up.
In this way we get rid of different signatures for _dl_lookup_hash,
allowing
to remove
the _dl_find_hash wrapper.
This new structure is also suitable for prelink integration.
Signed-off-by: Salvatore Cro salvatore@st.com
Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com
---
ldso/include/dl-hash.h| 16
ldso/ldso/arm/elfinterp.c |6 +-
ldso/ldso/avr32/elfinterp.c | 13 +++--
ldso/ldso/bfin/elfinterp.c| 18 --
ldso/ldso/cris/elfinterp.c|5 -
ldso/ldso/dl-hash.c | 20
ldso/ldso/i386/elfinterp.c|6 +-
ldso/ldso/m68k/elfinterp.c| 15 ---
ldso/ldso/mips/elfinterp.c|6 +-
ldso/ldso/powerpc/elfinterp.c | 20 +++-
ldso/ldso/sh/elfinterp.c | 10 +++---
ldso/ldso/sh64/elfinterp.c|7 +--
ldso/ldso/sparc/elfinterp.c | 24 +---
ldso/ldso/x86_64/elfinterp.c | 20 +++-
ldso/ldso/xtensa/elfinterp.c | 11 ++-
ldso/libdl/libdl.c|7 ---
16 files changed, 123 insertions(+), 81 deletions(-)
this didnt apply against current git master?
maybe needs a rebase?
-nc
Hi you need to apply also the patch 1,2 and 3 that revert the arch
specific implementation (sh, asrm i386). The patch set was created
against an updated master branch.
Cheers,
carmelo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10
-lc -lpthread link order works on x86_64 glibc-2.9, but cause hang on uClibc-0.9.32-rc1 on mipsel with NPTL
-lc -lpthread link order works on Linux with glibc-2.9 on x86_64, but cause
hang on uClibc-0.9.32-rc1 on mipsel with NPTL
The testing program is very simple as follow
#include stdio.h
#include pthread.h
int main(int argc, char *argv[])
{
pthread_cond_t cond;
printf( === Start Pthread Test !!! === \n);
pthread_cond_init(cond, NULL);
printf( === End Pthread Test !!! === \n);
return 0;
}
In following build,
$ mipsel-linux-gcc main.c -o /tftpboot/maintest.1 -lpthread
$ mipsel-linux-gcc main.c -o /tftpboot/maintest.2 -pthread
$ mipsel-linux-gcc main.c -o /tftpboot/maintest.3 -pthread -lc
$ mipsel-linux-gcc main.c -o /tftpboot/maintest.4 -lc -pthread
$ mipsel-linux-gcc main.c -o /tftpboot/maintest.5 -lc -lpthread
Only maintest.1 and maintest.2 works as expected, while the rest hang as
# ./maintest.3
=== Start Pthread Test !!! ===
^C
#
The problem was reported before and treated as wrong linking order (should be
-lpthread -lc), but for lots of complicated projects, it is very hard to
control link order due to stacking of LD_FLAGS from multiple makefiles.
IMHO, this can be resolved by defining pthread_* as libc_hidden_def to avoid to
be overridden by the one from libc.so.
Any suggestion?
Thanks,
Jian
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
anyone build mipsel with NPTL from uClibc snapshot
Today, I tried to build uClibc snapshot (on June 3, 2010) for mipsel target, and it failed since CPU_CFLAGS was used as host gcc option that includes options for MIPS, like -mips32. Is this known issue or something wrong with my env or config file? My env is Ubuntu 9.10 x86_64 Bash 4.0.33 make 3.81 gcc 4.4.1 Here is error from make V=1 set -e; \ tmp=`mktemp ./include/bits/sysnum.h.XX 2/dev/null || true`; \ [ -z $tmp ] tmp='./include/bits/sysnum.h.new'; \ KERNEL_HEADERS=stblinux-2.6.31/include/ top_builddir=./ CC=gcc -funsigned-char -fno-builtin -fno-asm -std=gnu99 -mips32 -mtune=mips32 -mabi=32 /bin/sh extra/scripts/gen_bits_syscall_h.sh $tmp; \ if cmp ./include/bits/sysnum.h $tmp /dev/null 21; then \ rm -f $tmp; \ else \ mv -f $tmp ./include/bits/sysnum.h; \ fi cc1: error: unrecognized command line option -mips32 cc1: error: unrecognized command line option -mabi=32 cc1: error: bad value (mips32) for -mtune= switch cc1: error: unrecognized command line option -mips32 cc1: error: unrecognized command line option -mabi=32 cc1: error: bad value (mips32) for -mtune= switch if grep -q __NR_ include/bits/sysnum.h; then true; else \ rm -f include/bits/sysnum.h; \ echo ERROR: Could not generate syscalls.; \ echo Make sure that you have proper kernel headers.; \ echo Your .config in KERNEL_HEADERS=\\ was set to:; \ echo stblinux-2.6.31/include/; \ exit 1; \ fi ERROR: Could not generate syscalls. Make sure that you have proper kernel headers. Your .config in KERNEL_HEADERS= was set to: stblinux-2.6.31/include/ make: *** [include/bits/sysnum.h] Error 1 Here is my .config file # # Automatically generated make config: don't edit # Version: 0.9.32-git # Tue Jun 1 17:28:54 2010 # # TARGET_alpha is not set # TARGET_arm is not set # TARGET_avr32 is not set # TARGET_bfin is not set # TARGET_cris is not set # TARGET_e1 is not set # TARGET_frv is not set # TARGET_h8300 is not set # TARGET_hppa is not set # TARGET_i386 is not set # TARGET_i960 is not set # TARGET_ia64 is not set # TARGET_m68k is not set # TARGET_microblaze is not set TARGET_mips=y # TARGET_nios is not set # TARGET_nios2 is not set # TARGET_powerpc is not set # TARGET_sh is not set # TARGET_sh64 is not set # TARGET_sparc is not set # TARGET_v850 is not set # TARGET_vax is not set # TARGET_x86_64 is not set # TARGET_xtensa is not set # # Target Architecture Features and Options # TARGET_ARCH=mips FORCE_OPTIONS_FOR_ARCH=y CONFIG_MIPS_O32_ABI=y # CONFIG_MIPS_N32_ABI is not set # CONFIG_MIPS_N64_ABI is not set # CONFIG_MIPS_ISA_1 is not set # CONFIG_MIPS_ISA_2 is not set # CONFIG_MIPS_ISA_3 is not set # CONFIG_MIPS_ISA_4 is not set CONFIG_MIPS_ISA_MIPS32=y # CONFIG_MIPS_ISA_MIPS32R2 is not set # CONFIG_MIPS_ISA_MIPS64 is not set TARGET_SUBARCH= # # Using ELF file format # ARCH_ANY_ENDIAN=y ARCH_LITTLE_ENDIAN=y # ARCH_WANTS_BIG_ENDIAN is not set ARCH_WANTS_LITTLE_ENDIAN=y ARCH_HAS_MMU=y ARCH_USE_MMU=y UCLIBC_HAS_FLOATS=y UCLIBC_HAS_FPU=y DO_C99_MATH=y # DO_XSI_MATH is not set # UCLIBC_HAS_FENV is not set KERNEL_HEADERS=stblinux-2.6.31/include HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set DOPIC=y # ARCH_HAS_NO_SHARED is not set # ARCH_HAS_NO_LDSO is not set HAVE_SHARED=y FORCE_SHAREABLE_TEXT_SEGMENTS=y LDSO_LDD_SUPPORT=y LDSO_CACHE_SUPPORT=y LDSO_PRELOAD_ENV_SUPPORT=y # LDSO_PRELOAD_FILE_SUPPORT is not set LDSO_BASE_FILENAME=ld.so # UCLIBC_STATIC_LDCONFIG is not set LDSO_RUNPATH=y LDSO_SEARCH_INTERP_PATH=y UCLIBC_CTOR_DTOR=y # LDSO_GNU_HASH_SUPPORT is not set # HAS_NO_THREADS is not set # LINUXTHREADS_OLD is not set LINUXTHREADS_NEW=y # UCLIBC_HAS_THREADS_NATIVE is not set UCLIBC_HAS_THREADS=y PTHREADS_DEBUG_SUPPORT=y UCLIBC_HAS_SYSLOG=y UCLIBC_HAS_LFS=y # MALLOC is not set # MALLOC_SIMPLE is not set MALLOC_STANDARD=y MALLOC_GLIBC_COMPAT=y UCLIBC_DYNAMIC_ATEXIT=y # COMPAT_ATEXIT is not set UCLIBC_SUSV3_LEGACY=y UCLIBC_SUSV3_LEGACY_MACROS=y # UCLIBC_SUSV4_LEGACY is not set # UCLIBC_HAS_STUBS is not set UCLIBC_HAS_SHADOW=y UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y UCLIBC_HAS___PROGNAME=y UCLIBC_HAS_PTY=y ASSUME_DEVPTS=y UNIX98PTY_ONLY=y # UCLIBC_HAS_GETPT is not set # UCLIBC_HAS_LIBUTIL is not set UCLIBC_HAS_TM_EXTENSIONS=y UCLIBC_HAS_TZ_CACHING=y UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH=/etc/TZ UCLIBC_FALLBACK_TO_ETC_LOCALTIME=y # # Advanced Library Settings # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 # # Support various families of functions # UCLIBC_LINUX_MODULE_24=y UCLIBC_LINUX_SPECIFIC=y UCLIBC_HAS_GNU_ERROR=y UCLIBC_BSD_SPECIFIC=y UCLIBC_HAS_BSD_ERR=y # UCLIBC_HAS_OBSOLETE_BSD_SIGNAL is not set # UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL is not set # UCLIBC_NTP_LEGACY is not set # UCLIBC_SV4_DEPRECATED is not set UCLIBC_HAS_REALTIME=y UCLIBC_HAS_ADVANCED_REALTIME=y UCLIBC_HAS_EPOLL=y UCLIBC_HAS_XATTR=y
