Re: NPTL branch temporarily broken
Carmelo AMOROSO wrote:
Denys Vlasenko wrote:
On Wednesday 10 December 2008 10:06, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all informed.
Further I'm just writing a detailed report on current status of merge,
that I can say is almost complete (once figured out what is not
actually working ;-) ).
I'm currently 100% focused on uclibc.
Cheers,
Carmelo
Khem,
I think to have found what is causing problems on nptl branch
(anyway I don't know why yet).
The cause is the change merged from trunk in the file
libc/sysdeps/linux/common/bits/sigset.h (rev 24243)
that includes all changes occurred in the same file on trunk
in rev 24183 / 24220 / 24221 by vda.
Please may you try on ARM reverting that file
and see if it helps. On sh4-nptl it's working better now
Below the boot log on my box... not more PANIC on INIT
even if it's blocking on udev
This seems confirming my idea on signal handling changes.
I'll try to merge on my private branch all changes that are already
in the nptl-branch but thos on signal handling.
The change is that sigset_t is not 1024 bits, but 64 bits
on almost all architectures. Only MIPS has 128.
This affects sigaction and sigprocmask, but they already
are translating libc struct sigaction / sigset_t to kernel's.
With this change sigset_t actually should match kernel one,
albeit struct sigaction is still different a bit.
Anyway, the symptom of breakage would be, for example,
in libc/sysdeps/linux/arm/sigaction.c:
int __libc_sigaction (int sig, const struct sigaction *act, struct sigaction
*oact)
{
int result;
struct kernel_sigaction kact, koact;
enum {
SIGSET_MIN_SIZE = sizeof(kact.sa_mask) sizeof(act-sa_mask)
? sizeof(kact.sa_mask) : sizeof(act-sa_mask)
};
*** first thing to check is whether sizeof(kact.sa_mask) ==
sizeof(act-sa_mask).
I tried to make it work even if it does not, but it's always better if they
match.
add line
struct BUG { int bug[sizeof(kact.sa_mask) == sizeof(act-sa_mask) ? 1 : -1];
};
and if compile fails, sizeof's are not ==.
Let me know that.
if (act) {
kact.k_sa_handler = act-sa_handler;
memcpy (kact.sa_mask, act-sa_mask, SIGSET_MIN_SIZE);
kact.sa_flags = act-sa_flags;
# ifdef HAVE_SA_RESTORER
if (kact.sa_flags SA_RESTORER) {
kact.sa_restorer = act-sa_restorer;
} else {
kact.sa_restorer = choose_restorer (kact.sa_flags);
kact.sa_flags |= SA_RESTORER;
}
# endif
}
*** next:
/* NB: kernel (as of 2.6.25) will return EINVAL
* if sizeof(kact.sa_mask) does not match kernel's sizeof(sigset_t)
*/
result = __syscall_rt_sigaction(sig,
act ? __ptrvalue (kact) : NULL,
oact ? __ptrvalue (koact) : NULL,
sizeof(kact.sa_mask));
Basically, if it throws EINVAL, always, then sizeof(kact.sa_mask) is botched.
(Kernel simply compares it with constant, it must be correct to work,
no greater or equal slack there).
I think adding if (errno == EINVAL) write(2, EINVAL!\n, 8);
will tell you whether it happens.
sigprocmask is simpler:
int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
if (set
...
) {
__set_errno(EINVAL);
return -1;
}
return __rt_sigprocmask(how, set, oldset, _NSIG / 8);
Again, _NSIG / 8 must be correct here, or it will fail always.
Hope this helps
--
vda
Hi Denys,
I
ll try to understand the impacts of this change on ntpl,
following your hints.
For now I preferred to revert back the offending changes to have the
nptl branch working again.
Keep you informed.
Carmelo
Another step forward.
Merged some other piece of signal handling (except for
libc/signal/sigaction.c) and nptl-branch is still working.
Running test-suite on sh4 without regressions.
As usual, Khem if you can, give a try on arm.
TIA,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
Khem Raj wrote: On (10/12/08 17:52), Carmelo AMOROSO wrote: Carmelo AMOROSO wrote: Carmelo AMOROSO wrote: Hi Khem, I'm seeing similar problem on sh4-nptl as happened to you as you told me yesterday.. Something recently merged is causing issues. I'm doing investigation and keep you all informed. Further I'm just writing a detailed report on current status of merge, that I can say is almost complete (once figured out what is not actually working ;-) ). I'm currently 100% focused on uclibc. Cheers, Carmelo Khem, I think to have found what is causing problems on nptl branch (anyway I don't know why yet). The cause is the change merged from trunk in the file libc/sysdeps/linux/common/bits/sigset.h (rev 24243) that includes all changes occurred in the same file on trunk in rev 24183 / 24220 / 24221 by vda. Please may you try on ARM reverting that file and see if it helps. On sh4-nptl it's working better now Below the boot log on my box... not more PANIC on INIT even if it's blocking on udev This seems confirming my idea on signal handling changes. I'll try to merge on my private branch all changes that are already in the nptl-branch but thos on signal handling. - VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 132k freed INIT: version 2.86 booting Fast Starting Kernel event manager... Activating swap. Checking all file systems... fsck 1.39 (29-May-2006) Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Setting up networking...done. Hostname: amorosoc. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap. Cheers, Carmelo Just an update: almost locally merged all the libc (including the libc/misc/internal) but the libc/signal and I have a still bootable uclibc-nptl system on sh4. I'll leave libc/signal as last. OK I tried with this changes reverted(only uclibc rebuilt). Now I do not get the segfaults any more but it just hangs there. I will now try by rebuilding whole rfs. Thx -Khem Hi Khem, I reverted some files of libc/signal and nptl branch is working again (full boot with sysv-init). libc/inet/getaddrinfo.c libc/signal/sigaction.c libc/signal/sigempty.c libc/signal/sigfillset.c libc/signal/sigset-cvt-mask.h libc/sysdeps/linux/common/bits/sigset.h Committed revision 24377. Please try again on ARM/nptl and let me know. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
Denys Vlasenko wrote:
On Wednesday 10 December 2008 10:06, Carmelo AMOROSO wrote:
Carmelo AMOROSO wrote:
Hi Khem,
I'm seeing similar problem on sh4-nptl as happened to you as you told me
yesterday.. Something recently merged is causing issues.
I'm doing investigation and keep you all informed.
Further I'm just writing a detailed report on current status of merge,
that I can say is almost complete (once figured out what is not
actually working ;-) ).
I'm currently 100% focused on uclibc.
Cheers,
Carmelo
Khem,
I think to have found what is causing problems on nptl branch
(anyway I don't know why yet).
The cause is the change merged from trunk in the file
libc/sysdeps/linux/common/bits/sigset.h (rev 24243)
that includes all changes occurred in the same file on trunk
in rev 24183 / 24220 / 24221 by vda.
Please may you try on ARM reverting that file
and see if it helps. On sh4-nptl it's working better now
Below the boot log on my box... not more PANIC on INIT
even if it's blocking on udev
This seems confirming my idea on signal handling changes.
I'll try to merge on my private branch all changes that are already
in the nptl-branch but thos on signal handling.
The change is that sigset_t is not 1024 bits, but 64 bits
on almost all architectures. Only MIPS has 128.
This affects sigaction and sigprocmask, but they already
are translating libc struct sigaction / sigset_t to kernel's.
With this change sigset_t actually should match kernel one,
albeit struct sigaction is still different a bit.
Anyway, the symptom of breakage would be, for example,
in libc/sysdeps/linux/arm/sigaction.c:
int __libc_sigaction (int sig, const struct sigaction *act, struct sigaction
*oact)
{
int result;
struct kernel_sigaction kact, koact;
enum {
SIGSET_MIN_SIZE = sizeof(kact.sa_mask) sizeof(act-sa_mask)
? sizeof(kact.sa_mask) : sizeof(act-sa_mask)
};
*** first thing to check is whether sizeof(kact.sa_mask) ==
sizeof(act-sa_mask).
I tried to make it work even if it does not, but it's always better if they
match.
add line
struct BUG { int bug[sizeof(kact.sa_mask) == sizeof(act-sa_mask) ? 1 : -1];
};
and if compile fails, sizeof's are not ==.
Let me know that.
if (act) {
kact.k_sa_handler = act-sa_handler;
memcpy (kact.sa_mask, act-sa_mask, SIGSET_MIN_SIZE);
kact.sa_flags = act-sa_flags;
# ifdef HAVE_SA_RESTORER
if (kact.sa_flags SA_RESTORER) {
kact.sa_restorer = act-sa_restorer;
} else {
kact.sa_restorer = choose_restorer (kact.sa_flags);
kact.sa_flags |= SA_RESTORER;
}
# endif
}
*** next:
/* NB: kernel (as of 2.6.25) will return EINVAL
* if sizeof(kact.sa_mask) does not match kernel's sizeof(sigset_t) */
result = __syscall_rt_sigaction(sig,
act ? __ptrvalue (kact) : NULL,
oact ? __ptrvalue (koact) : NULL,
sizeof(kact.sa_mask));
Basically, if it throws EINVAL, always, then sizeof(kact.sa_mask) is botched.
(Kernel simply compares it with constant, it must be correct to work,
no greater or equal slack there).
I think adding if (errno == EINVAL) write(2, EINVAL!\n, 8);
will tell you whether it happens.
sigprocmask is simpler:
int sigprocmask(int how, const sigset_t * set, sigset_t * oldset)
{
if (set
...
) {
__set_errno(EINVAL);
return -1;
}
return __rt_sigprocmask(how, set, oldset, _NSIG / 8);
Again, _NSIG / 8 must be correct here, or it will fail always.
Hope this helps
--
vda
Hi Denys,
I
ll try to understand the impacts of this change on ntpl,
following your hints.
For now I preferred to revert back the offending changes to have the
nptl branch working again.
Keep you informed.
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: NPTL branch temporarily broken
Carmelo AMOROSO wrote: Hi Khem, I'm seeing similar problem on sh4-nptl as happened to you as you told me yesterday.. Something recently merged is causing issues. I'm doing investigation and keep you all informed. Further I'm just writing a detailed report on current status of merge, that I can say is almost complete (once figured out what is not actually working ;-) ). I'm currently 100% focused on uclibc. Cheers, Carmelo Khem, I think to have found what is causing problems on nptl branch (anyway I don't know why yet). The cause is the change merged from trunk in the file libc/sysdeps/linux/common/bits/sigset.h (rev 24243) that includes all changes occurred in the same file on trunk in rev 24183 / 24220 / 24221 by vda. Please may you try on ARM reverting that file and see if it helps. On sh4-nptl it's working better now Below the boot log on my box... not more PANIC on INIT even if it's blocking on udev This seems confirming my idea on signal handling changes. I'll try to merge on my private branch all changes that are already in the nptl-branch but thos on signal handling. - VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 132k freed INIT: version 2.86 booting Fast Starting Kernel event manager... Activating swap. Checking all file systems... fsck 1.39 (29-May-2006) Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Setting up networking...done. Hostname: amorosoc. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] bug in __check_pf() (getaddrinfo.c)
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL for ifa_addr means that the interface has no address. Do
you know in what cases does this happen. Patch looks ok though.
True. My environment has a interface that has no address.
And, previous source code had another problem. 'for' statement had no
'{' and '}'. Therefore, If you defined both __UCLIBC_HAS_IPV4__ and
__UCLIBC_HAS_IPV6__, the second 'if' statement would be outside of the
for-loop and occure segfault.
This stuff seems to continuously come back and haunt me ... :-( (I was the
original poster of check_pf-stuff, although it has been modified since
then so can't take credit for all the problems. :-) Patch looks good to me
anyway.
/Ricard
--
Ricard Wolf Wanderl�f ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
Khem,
may you give a try at this patch on nptl branch ? I'm wondering if
this is the cause
of the segfault we are seeing in sysv-init. I've merged getaddrinfo.c
on nptl branch,
and IIRC my config has both ipv4 and ipv6 support enabled.
Unfortunately I don't have access to my box today... anyway I'll
restart with the investigation
tomorrow.
TIA,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] bug in __check_pf() (getaddrinfo.c)
Bernhard Reutner-Fischer wrote:
On Mon, Dec 08, 2008 at 10:35:50AM +0100, Carmelo Amoroso wrote:
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL for ifa_addr means that the interface has no address. Do
you know in what cases does this happen. Patch looks ok though.
True. My environment has a interface that has no address.
And, previous source code had another problem. 'for' statement had no
'{' and '}'. Therefore, If you defined both __UCLIBC_HAS_IPV4__ and
__UCLIBC_HAS_IPV6__, the second 'if' statement would be outside of the
for-loop and occure segfault.
This stuff seems to continuously come back and haunt me ... :-( (I was the
original poster of check_pf-stuff, although it has been modified since
then so can't take credit for all the problems. :-) Patch looks good to me
anyway.
/Ricard
--
Ricard Wolf Wanderl�f ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
Khem,
may you give a try at this patch on nptl branch ? I'm wondering if
this is the cause
of the segfault we are seeing in sysv-init. I've merged getaddrinfo.c
on nptl branch,
and IIRC my config has both ipv4 and ipv6 support enabled.
Unfortunately I don't have access to my box today... anyway I'll
restart with the investigation
tomorrow.
I've applied the other patch to fix the loop to look for both IPv4 and
IPv6 addresses (trunk r24317).
applied on nptl branch as well (rev 24333).
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] bug in __check_pf() (getaddrinfo.c)
Khem Raj wrote:
On (08/12/08 10:35), Carmelo Amoroso wrote:
On 07/12/2008, Ricard Wanderlof [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008, Hiroshi Shinji wrote:
Hi Khem,
Thanks for your comment.
2008/12/6 Khem Raj [EMAIL PROTECTED]:
Getting NULL for ifa_addr means that the interface has no address. Do
you know in what cases does this happen. Patch looks ok though.
True. My environment has a interface that has no address.
And, previous source code had another problem. 'for' statement had no
'{' and '}'. Therefore, If you defined both __UCLIBC_HAS_IPV4__ and
__UCLIBC_HAS_IPV6__, the second 'if' statement would be outside of the
for-loop and occure segfault.
This stuff seems to continuously come back and haunt me ... :-( (I was the
original poster of check_pf-stuff, although it has been modified since
then so can't take credit for all the problems. :-) Patch looks good to me
anyway.
/Ricard
--
Ricard Wolf Wanderl�f ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
Khem,
may you give a try at this patch on nptl branch ? I'm wondering if
this is the cause
of the segfault we are seeing in sysv-init. I've merged getaddrinfo.c
Carmelo
I tried this patch on arm. Did not help :(
Thx
-Khem
ok. thanks. I'll keep to debug it.
carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
NPTL branch temporarily broken
Hi Khem, I'm seeing similar problem on sh4-nptl as happened to you as you told me yesterday.. Something recently merged is causing issues. I'm doing investigation and keep you all informed. Further I'm just writing a detailed report on current status of merge, that I can say is almost complete (once figured out what is not actually working ;-) ). I'm currently 100% focused on uclibc. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/libpthread: nptl nptl/sysdeps/generic nptl/sysdeps/p etc...
Bernhard Reutner-Fischer wrote:
On Wed, Dec 03, 2008 at 09:53:18AM -0800, [EMAIL PROTECTED] wrote:
Author: carmelo
Date: 2008-12-03 09:53:17 -0800 (Wed, 03 Dec 2008)
New Revision: 24246
Log:
Rework nptl build system for cleaning headers and objects
to be compliant with all other Makefile.
The output of the make clean (silent mode) will be as follows:
Modified: branches/uClibc-nptl/libpthread/nptl/Makefile.in
===
--- branches/uClibc-nptl/libpthread/nptl/Makefile.in 2008-12-03 14:07:45 UTC
(rev 24245)
+++ branches/uClibc-nptl/libpthread/nptl/Makefile.in 2008-12-03 17:53:17 UTC
(rev 24246)
nptl_headers_clean:
-$(RM) $(PTDIR)/banner.h $(top_builddir)include/pthread.h\
- $(PTDIR)/version.h $(top_builddir)include/semaphore.h \
+$(do_rm) $(addprefix $(top_builddir),$(nptl_headers_bootstrap)) \
$(PTHREAD_OUT)/pthread-errnos.{c,h,s}
The primary reason why do_rm was added was to be gentle to shells which do not
do bash-like globs. Please refer to the samples on trunk.
Hi Bernhard,
it should be fine now (rev 24254). Thanks for pointing this out.
PS: It would be nice if we would move to use something like $(call do_rm,)
mid-term since with that it should be easier to pretty-print the dirname of
the affected files once and correctly (as you can see i cheat with the names
a bit right now). Any volunteers?
not now for me, sorry :(
Modified:
branches/uClibc-nptl/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.in
===
--- branches/uClibc-nptl/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.in
2008-12-03 14:07:45 UTC (rev 24245)
+++ branches/uClibc-nptl/libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.in
2008-12-03 17:53:17 UTC (rev 24246)
@@ -130,7 +130,7 @@
librt-a-y += $(LIBRT_LINUX_OBJ)
librt-so-y += $(LIBRT_LINUX_OBJ:.o=.oS)
-objclean-y += nptl_linux_objclean
+objclean-y += nptl_linux_clean
headers_clean-y += nptl_linux_headers_clean
#
@@ -188,11 +188,13 @@
$(ALL_HEADERS_BITS_PTHREAD):
$(do_ln) ../../$(PTHREAD_LINUX_DIR)/bits/$(@F) $(top_builddir)$@
+nptl_linux_headers_all:= $(PTHREAD_LINUX_OUT)/lowlevelbarrier.{c,h,s}
\
+$(PTHREAD_LINUX_OUT)/lowlevelcond.{c,h,s} \
+$(PTHREAD_LINUX_OUT)/lowlevelrwlock.{c,h,s} \
+$(PTHREAD_LINUX_OUT)/unwindbuf.{c,h,s}
breaks too, fwiw
fixed too.
Cheers,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl: include libc/misc/internals
[EMAIL PROTECTED] wrote: Author: kraj Date: 2008-12-01 19:11:25 -0800 (Mon, 01 Dec 2008) New Revision: 24225 Log: signed-off-by: Khem Raj [EMAIL PROTECTED] More merges from trunk to get nptl compiling for arm. Also fix some errno related linking problems. Added: branches/uClibc-nptl/libc/misc/internals/internal_errno.h Modified: branches/uClibc-nptl/include/netdb.h branches/uClibc-nptl/libc/misc/internals/ branches/uClibc-nptl/libc/misc/internals/Makefile.in branches/uClibc-nptl/libc/misc/internals/__errno_location.c Thanks Khem, they were on my working copy. I'll check them on sh4 Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl: include libc/misc/internals
Carmelo AMOROSO wrote: [EMAIL PROTECTED] wrote: Author: kraj Date: 2008-12-01 19:11:25 -0800 (Mon, 01 Dec 2008) New Revision: 24225 Log: signed-off-by: Khem Raj [EMAIL PROTECTED] More merges from trunk to get nptl compiling for arm. Also fix some errno related linking problems. Added: branches/uClibc-nptl/libc/misc/internals/internal_errno.h Modified: branches/uClibc-nptl/include/netdb.h branches/uClibc-nptl/libc/misc/internals/ branches/uClibc-nptl/libc/misc/internals/Makefile.in branches/uClibc-nptl/libc/misc/internals/__errno_location.c Thanks Khem, they were on my working copy. I'll check them on sh4 Carmelo Yeah... nptl branch build fine for me too. I'll come with further merge soon. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Filippo ARCIDIACONO wrote: -Original Message- From: Carmelo Amoroso [mailto:[EMAIL PROTECTED] Sent: Saturday, November 29, 2008 3:25 PM To: Tobias Poschwatta Cc: Filippo ARCIDIACONO; 'Carmelo AMOROSO'; uclibc@uclibc.org Subject: Re: testsuite: wcsxfrm Tobias Poschwatta wrote: On Thu, Nov 27, 2008 at 08:45:18AM +0100, Carmelo Amoroso wrote: Thanks Filippo. Please TObia may you give a try ? Thanks, works much better now. There are only two failing tests remaining in locale-mbwc: tst_iswctype and tst_wcswidth. Output attached. Thanks, T. Yes, we know. Filippo will try to fix these asap. In the meanwhile any patches are welcome. Ok, the test failures has been fixed. Soon will be available. Committed on trunk/nptl/0.9.30. Thanks Filippo. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Regarding setting of errno on System Call fail.
Arvind Kumar wrote: Hello! Any clue will be appreciated. I am running my application on target machine which contain uclibc version 0.2.29. http://0.2.29. In my application connect system call is called. On my Linux host machine, connect system call is failed and errno is set to EINPROGRESS. But on my target machine, at some point of time when connect system call is failed, the errno is not set to EINPROGRESS. There is some problem of setting of errno. Could anyone please help.. Thanks Regards, Arvind Please, provide a simple test case with us, better if it is test-suite complaint so that it can be included to check and fix any potential bug. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: What is the preferred code style for uclibc?
Denys Vlasenko wrote:
Hi Bernhard, folks,
Can you indicate what coding style you prefer
in uclibc?
Hi Denys,
my preferred style is kernel's one, I don't think uclibc has
a preferred one, even if, yesy, a Coding style rules could be useful.
Curretly we have a mixture of all kinds,
GNU style with its uniquely difficult placement
of {}s:
if (set == NULL || signo = 0 || signo = NSIG)
{
__set_errno (EINVAL);
return -1;
}
indent-by-4 style:
if (act) {
kact.k_sa_handler = act-sa_handler;
kact.sa_mask = act-sa_mask.__val[0];
kact.sa_flags = act-sa_flags;
# ifdef HAVE_SA_RESTORER
if (kact.sa_flags SA_RESTORER) {
kact.sa_restorer = act-sa_restorer;
} else {
kact.sa_restorer = choose_restorer (kact.sa_flags);
kact.sa_flags |= SA_RESTORER;
}
# endif
}
Linux kernel style:
if (bufsize count) {
bufsize = count;
if (count == 0) { /* We're at the end of the
buffer... */
__set_errno(EFBIG);
return -1;
}
}
etc.
Can you let us know what aspects of style you plan to
make more uniform, and in what way; what you don't plan
to regulate.
For example, how would you write this?
while ((n 1)
((wi = fgetwc_unlocked(stream)) != WEOF)
((*p++ = wi) != '\n')
) {
--n;
}
I'd write as follow:
while ((n 1) ((wi = fgetwc_unlocked(stream)) != WEOF)
((*p++ = wi) != '\n')) {
--n;
}
I promise to not engage in gratuitous style changes,
there will be no rain of commits with s/spaces/tabs/, :)
good ;-)
I merely plan to follow the agreed-on style in the code
I touch.
--
vda
carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/sysdeps/linux/sh/bits
Khem Raj wrote: On Thu, Nov 27, 2008 at 6:57 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-11-27 06:52:15 -0800 (Thu, 27 Nov 2008) New Revision: 24165 Log: Make __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ visible in case the arch supports this feature. SH4 will use this in some aseembly files for the NPTL implementation. Add now safely on trunk. don't worry guys... I'm not going to add any of NPTL part to trunk. Just while working on merge trynk to branch, I'm going to add some absolutely safe change in trunk to simplify future merge, and avoid looking more and more times at the same files. I hope nobody would have some concerns on this. It will simplify my work a lot. Good idea.Yes common changes from the branch should be first brought into trunk. It can be done as you bring nptl branch upto date with trunk. Hi Khem, ok. I've got just an error while building due to undefined __errno_location. I removed an hidden_def an it worked, but it is just a w/a. At this point we need definitively merge the errno.h properly. Next modnday I'll be focused on this (unable to this this at home) Ciao, Carmelo TIA, Carmelo Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED] Modified: trunk/uClibc/include/libc-symbols.h trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h Changeset: Modified: trunk/uClibc/include/libc-symbols.h === --- trunk/uClibc/include/libc-symbols.h 2008-11-27 14:43:17 UTC (rev 24164) +++ trunk/uClibc/include/libc-symbols.h 2008-11-27 14:52:15 UTC (rev 24165) @@ -133,6 +133,12 @@ # undef HAVE_ASM_GLOBAL_DOT_NAME #endif +#ifdef __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ +# define HAVE_ASM_CFI_DIRECTIVES +#else +# undef HAVE_ASM_CFI_DIRECTIVES +#endif + #if defined HAVE_ASM_WEAK_DIRECTIVE || defined HAVE_ASM_WEAKEXT_DIRECTIVE # define HAVE_WEAK_SYMBOLS #endif Modified: trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h === --- trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h 2008-11-27 14:43:17 UTC (rev 24164) +++ trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h 2008-11-27 14:52:15 UTC (rev 24165) @@ -39,6 +39,9 @@ /* needed probably only for ppc64 */ #undef __UCLIBC_HAVE_ASM_GLOBAL_DOT_NAME__ +/* define if target supports CFI pseudo ops */ +#define __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ + /* define if target supports IEEE signed zero floats */ #define __UCLIBC_HAVE_SIGNED_ZERO__ ___ uClibc-cvs mailing list [EMAIL PROTECTED] http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Tobias Poschwatta wrote: On Thu, Nov 27, 2008 at 08:45:18AM +0100, Carmelo Amoroso wrote: Thanks Filippo. Please TObia may you give a try ? Thanks, works much better now. There are only two failing tests remaining in locale-mbwc: tst_iswctype and tst_wcswidth. Output attached. Thanks, T. Yes, we know. Filippo will try to fix these asap. In the meanwhile any patches are welcome. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include libc/sysdeps/linux/sh/bits
[EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-11-27 06:52:15 -0800 (Thu, 27 Nov 2008) New Revision: 24165 Log: Make __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ visible in case the arch supports this feature. SH4 will use this in some aseembly files for the NPTL implementation. Add now safely on trunk. don't worry guys... I'm not going to add any of NPTL part to trunk. Just while working on merge trynk to branch, I'm going to add some absolutely safe change in trunk to simplify future merge, and avoid looking more and more times at the same files. I hope nobody would have some concerns on this. It will simplify my work a lot. TIA, Carmelo Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED] Modified: trunk/uClibc/include/libc-symbols.h trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h Changeset: Modified: trunk/uClibc/include/libc-symbols.h === --- trunk/uClibc/include/libc-symbols.h 2008-11-27 14:43:17 UTC (rev 24164) +++ trunk/uClibc/include/libc-symbols.h 2008-11-27 14:52:15 UTC (rev 24165) @@ -133,6 +133,12 @@ # undef HAVE_ASM_GLOBAL_DOT_NAME #endif +#ifdef __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ +# define HAVE_ASM_CFI_DIRECTIVES +#else +# undef HAVE_ASM_CFI_DIRECTIVES +#endif + #if defined HAVE_ASM_WEAK_DIRECTIVE || defined HAVE_ASM_WEAKEXT_DIRECTIVE # define HAVE_WEAK_SYMBOLS #endif Modified: trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h === --- trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h 2008-11-27 14:43:17 UTC (rev 24164) +++ trunk/uClibc/libc/sysdeps/linux/sh/bits/uClibc_arch_features.h 2008-11-27 14:52:15 UTC (rev 24165) @@ -39,6 +39,9 @@ /* needed probably only for ppc64 */ #undef __UCLIBC_HAVE_ASM_GLOBAL_DOT_NAME__ +/* define if target supports CFI pseudo ops */ +#define __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__ + /* define if target supports IEEE signed zero floats */ #define __UCLIBC_HAVE_SIGNED_ZERO__ ___ uClibc-cvs mailing list [EMAIL PROTECTED] http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
libc_hidden_proto removal
Hi Denys, among a lot of other stuff, I'm merging into nptl branch your changes for hidden proto removal. I'd like to test it on nptl. I've seen that you are commenting out and not removing... I can understand and that's fine for me... as well as if you are going to remove other parts, I'll synch them immediately. But, the final definitive removal of the commented libc_hidden_proto I'd like to happen after the NPTL merge, if possible. We could live for a while with the comment in the trunk. Do you agree ? TIA, CArmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Tobias Poschwatta wrote: Hi, in libc/strings/Makefile.in, it seems that wcsxfrm is included only if UCLIBC_HAS_LOCALE is selected. But the test case test/locale-mbwc/tst_wcsxfrm.c is run if UCLIBC_HAS_WCHAR is selected. So, if WCHAR is enabled, but LOCALE disabled, the testsuite fails: gcc -Wall -Wstrict-prototypes -Os -funit-at-a-time -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -fstrict-aliasing -Os -D_GNU_SOURCE -I../../test-mlittle-endian -nostdinc -I../../install_dir/usr/include -I/usr/lib/gcc/armv5l-unknown-linux-uclibceabi/4.3.3//include-fixed -I/usr/lib/gcc/armv5l-unknown-linux-uclibceabi/4.3.3/include -D__USE_GNU -fno-builtin -c tst_wcsxfrm.c -o tst_wcsxfrm.o gcc -s -B../../lib -Wl,-rpath,../../lib -Wl,-rpath-link,../../lib -Wl,--dynamic-linker,/tmp/build/uclibc-0.9.30/build/test/locale-mbwc/../../lib/ld-uClibc.so.0 tst_wcsxfrm.o -o tst_wcsxfrm tst_wcsxfrm.o: In function `tst_wcsxfrm': tst_wcsxfrm.c:(.text+0x208): undefined reference to `wcsxfrm' tst_wcsxfrm.c:(.text+0x2c4): undefined reference to `wcsxfrm' collect2: ld returned 1 exit status make[2]: *** [tst_wcsxfrm] Error 1 T. Fixed in rev 24147. Please give it a try. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Tobias Poschwatta wrote: On Tue, Nov 25, 2008 at 03:39:08PM +0100, Carmelo AMOROSO wrote: Fixed in rev 24147. Please give it a try. That particular test case works now. Thanks. Still, because locale is disabled, a lots of tests fail in test/locale-mbwc with 'can't set locale' messages. Tobias do you mean at runtime, or while compiling ? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Tobias Poschwatta wrote: On Tue, Nov 25, 2008 at 04:47:11PM +0100, Carmelo AMOROSO wrote: do you mean at runtime, or while compiling ? at runtime. All tests compile, now. E.g.: Ok. Well firstly locale support is not totally completed even if recently we did a lot of progresses on this. My colleague Filippo at ST worked a lot hardly on this and all we fixed in the locale area in on the trunk. test/locale-mbwc# cat tst_iswalnum.out Warning : can't set locale: de_DE.ISO-8859-1 skipping ... Warning : can't set locale: de_DE.UTF-8 skipping ... Warning : can't set locale: ja_JP.UTF-8 skipping ... iswalnum:de_DE.ISO-8859-1:0:0:0:L:can't set locale iswalnum:de_DE.UTF-8:0:0:0:L:can't set locale iswalnum:C:1:1:2:S:PASSED [...] iswalnum:C:20:1:2:S:PASSED iswalnum:ja_JP.UTF-8:0:0:0:L:can't set locale Exit status is 1: test/locale-mbwc# ./tst_iswalnum Warning : can't set locale: de_DE.ISO-8859-1 skipping ... iswalnum:de_DE.ISO-8859-1:0:0:0:L:can't set locale Warning : can't set locale: de_DE.UTF-8 skipping ... iswalnum:de_DE.UTF-8:0:0:0:L:can't set locale iswalnum:C:1:1:2:S:PASSED [...] iswalnum:C:20:1:2:S:PASSED Warning : can't set locale: ja_JP.UTF-8 skipping ... iswalnum:ja_JP.UTF-8:0:0:0:L:can't set locale [EMAIL PROTECTED]:/tmp/build/uclibc-0.9.30/build/test/locale-mbwc# echo $? 1 It seems that you don't have these locales built-in. Are you using pre-generated locale headers ? or are you building locales data at build time ? Obviously patches are welcome. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: testsuite: wcsxfrm
Tobias Poschwatta wrote: On Tue, Nov 25, 2008 at 05:19:35PM +0100, Carmelo AMOROSO wrote: It seems that you don't have these locales built-in. Are you using pre-generated locale headers ? or are you building locales data at build time ? Well, actually, locale is disabled: UCLIBC_HAS_WCHAR=y # UCLIBC_HAS_LOCALE is not set The tests in locale-mbcw are run, because WCHAR is enabled. Tobias I'll ask Filippo to have a look at this. Likely we might want to disable (also partially) some part of the tests according to locale. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl/libc/inet
Denys Vlasenko wrote:
On Friday 21 November 2008 06:22, [EMAIL PROTECTED] wrote:
Author: kraj
Date: 2008-11-20 21:22:12 -0800 (Thu, 20 Nov 2008)
New Revision: 24107
Log:
Add _res_init.c to resolv_CSRC.
Please also add a comment why it is necessary.
Hi Denys,
I erroneously removed it in the previous commit and Khem fixed it.
This part is slightly different in nptl branch because _res is a TLS
variable.
This is one of the thing that need to be looked better when final merge
will occur.
So for now, please keep this as the right change.
I hope will look at this soon.
Thanks Khem for fix.
Carmelo
--- branches/uClibc-nptl/libc/inet/Makefile.in 2008-11-20 23:41:56 UTC
(rev 24106)
+++ branches/uClibc-nptl/libc/inet/Makefile.in 2008-11-21 05:22:12 UTC
(rev 24107)
@@ -42,7 +42,7 @@
gethostbyaddr_r.c gethostbyname_r.c gethostbyname2_r.c gethostent_r.c \
gethostbyaddr.c gethostbyname.c gethostbyname2.c gethostent.c \
res_init.c res_query.c res_comp.c ns_name.c \
-ethers.c
+ethers.c _res_state.c
What does it do? There is no _res_state.c file anywhere I can see.
_res is living in res_init.o:
#ifdef L_res_init
/* Protected by __resolv_lock */
struct __res_state _res;
/* Will be called under __resolv_lock. */
static void res_sync_func(void)
{
...
So, if your change is correct, it sure is very non-obvious.
Please add a comment.
--
vda
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: How to build JFFS2 image?
×èíêîâ Àíäðåé wrote: Hi. I can not build JFFS2 image using buildroot. My build attempts always crashes with different errors in .../project_build_mipsel/uclibc/linux-2.6.26.3: errors are like smth unresolved symbol in object file or unknown type in C source file.. if you don't clarify what is the unresolved symbol, we cannot help. Further I suggest to post this directly to buildroot list. May be it is because I use advanced linux kernel configuration? I have Ubuntu8.04 x86 host machine. My target architecture is mipsel. How can I build target JFFS2 image using buildroot and/or mkfs.jffs2 command ? This is not a uclibc issue. Cheers, Carmelo Thanks. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Strange location of kernel-features.h
Carmelo AMOROSO wrote: Peter Kjellerstedt wrote: Can anyone explain to me why kernel-features.h is placed in libpthread/linuxthreads/sysdeps/pthread? As far as I can tell there is nothing pthread related in that file. Hi Peter, probably because it has been simply copied from glibc... your point seems correct to me. This placement will prevent the changes made below by Carmelo in libc/sysdeps/linux/common/getdents.c from taking effect for no apparent reason at all if one uses libpthread/linuxthreads.old. Moreover, if __ASSUME_GETDENTS32_D_TYPE actually happens to be defined while compiling getdents.c when using libpthread/linuxthreads I would say that is more of an accident than anything else since there are no indications in the list of included files that one is expecting kernel-features.h to be included... I'll try to find a better place where to include it. //Peter Thanks, Carmelo Hi, well I've looed at this, I think the best way (ans easiest) is to move kernel-features in libc/sysdeps/linux/common/bits and include it from within features.h. In this way, it will be included automatically in each file. Let me know, so I can commit. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr __tls_get_addr)
Rob Landley wrote:
On Monday 27 October 2008 15:02:19 Rob Landley wrote:
On Monday 27 October 2008 12:50:13 Carmelo AMOROSO wrote:
Sorry for having confused with multiple patches/proposal and emails.
Currently the dl_iterate_phdr symbols is defined in ld-uClibc.so.0 and
libdl.a. The idea is to move into libc.so.0 and libc.a (exactly as glibc
does).
Well, that sounds like a good thing all by itself. Why is uClibc defining
it in a different place than glibc does right now? (And why don't more
programs break due to that?)
For one thing, a statically linked program would never get dl_iterate_phdr
right now, right? (What does that symbol _do_, anyway? Is there some
documentation I should read up on somewhere?)
it turns out there's an existing gentoo bug on this:
http://bugs.gentoo.org/117523
So yes, I think your patch should be applied (probably to 0.9.30.1):
http://www.uclibc.org/lists/uclibc/2008-January/018969.html
Rob
Hi Rob,
finally I've got some time to review and commit my old patch to move
_dl_iterate_phdr into libc.{so,a}.
Committed on trunk rev 24090.
Cheers,
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: libc_hidden_proto removal
Bernhard Reutner-Fischer wrote: On Mon, Nov 17, 2008 at 04:57:41AM +0100, Denys Vlasenko wrote: Sometime ago I removed string.h related libc_hidden_proto's. There were a few bumps, but nothing tragic. So now it sits half-done, something like: ... /* Experimentally off - libc_hidden_proto(strlen) */ /* Experimentally off - libc_hidden_proto(strncat) */ /* Experimentally off - libc_hidden_proto(strncpy) */ /* libc_hidden_proto(strnlen) */ /* Experimentally off - libc_hidden_proto(strstr) */ /* Experimentally off - libc_hidden_proto(strcasecmp) */ libc_hidden_proto(socket) libc_hidden_proto(close) libc_hidden_proto(fopen) libc_hidden_proto(fclose) libc_hidden_proto(random) ... Unless there are some big pending merges which would rather see it postponed, I will start removing the rest of them. Carmelo promised to bring the NPTL branch up to date WRT trunk so we could start reviewing the NPTL changes. Carmelo, would you mind Denys continuing with the hidden_proto removal now or would it be better if we would postpone this some more? Please, go ahead... I'll try to keep aligned with Denys changes. I'm synchronizing nptl branch almost on directory basis. Each commit is guarantee to build (on sh at least), but being these changes no TLS and/or NPTL related, I'm pretty sure the branch should continue working for arm and mips too. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: linuxthreads changes from upstream
Matt Fleming wrote: Hi, the attached patch contains some fixes from linuxthreads HEAD. The patch should apply against trunk. This patch was initially proposed by Will Newton on Aug 27, I've just brought it up to date. Amongst other things it fixes a bug that a customer was seeing with mutex lock/unlock timing issues. Matt Hi Matt, I think providing some explanation about the proposed change it's important, instead of simply saying some fixes. Further what is the customer's bug, and which piece of this patch is intended to fix it. And keeping probably unrelated changes into one only patch is not so comfortable for review. Thanks, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fun with the dynamic loader.
Rob Landley wrote: While debugging why the dynamic loader is just not working for me on sparc, I stumbled across this little gem: Near the end of ldso/ldso/dl-startup.c we have the only user of the START() macro: #ifndef START return _dl_elf_main; #else START(); #endif Only three architectures actually #define this macro: frv, bfin, and avr32. The last of which does: ./avr32/dl-startup.h:#define START()return _dl_elf_main; So it's #defining the macro to do what the absence of the macro would do. Why? I think it can be safely removed. it doesn't make sense. Rob Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] ld.so_nptl: bug discovered while running firefox 3
Hi Khem, All
while doing some test with firefox 3 (linked against uclibc-nptl on
sh4), we discovered a bug in ld.so dynamic linker.
In firefox there is a shared object libejmalloc.so having a constructor
that accesses a TLS variable using the local-dynamic tls access model.
During the ld.so startup the dtv entries are properly initialized just
after calling the constructors for all NEEDED dso, so causing the
segfault in __tls_get_address.
The patch basically move the dtv initialization before calling the
constructor (we checked glibc too, and it correclty does in this way).
My colleague implemented a simple test case (added in the test suite )
that exploits this bug.
Khem, may you run the test case, before and after applying the patch so
on arm-nptl too.
Waiting for your feedback before pushing it out in SVN.
Cheers,
Carmelo
ldso: Initialize fully dtv before calling the constructors.
Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED]
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Index: test/tls/Makefile
===
--- test/tls/Makefile (revision 24035)
+++ test/tls/Makefile (working copy)
@@ -3,7 +3,7 @@
TESTS := tst-tls1 tst-tls2 tst-tls3 tst-tls4 tst-tls5 tst-tls6 tst-tls7
\
tst-tls8 tst-tls9 tst-tls10 tst-tls11 tst-tls12 tst-tls13 \
- tst-tls14 tst-tls15 tst-tls1-static tst-tls2-static \
+ tst-tls14 tst-tls15 tst-tls16 tst-tls1-static tst-tls2-static \
tst-tls9-static
TESTS_DISABLED := tst-tls1-static tst-tls2-static tst-tls9-static
@@ -42,6 +42,7 @@
CFLAGS_tst-tlsmod14b.so := -fPIC -DSHARED -shared
CFLAGS_tst-tlsmod15a.so := -fPIC -DSHARED -shared
CFLAGS_tst-tlsmod15b.so := -fPIC -DSHARED -shared
+CFLAGS_tst-tlsmod16.so := -fPIC -DSHARED -shared
LDFLAGS_tst-tlsmod1.so := -shared -static-libgcc -L$(top_builddir)lib
LDFLAGS_tst-tlsmod2.so := -shared -static-libgcc -L$(top_builddir)lib
@@ -66,6 +67,7 @@
LDFLAGS_tst-tlsmod14b.so := -shared -static-libgcc -L$(top_builddir)lib
LDFLAGS_tst-tlsmod15a.so := -shared -static-libgcc -L$(top_builddir)lib
LDFLAGS_tst-tlsmod15b.so := -shared -static-libgcc -L$(top_builddir)lib
+LDFLAGS_tst-tlsmod16.so := -shared -static-libgcc -L$(top_builddir)lib
LDFLAGS_tst-tls3 := tst-tlsmod1.so
LDFLAGS_tst-tls4 := -ldl
@@ -80,6 +82,7 @@
LDFLAGS_tst-tls13 := -ldl -Wl,-rpath-link=.
LDFLAGS_tst-tls14 := -ldl -Wl,-rpath-link=. tst-tlsmod14a.so
LDFLAGS_tst-tls15 := -ldl -Wl,-rpath-link=.
+LDFLAGS_tst-tls16 := tst-tlsmod16.so
tst-tls3: tst-tlsmod1.so
tst-tls4: tst-tlsmod2.so
@@ -94,6 +97,7 @@
tst-tls13: tst-tlsmod13.so tst-tlsmod13a.so
tst-tls14: tst-tlsmod14a.so tst-tlsmod14b.so
tst-tls15: tst-tlsmod15a.so tst-tlsmod15b.so
+tst-tls16: tst-tlsmod16.so
RET_tst-tls13 := 1
ifeq ($(TARGET_ARCH),mips)
Index: test/tls/tst-tls16.c
===
--- test/tls/tst-tls16.c(revision 0)
+++ test/tls/tst-tls16.c(revision 0)
@@ -0,0 +1,21 @@
+#include stdio.h
+#include stdlib.h
+#include tls.h
+
+#define TLS_VAR_INIT_VALUE 99
+
+#ifdef USE_TLS
+extern __thread int tls_var;
+#endif
+
+int main(void)
+{
+ int ret = EXIT_SUCCESS;
+#ifdef USE_TLS
+ if (tls_var != TLS_VAR_INIT_VALUE) {
+ printf(tls_var = %d - Expected value = %d\n, tls_var,
TLS_VAR_INIT_VALUE);
+ ret = EXIT_FAILURE;
+ }
+#endif
+ return ret;
+}
Index: test/tls/tst-tlsmod16.c
===
--- test/tls/tst-tlsmod16.c (revision 0)
+++ test/tls/tst-tlsmod16.c (revision 0)
@@ -0,0 +1,25 @@
+#include stdio.h
+#include tls.h
+
+#define TLS_VAR_INIT_VALUE 99
+
+#ifdef USE_TLS
+__thread int tls_var __attribute__((tls_model(global-dynamic)));
+static __thread int local_tls_var __attribute__((tls_model(local-dynamic)));
+#endif
+
+void __attribute__((constructor)) libtls_ctor(void);
+void libtls_ctor(void)
+{
+ printf(libtls: constructor!\n);
+#ifdef USE_TLS
+ local_tls_var = TLS_VAR_INIT_VALUE;
+ tls_var = local_tls_var;
+#endif
+}
+
+void __attribute__((destructor)) libtls_dtor(void);
+void libtls_dtor(void)
+{
+ printf(libtls: destructor!\n);
+}
Index: ldso/ldso/ldso.c
===
--- ldso/ldso/ldso.c(revision 24035)
+++ ldso/ldso/ldso.c(working copy)
@@ -842,6 +842,27 @@
_dl_protect_relro (tpnt);
}
+ if (!was_tls_init_tp_called _dl_tls_max_dtv_idx 0)
+ ++_dl_tls_generation;
+
+ _dl_debug_early(Calling _dl_allocate_tls_init()!\n);
+
+ /* Now that we have completed relocation, the initializer data
+ for the TLS blocks has its final values and we can copy them
+ into the main thread's TLS area, which we allocated above. */
+ _dl_allocate_tls_init (tcbp);
+
+ /* And finally install it for the main thread. If ld.so
Re: NPTL branch almost merged with trunk @ rev 22714
Bernhard Reutner-Fischer wrote: On Sun, Jul 13, 2008 at 09:08:01AM +0200, Carmelo Amoroso wrote: Denys Vlasenko wrote: On Wednesday 09 July 2008 18:59, Carmelo AMOROSO wrote: Hi Steve, Khem, Mike, all ... well just an update on the NPTL branch synchmerge work. Seeing you doing all this, I really hesitate to do libc_hidden_proto removal before you merge nptl branch to trunk - it (removal) will touch almost every .c and .h file! So I will wait ~three weeks for the merge to complete. Ok Denys, thanks a lot... this will reduce my ffort in merge all these files. BTW, will there be a new uclibc release just before the merge? ;) ;) ;) definitely yes. Carmelo, could you please sync the NPTL branch against current trunk to bring the branch back up to date? This would make reviewing the NPTL branch alot more feasable.. TIA and cheers, Hi Bernhard, I'm going to complete some higher priority work on kernel side and then start immediately with uclibc again. I've also an important fix for nptl branch discovered while running firefox 3 on uclibc-nptl/sh4. Hopefully I'll restart the uclibc work next Monday at full time. Sorry for the delay. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [RFC] Fix various compiler warning
Hans-Christian Egtvedt wrote: On Mon, 3 Nov 2008 17:35:47 -0500 Rob Landley [EMAIL PROTECTED] wrote: [SNIP] There are more defines to be cleaned up I think, places where #if is used when I think it should really have been #ifdef. It depends on how this is used. In a simple case just changing #if to #ifdef is correct and enough, in other case it should be done as: #if defined XXX XXX if we want also check that XXX is not defined 0 but this depends on how the macro is used and its meaning. Cheers, Carmelo [SNIP] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr __tls_get_addr)
Rob Landley wrote: On Monday 27 October 2008 12:50:13 Carmelo AMOROSO wrote: Sorry for having confused with multiple patches/proposal and emails. Currently the dl_iterate_phdr symbols is defined in ld-uClibc.so.0 and libdl.a. The idea is to move into libc.so.0 and libc.a (exactly as glibc does). Well, that sounds like a good thing all by itself. Why is uClibc defining it in a different place than glibc does right now? I don't know... it was as is since the beginning. (And why don't more programs break due to that?) dynamically linked program will always find it in the ld.so (always available). For one thing, a statically linked program would never get dl_iterate_phdr right now, right? Yes, infact I discovered the problem while statically linking a C++ application. (What does that symbol _do_, anyway? Is there some documentation I should read up on somewhere?) man dl_iterate_phdr it can say something much more and better than me ;-) Carmelo Rob Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [ANNOUNCE] uClibc-0.9.30-rc3 released
Kevin Day wrote:
On Tue, Oct 28, 2008 at 3:31 PM, Bernhard Reutner-Fischer
[EMAIL PROTECTED] wrote:
Hi,
uClibc-0.9.30-rc3 is out of the door. Please refer to
$ svn log -r23683:23835 svn://uClibc.org/trunk/uClibc
for the ChangeLog between the -rc2 and -rc3.
The tarballs can be downloaded -- as usual -- from http://uClibc.org/
The final release of 0.9.30 is (still) scheduled for \end of October\
so please test this release candidate thoroughly, _now_.
Thanks to everybody who fixed or reported bugs.
___
Is there a reason the following:
http://uclibc.org/lists/uclibc/2008-May/019349.html
was not fixed in this version?
may be lack of time for reviewing and testing ?
I seem to remember a cleaned up version of my fix being applied.
I don't think so... but I may be wrong.
Cheers,
Carmelo
This patch was done on 0.9.28.3, but the 0.9.30-rc3 seems to still be
using the old way:
diff -r -u uClibc-0.9.28.3.orig/ldso/libdl/libdl.c
uClibc-0.9.28.3/ldso/libdl/libdl.c
--- uClibc-0.9.28.3.orig/ldso/libdl/libdl.c 2008-05-15 17:23:49 -0500
+++ uClibc-0.9.28.3/ldso/libdl/libdl.c 2008-05-15 17:26:41 -0500
@@ -132,7 +132,10 @@
void dl_cleanup(void)
{
struct dyn_elf *d;
- for (d = _dl_handles; d; d = d-next_handle) {
+ struct dyn_elf *n;
+
+ for (d = _dl_handles; d; d = n) {
+ n = d-next_handle;
do_dlclose(d, 1);
}
}
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] __syscall_rt_sigaction should use kernel_sigaction
Carmelo AMOROSO wrote: Hi, __syscall_rt_sigaction should accept kernel_sigaction instead on sigaction, as declared into the bit/kernel_sigaction.h header. Indeed, each libc function that invoke it, are passing a kernel_sigaction pointer. Attached patch tries to fix it. Cheers, Carmelo what about this change ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uClibc system call to get stack trace information
ganesh sahu wrote: Hi Does uClibc is having an system call to get stack information. In glibc we can print the stack trace through backtrace() function but it doesn't work in uClibc. So how we can get stack trace information inside our C code using uClibc. Thanks Ganesh Backtrace function is not implemented. You may use gdb. Cheers, Carmelo Did you know? You can CHAT without downloading messenger. Click here http://in.rd.yahoo.com/tagline_webmessenger_2/*http://in.webmessenger.yahoo.com/ ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: How goes the -rc2 todo list?
Rob Landley wrote: On Saturday 11 October 2008 04:00:07 Bernhard Reutner-Fischer wrote: On Sat, Oct 11, 2008 at 01:38:08AM -0500, Rob Landley wrote: Just wondering... Thanks to khem for testing and applying the 4994 patch. There is a depency problem in locales, i'll fix this during the weekend and then announce rc2. Cool. The arm problem I'm tracking down turned out to be a busybox issue rather than a uClibc one, so my own testing's off on a tangent right now. Nothing to report at present. :) Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc I'll test Bernhard's locale patch on Manday. I don't have a sh4 box at home. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: SH2aeb support
Kieran Bingham wrote: Hi Carmelo. Thanks for the hint, Yes SVN:Trunk does solve the memcpy build issue it would seem. fine. I have another issue I've not been able to figure out correctly. With Support global constructors and destructors turned off, uClibc doesn't seem to build crti.o and crtn.o, yet the linker still looks for them. These files get built if i turn on CTOR_DTOR but should they be built when this is switched off ? or should there be stub files created ? sh2aeb-linux-uclibc-gcc -Wl,-EB -Wl,-elf2flt=-s65536 test.c -o test /opt/sh/2a/toolchain/lib/gcc/sh2aeb-linux-uclibc/4.2.4/../../../../sh2aeb-linux-uclibc/bin/ld.real: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[1]: *** [test] Error 1 make[1]: Leaving directory `/opt/sh/2a/build/src/test-apps-0.1' make: *** [build] Error 2 Which is the target file format used to build uclibc. I'm not so aware of not elf format... if I guess correctly sh2a doesn't use elf format (as from -Wl,-elf2flt). If I build with Support global constructors and destructors turned on, then I get linker errors as follows: test.elf2flt: In function `__uClibc_fini': (.text+0x908): undefined reference to `__fini_array_start' test.elf2flt: In function `__uClibc_fini': (.text+0x90c): undefined reference to `__fini_array_end' test.elf2flt: In function `__uClibc_main': (.text+0xa54): undefined reference to `__preinit_array_end' test.elf2flt: In function `__uClibc_main': (.text+0xa60): undefined reference to `__preinit_array_start' test.elf2flt: In function `__uClibc_main': (.text+0xa64): undefined reference to `__init_array_start' test.elf2flt: In function `__uClibc_main': (.text+0xa68): undefined reference to `__init_array_end' If __UCLIBC_FORMAT_SHARED_FLAT__ is not defined, these symbols should not be referenced from __uClibc_fini. Are you sure uclibc has been properly configured ? Sorry if cannot help more on this. Cheers, Carmelo I've got round this so far by turning it on to build the files, then off to create something that links successfully, but I can't figure out how to get the crt[ni].o to build otherwise :( -- Cheers Kieran 2008/10/6 Carmelo Amoroso [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Kieran Bingham wrote: Hi Guys, I'm currently trying to build uClibc-0.9.30-rc1 for SH2aeb and found an issue when building which I fixed with the attached patches. make[2]: Entering directory `/opt/sh/2a/build/src/test-apps-0.1' sh2aeb-linux-uclibc-gcc -Wl,-EB test.c -o test test.c: In function 'main': test.c:5: warning: return type of 'main' is not 'int' /opt/sh/2a/toolchain/usr/lib/libc.a(memcpy.o): In function `memcpy': memcpy.c:(.text+0x60): undefined reference to `WORD_COPY_FWD' collect2: ld returned 1 exit status make[2]: *** [test] Error 1 I think its the right thing to do - i.e. follow the SH4, and define ARCH_HAS_BWD, but then I had to copy the include from memmove to memcpy which I don't think is a particularly nice way to do this. Why is it currently including a .c file in this way? -- Cheers Kieran Bingham i, it should be already fized in rev 23572. Please try with this and let us know. Carmelo ___ uClibc mailing list uClibc@uclibc.org mailto:uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: SH2aeb support
Kieran Bingham wrote: Hi Guys, I'm currently trying to build uClibc-0.9.30-rc1 for SH2aeb and found an issue when building which I fixed with the attached patches. make[2]: Entering directory `/opt/sh/2a/build/src/test-apps-0.1' sh2aeb-linux-uclibc-gcc -Wl,-EB test.c -o test test.c: In function 'main': test.c:5: warning: return type of 'main' is not 'int' /opt/sh/2a/toolchain/usr/lib/libc.a(memcpy.o): In function `memcpy': memcpy.c:(.text+0x60): undefined reference to `WORD_COPY_FWD' collect2: ld returned 1 exit status make[2]: *** [test] Error 1 I think its the right thing to do - i.e. follow the SH4, and define ARCH_HAS_BWD, but then I had to copy the include from memmove to memcpy which I don't think is a particularly nice way to do this. Why is it currently including a .c file in this way? -- Cheers Kieran Bingham i, it should be already fized in rev 23572. Please try with this and let us know. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_fadvise for ppc32
Corinna Schultz wrote:
These changes are based on the glibc code that handles ppc32. This
probably shouldn't be in the common dir, but I am unfamiliar with how
to add code into the arch-specific dir. I am also unsure about the
proper symbol to use in the #ifdef; however, this patch worked for us.
It was tested on ia32, and ppc32, and all LTP tests passed. I should
note, that our ppc machine has INTERNAL_SYSCALL defined, so I don't
believe the other code paths were tested.
Suggestions for improvements are welcome.
-Corinna Schultz
IBM LTC
Hi Corinna,
usually arch specific implementation will go in separate directory.
We prefer avoid, whenever possible, adding multiple ifdef inside common code.
May you kindly post the complete file for powerpc, so we can put it in the
right place.
TIA,
Carmelo
This patch fixes posix_fadvise[64] function for ppc32, to send
arguments of the proper size and in the proper order.
Signed-off-by: Corinna Schultz [EMAIL PROTECTED]
diff -ruN orig/posix_fadvise64.c new/posix_fadvise64.c
--- uClibc.orig/libc/sysdeps/linux/common/posix_fadvise64.c
2008-10-03 13:08:21.589048507 -0500
+++ uClibc.new/libc/sysdeps/linux/common/posix_fadvise64.c
2008-10-03 13:11:52.697012758 -0500
@@ -56,30 +56,48 @@
/* 32 bit implementation is kind of a pita */
#elif __WORDSIZE == 32
-#if defined INTERNAL_SYSCALL ! defined __TARGET_powerpc__
+#if defined INTERNAL_SYSCALL
int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
{
INTERNAL_SYSCALL_DECL (err);
+#ifdef __powerpc__
+ int ret = INTERNAL_SYSCALL (fadvise64_64, err, 6, fd, advice,
+ __LONG_LONG_PAIR(offset 32, offset 0x),
+ __LONG_LONG_PAIR(len 32, len 0x));
+#else
int ret = INTERNAL_SYSCALL (fadvise64_64, err, 6, fd,
__LONG_LONG_PAIR(offset 32, offset 0x),
__LONG_LONG_PAIR(len 32, len 0x),
- advice);
+#endif advice);
if (!INTERNAL_SYSCALL_ERROR_P (ret, err))
return 0;
return INTERNAL_SYSCALL_ERRNO (ret, err);
}
#elif defined _syscall6 /* workaround until everyone has _syscall6() */
#define __NR___syscall_fadvise64_64 __NR_fadvise64_64
+
+#ifdef __powerpc__
+static __inline__ _syscall6(int, __syscall_fadvise64_64, int, fd,
+ int, advice, unsigned long, high_offset, unsigned long, low_offset,
+ unsigned long, high_len, unsigned long, low_len);
+#else
static __inline__ _syscall6(int, __syscall_fadvise64_64, int, fd,
unsigned long, high_offset, unsigned long, low_offset,
unsigned long, high_len, unsigned long, low_len,
int, advice);
+#endif
int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
{
+#ifdef __powerpc__
+ int ret = __syscall_fadvise64_64(fd, advice,
+ __LONG_LONG_PAIR(offset 32, offset 0x),
+ __LONG_LONG_PAIR(len 32, len 0x));
+#else
int ret = __syscall_fadvise64_64(fd,
__LONG_LONG_PAIR(offset 32, offset 0x),
__LONG_LONG_PAIR(len 32, len 0x),
advice);
+#endif
if (ret == -1)
return errno;
return ret;
diff -ruN orig/posix_fadvise.c new/posix_fadvise.c
--- uClibc.orig/libc/sysdeps/linux/common/posix_fadvise.c
2008-10-03 13:15:54.991477654 -0500
+++ uClibc.new/libc/sysdeps/linux/common/posix_fadvise.c
2008-10-03 13:15:32.929049499 -0500
@@ -26,21 +26,37 @@
int posix_fadvise(int fd, off_t offset, off_t len, int advice)
{
INTERNAL_SYSCALL_DECL(err);
+#ifdef __powerpc__
+int ret = (int) (INTERNAL_SYSCALL(posix_fadvise, err, 6, fd, 0,
+__LONG_LONG_PAIR (offset 31, offset), len, advice));
+#else
int ret = (int) (INTERNAL_SYSCALL(posix_fadvise, err, 5, fd,
__LONG_LONG_PAIR (offset 31, offset), len, advice));
+#endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
}
#else
-static __inline__ int syscall_posix_fadvise(int fd, off_t offset1,
off_t offset2, off_t len, int advice);
#define __NR_syscall_posix_fadvise __NR_fadvise64
++
++#ifdef __powerpc__
++static __inline__ int syscall_posix_fadvise(int fd, int unused,
off_t offset1, off_t offset2, off_t len, int advice);
++_syscall6(int, syscall_posix_fadvise, int, fd, int, unused, off_t, offset1,
++ off_t, offset2, off_t, len, int, advice);
++#else
++static __inline__ int syscall_posix_fadvise(int fd, off_t offset1,
off_t offset2, off_t len, int advice);
Re: in function 'memcpy': undefined reference to `WORD_COPY_FWD'
Bernhard Reutner-Fischer wrote: On Tue, Sep 30, 2008 at 11:29:46PM -0500, Rob Landley wrote: libc/libc_so.a(memcpy.os): In function `memcpy': memcpy.c:(.text+0x6e): undefined reference to `WORD_COPY_FWD' likely something I broke with a recent commit. I'll check it(but cannot test). Carmelo I see this too on i386 with $ grep STRING FAILED.6.config UCLIBC_HAS_STRING_GENERIC_OPT=y # UCLIBC_HAS_STRING_ARCH_OPT is not set Which I'll worry about in the morning, I guess... great. TIA, PS: see extra/scripts/randconfig.sh for a little script that produces failing configs for your favourite arch. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: in function 'memcpy': undefined reference to `WORD_COPY_FWD'
Carmelo AMOROSO wrote: Bernhard Reutner-Fischer wrote: On Tue, Sep 30, 2008 at 11:29:46PM -0500, Rob Landley wrote: libc/libc_so.a(memcpy.os): In function `memcpy': memcpy.c:(.text+0x6e): undefined reference to `WORD_COPY_FWD' likely something I broke with a recent commit. I'll check it(but cannot test). Carmelo I reproduced it with the following combination UCLIBC_HAS_STRING_GENERIC_OPT=y UCLIBC_HAS_STRING_ARCH_OPT is not set while setting UCLIBC_HAS_STRING_ARCH_OPT=y it works. Yes, I suspect it was a my fault. Carmelo I see this too on i386 with $ grep STRING FAILED.6.config UCLIBC_HAS_STRING_GENERIC_OPT=y # UCLIBC_HAS_STRING_ARCH_OPT is not set Which I'll worry about in the morning, I guess... great. TIA, PS: see extra/scripts/randconfig.sh for a little script that produces failing configs for your favourite arch. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] all arches: c89 touchup
Bernhard Reutner-Fischer wrote: Hi, To be gentle to c89 bootstrap-compilers the attached patch does basically s/\/\/\(.*\)/\/*\1 *\//g The corresponding issue is http://bugs.uclibc.org/view.php?id=5194 The reporter sees this with gcc-4.2.4 without passing -std=c89 to the compiler (i.e. uses the defaults) and as such i find it a bit odd that the preprocessor rejects it. Still, it may be handy if one is able to bootstrap the libc with a compiler that is in C89 mode. Are there objections from the arch maintainers against the attached change? libm/e_lgamma.c|2 libm/e_gamma.c |2 libm/e_gamma_r.c |2 include/fcntl.h|2 include/libc-symbols.h |2 utils/ldd.c|8 ldso/ldso/arm/dl-startup.h |2 ldso/ldso/powerpc/resolve.S| 14 - libc/inet/rpc/rpc_thread.c |2 libc/string/ia64/memcmp.S | 88 +++--- libc/string/ia64/bzero.S | 130 - libc/string/ia64/strcpy.S | 64 ++-- libc/string/ia64/strncmp.S |6 libc/string/ia64/memcpy.S | 158 +-- libc/string/ia64/memset.S | 174 ++--- libc/string/ia64/memccpy.S | 102 +++ libc/string/ia64/strncpy.S | 90 +++--- libc/string/ia64/memmove.S | 160 +-- libc/string/ia64/strchr.S | 32 +- libc/string/ia64/strlen.S | 18 - libc/string/ia64/strcmp.S |2 libc/string/ia64/memchr.S | 32 +- libc/string/sh64/strcpy.S | 28 +- libc/string/sh64/memcpy.S |2 libc/string/sh64/memset.S | 28 +- libc/string/generic/strtok_r.c |8 libc/string/xtensa/strncpy.S | 144 +- libc/string/xtensa/strcpy.S| 72 ++--- libc/string/xtensa/strlen.S| 58 ++-- libc/string/xtensa/strcmp.S| 148 +-- libc/string/xtensa/memcpy.S| 22 - libc/string/xtensa/memset.S| 10 libc/string/bfin/strcmp.S | 80 ++--- libc/string/bfin/memchr.S |4 libc/sysdeps/linux/microblaze/__longjmp.S |6 libc/sysdeps/linux/microblaze/vfork.S | 10 libc/sysdeps/linux/microblaze/crt0.S | 18 - libc/sysdeps/linux/common/bits/uClibc_errno.h |2 libc/sysdeps/linux/common/llseek.c |2 libc/sysdeps/linux/v850/__longjmp.S|2 libc/sysdeps/linux/v850/vfork.S|6 libc/sysdeps/linux/v850/crt0.S | 20 - libc/sysdeps/linux/xtensa/vfork.S | 28 +- libc/sysdeps/linux/xtensa/setjmp.S |2 libc/sysdeps/linux/xtensa/__longjmp.S |6 libc/sysdeps/linux/xtensa/windowspill.S| 26 - libc/sysdeps/linux/ia64/setjmp.S | 44 +-- libc/sysdeps/linux/ia64/__longjmp.S| 74 ++--- libc/sysdeps/linux/e1/crt1.c |2 libc/sysdeps/linux/nios/bits/endian.h |2 libc/sysdeps/linux/nios/crt1.S |4 libc/sysdeps/linux/sparc/qp_ops.c |2 libc/sysdeps/linux/sh/vfork.S | 12 libc/sysdeps/linux/sh/clone.S |6 libc/sysdeps/linux/bfin/__longjmp.S| 26 - libc/sysdeps/linux/bfin/bsd-_setjmp.S | 22 - libc/misc/internals/tempname.c |2 libpthread/linuxthreads.old/forward.c |4 libpthread/linuxthreads.old/pthread.c |4 libpthread/linuxthreads/pthread.c |4 libpthread/linuxthreads/sysdeps/unix/sysv/linux/sh/vfork.S |4 61 files changed, 1018 insertions(+), 1018 deletions(-) PS: yes, i do not fancy such
[PATCH] __syscall_rt_sigaction should use kernel_sigaction
Hi, __syscall_rt_sigaction should accept kernel_sigaction instead on sigaction, as declared into the bit/kernel_sigaction.h header. Indeed, each libc function that invoke it, are passing a kernel_sigaction pointer. Attached patch tries to fix it. Cheers, Carmelo Index: libc/sysdeps/linux/common/__syscall_rt_sigaction.c === --- libc/sysdeps/linux/common/__syscall_rt_sigaction.c (revision 23479) +++ libc/sysdeps/linux/common/__syscall_rt_sigaction.c (working copy) @@ -11,10 +11,10 @@ #ifdef __NR_rt_sigaction #include signal.h +#include bits/kernel_sigaction.h -int __syscall_rt_sigaction (int __signum, const struct sigaction *__act, struct sigaction *__oldact, size_t __size) attribute_hidden; #define __NR___syscall_rt_sigaction __NR_rt_sigaction _syscall4(int, __syscall_rt_sigaction, int, signum, - const struct sigaction *, act, struct sigaction *, oldact, + const struct kernel_sigaction *, act, struct kernel_sigaction *, oldact, size_t, size); #endif ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Corinna Schultz wrote: Quoting Carmelo AMOROSO [EMAIL PROTECTED]: Does anybody (other than sh4) tried posix_fadvise tests? Carmelo, I was finally able to test this today. The tests are still failing for me (I'm on ppc32), though for different reasons than before :-) . I have not tried the ppc workaround patch yet, though. I'll let you know. The work-around is just for fixing build problem on powerpc. I suppose that powerpc might need an ad hoc implementation. Indeed glibc has these two files sysdeps/unix/sysv/linux/powerpc/powerpc32/posix_fadvise.c sysdeps/unix/sysv/linux/powerpc/powerpc32/posix_fadvise64.c So, you may be able to port glibc implementation and adapt to uclibc and post a patch for inclusion. Sorry, but I cannot do more on powerpc. Cheersm Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Paul Mundt wrote: On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote: Index: libc/sysdeps/linux/sh/bits/syscalls.h === --- libc/sysdeps/linux/sh/bits/syscalls.h(revision 23401) +++ libc/sysdeps/linux/sh/bits/syscalls.h(working copy) @@ -140,6 +140,151 @@ __syscall_return(type,__sc0); \ } +#define SYSCALL_INST_STR0 trapa #0x10\n\t +#define SYSCALL_INST_STR1 trapa #0x11\n\t +#define SYSCALL_INST_STR2 trapa #0x12\n\t +#define SYSCALL_INST_STR3 trapa #0x13\n\t +#define SYSCALL_INST_STR4 trapa #0x14\n\t +#define SYSCALL_INST_STR5 trapa #0x15\n\t +#define SYSCALL_INST_STR6 trapa #0x16\n\t + This breaks SH-2/SH-2A, you should be using __SH_SYSCALL_TRAP_BASE here. Hi Paul, it was taken from a sysdep.h in nptl path, that probably doesn't care of SH-2[A]. I'll fit it immediately. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] sh: fix SYSCALL_INST_STR macros for SH-2[A] arch.
Hi Paul, please find attached a patch to make SYSCALL_INST_STR macros working on SH2 too. I've built trunk for sh4 and objdumped some object using INLINE_SYSCALL, and it looks fine. Let me know, so I can commit. Carmelo Index: libc/sysdeps/linux/sh/bits/syscalls.h === --- libc/sysdeps/linux/sh/bits/syscalls.h (revision 23456) +++ libc/sysdeps/linux/sh/bits/syscalls.h (working copy) @@ -140,14 +140,19 @@ __syscall_return(type,__sc0); \ } -#define SYSCALL_INST_STR0 trapa #0x10\n\t -#define SYSCALL_INST_STR1 trapa #0x11\n\t -#define SYSCALL_INST_STR2 trapa #0x12\n\t -#define SYSCALL_INST_STR3 trapa #0x13\n\t -#define SYSCALL_INST_STR4 trapa #0x14\n\t -#define SYSCALL_INST_STR5 trapa #0x15\n\t -#define SYSCALL_INST_STR6 trapa #0x16\n\t +/* Two level macros for expansion and stringification */ +#define xstr(s)str(s) +#define str(s) #s +#define SYSCALL_INST_STR(x)trapa #xstr(__SH_SYSCALL_TRAP_BASE + x)\n\t +#define SYSCALL_INST_STR0 SYSCALL_INST_STR(0) +#define SYSCALL_INST_STR1 SYSCALL_INST_STR(1) +#define SYSCALL_INST_STR2 SYSCALL_INST_STR(2) +#define SYSCALL_INST_STR3 SYSCALL_INST_STR(3) +#define SYSCALL_INST_STR4 SYSCALL_INST_STR(4) +#define SYSCALL_INST_STR5 SYSCALL_INST_STR(5) +#define SYSCALL_INST_STR6 SYSCALL_INST_STR(6) + # ifdef NEED_SYSCALL_INST_PAD # define SYSCALL_INST_PAD \ or r0,r0; or r0,r0; or r0,r0; or r0,r0; or r0,r0 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix SYSCALL_INST_STR macros for SH-2[A] arch.
Bernhard Reutner-Fischer wrote: On Wed, Sep 24, 2008 at 10:53:59PM +0900, Paul Mundt wrote: uClibc has no equivalent of __stringify()? This should probably be in a generic header somewhere. Agree. We only have STRINGIFY in libpthread internals. Moving to libc-symbols.h (alway included) sounds reasonable? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: libdl usage count wrapping
I'll look at these two issues soon.
Thanks,
Carmelo
Vallevand, Mark K wrote:
Wow. I just ran into this problem. Or, something very similar. I
reported a memory leak in dlopen() dlclose() last week. I've got a fix
for that problem, and my program doesn't leak any more. But, now its
crashing consistently after a period of time. The program makes heavy
use of dlopen() dlclose().
Looking at dlopen() dlclose(), I'm probably not going to look for
another fix there. I'm going to fix my program to dlopen() once and
leave libraries open.
Regards.
Mark K Vallevand
We old folks have to find our cushions and pillows in our tankards.
Strong beer is the milk of the old.
- Martin Luther
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Phil Estes
Sent: Monday, September 22, 2008 9:45 PM
To: uclibc@uclibc.org
Subject: libdl usage count wrapping
Recently I was looking into an issue where someone was claiming pam was
segfaulting after a lot of usage (lots of calls to authenticate
users--usually around 5K calls). My investigation led me to the point
where I realized that the dlopen() and dlclose() management of ref.
counting is not balanced, which leads to the heaviest DL_NEEDED
libraries basically getting incremented to the point of overflowing
unsigned short usage_count. This leads to a nasty situation where
libc.so is munmapped (because usage_count == 0), and the next call to a
C runtime function traps, of course.
Since I was working with 0.9.29 snapshot from 2006, I decided to see if
anything in SVN has changed that might impact this. I was interested to
find the 17530 changeset and accompanying discussion
( http://uclibc.org/lists/uclibc/2007-January/017165.html ) and while
testing it, noted a 10x improvement, given that more of the dependent
libs are added to the list that is walked at do_dlclose that includes a
decrement of usage_count. However, it is still not exact in that
libc.so's usage_count continues to rise even with matching dlopen() and
dlclose() calls each iteration through the example program (I'll attach
below), and now needs 65K iterations of loading/unloading a lib to get a
segfault.
One way to 'watch' this in gdb is to add a breakpoint in libdl.c around
line 247 or so and use the commands interface to do the following
output:
commands brnum
silent
printf %d : %s\n,(*tpnt1)-usage_count, lpntstr
cont
end
Now continue and watch libc's usage_count climb, and if you are patient
enough, you will get a segfault somewhere after 65,500 iterations.
Obviously one potential fix is to handle the wrap of usage_count in
ldso/dl-elf.c by checking for 0 after the increment and setting to near
max ..which would then never allow a wrap to zero to occur which causes
the segfault.
However, it would be interesting to know if the uClibc maintainers think
usage_count is important enough for some of the core libs to either (a)
be correct, or (b) be protected from the segfault condition which is
less likely than it used to be given the aforementioned changes, but
still potential for long-running apps (like pam running on a system with
a very long uptime). I'm slightly interested in trying to fix, but
given I'm no expert on all the various lists and pointers employed via
dlopen() it seems like someone with some skill in the area should make
sure it's done right. My hunch is that is has to do with the init_fini
list creation and the filtering out of RTLD_GLOBAL libs, but I'm not
sure yet without more debug...but the init_fini list seems to be what is
walked at dlclose that has any relation to decrementing usage_count.
Thanks for any thoughts/input,
Phil Estes
[EMAIL PROTECTED]
Here's my example program for creating the segfault condition..it can
obviously be doctored to load different libs, more libs, less libs, etc.
---stress-dlopen.c
#include stdio.h
#include stdlib.h
#include dlfcn.h
#define NUMLIBS 4
#define ITERS 5
void *handles[NUMLIBS];
/*
char *names[NUMLIBS] = { /lib/security/pam_deny.so,
/lib/security/pam_warn.so,
/lib/libpam.so.0 };
*/
char *names[NUMLIBS] = { /usr/lib/libxml2.so.2,
/usr/lib/libpcap.so,
/usr/lib/libpng.so.2,
/usr/lib/libxslt.so.1 };
int openlibs()
{
int i, errors=0;
for (i = 0; i NUMLIBS; i++) {
handles[i] = dlopen(names[i], RTLD_NOW);
if (handles[i] == 0) {
errors++;
fprintf(stderr, %s\n, dlerror());
}
}
return errors;
}
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Fathi Boudra wrote: On Thu, Sep 18, 2008 at 5:05 PM, Carmelo AMOROSO [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Bernhard Reutner-Fischer wrote: On Thu, Sep 18, 2008 at 03:29:09PM +0200, Carmelo AMOROSO wrote: Absolutely agreed. IIRC I should now use __inline__ keyword, right? yes. Merged. Thanks for review ;-) fails to build on my config. LD libuClibc-0.9.29.so http://libuClibc-0.9.29.so libc/libc_so.a(posix_fadvise64.os): In function `posix_fadvise64': posix_fadvise64.c:(.text+0x18): undefined reference to `__illegally_sized_syscall_arg2' posix_fadvise64.c:(.text+0x1c): undefined reference to `__illegally_sized_syscall_arg3' posix_fadvise64.c:(.text+0x20): undefined reference to `__illegally_sized_syscall_arg4' posix_fadvise64.c:(.text+0x24): undefined reference to `__illegally_sized_syscall_arg5' collect2: ld returned 1 exit status make[1]: *** [lib/libc.so] Error 1 arch ? compiler ? anyway I've seen similar post ... not related to posix_fadvise. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Fathi Boudra wrote: fails to build on my config. LD libuClibc-0.9.29.so http://libuClibc-0.9.29.so http://libuClibc-0.9.29.so libc/libc_so.a(posix_fadvise64.os): In function `posix_fadvise64': posix_fadvise64.c:(.text+0x18): undefined reference to `__illegally_sized_syscall_arg2' posix_fadvise64.c:(.text+0x1c): undefined reference to `__illegally_sized_syscall_arg3' posix_fadvise64.c:(.text+0x20): undefined reference to `__illegally_sized_syscall_arg4' posix_fadvise64.c:(.text+0x24): undefined reference to `__illegally_sized_syscall_arg5' collect2: ld returned 1 exit status make[1]: *** [lib/libc.so] Error 1 arch ? compiler ? anyway I've seen similar post ... not related to posix_fadvise. uclibc trunk/powerpc/gcc-4.2.4 under buildroot r23434. same configuration before posix_fadvise commit works. powerpc needs a specific implementation because it expects 8 bytes long variable. Look recent messages, as I said, regarding pread_wirte implementation. May we add a work-around for powerpc, otherwise, if you can, please post a patch for implementing specific powerpc function. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: uclibc 5 problem : system( ) call from user space creates system hang up
yogesh marathe wrote:
I'm trying to execute system( ) call (the one from stdlib.h) in an
application that requires uclibc5 and pthread lib both. System hangs up
when i do so.
Please help me out. Issue is resolves when I do not use pthread library.
Same function is working with uclibc4 with pthread library.
what is uclibc4 or uclibc5 ?
I tried
#includestdlib.h
.
.
.
int main()
{
.
.
system(pwd);
.
return 0;
}
.
.
.
in my application.
Regards,
Yogesh.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Carmelo AMOROSO wrote: Khem Raj wrote: On Mon, Sep 15, 2008 at 4:55 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: Corinna Schultz wrote: Quoting Carmelo AMOROSO [EMAIL PROTECTED]: a colleague of mine is right now working to produce a patch for posix_fadvise to fix all LTP tests using posix_fadvise[64]. Indeed LTP tests expect that, when posix_fadvise[64] fails, it should return as return value an error code (-errno) instead of simply setting properly errno and returning -1. Did you see my earlier message, detailing the errors I'm seeing? I have very little experience with this low-level programming, and don't really know how to begin fixing it, so if you have people already working on it, I'll happily wait for your patch. :) Do you have an estimate of when your patch will be available? -Corinna Hi Corinna, may you try the attached patch. It worked fine for NPTL branch solving all LTP posix_fadvise tests. Let me know, so we can enqueue for commit. Thanks to Filippo for having fixed this. It needs to to be tested on all arches which use common/posix_fadvise* implementation. Thanks -Khem Well, waiting fro feedback from other archs... I did it on sh4 ;-) Carmelo Does anybody (other than sh4) tried posix_fadvise tests? Attached you can find the log of LTP running on sh4 target with/without the fix. As you can see, all LTP tests for posix_fadvise now pass. Being quite confident in the correctness of the patch, unless someone else will have problem, I'll commit it. TIA, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc INFO: creating /usr/ltp/output directory INFO: no command files were provided, using default, system calls, memory management, IPC, scheduler direct io, file system, math and pty tests will now be executed If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. STMicroelectronics Base Distribution 2.3 Linux amorosoc 2.6.23.17_stm23_0116-mb442 #1 PREEMPT Mon Sep 15 14:37:32 CEST 2008 sh4 unknown unknown GNU/Linux Gnu C gcc (GCC) 4.2.3 (snapshot) (STMicroelectronics/Linux Base 4.2.3-43) Gnu make 3.81 util-linux 2.12r mount 2.12r modutils 3.1 e2fsprogs 1.39 PPP2.4.4b1 Linux C Library0.9.30rc2 Linux C Library0.9.30rc2 Linux C++ Library 6.0.9 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 Modules Loaded free reports: total used free sharedbuffers cached Mem: 60692 17080 43612 0 0 9740 -/+ buffers/cache: 7340 53352 Swap:0 0 0 /proc/cpuinfo machine : STb7100 Reference board processor : 0 cpu family : sh4 cpu type: STb7100 cut : 2.x cpu flags : fpu cache type : split (harvard) icache size : 16KiB (2-way) dcache size : 32KiB (2-way) bogomips: 262.14 test_start tag=posix_fadvise01 stime=946685502 cmdline= posix_fadvise01 contacts= analysis=exit initiation_status=ok test_output posix_fadvise011 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 0 - expected 0 posix_fadvise012 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 2 - expected 0 posix_fadvise013 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 1 - expected 0 posix_fadvise014 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 5 - expected 0 posix_fadvise015 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 3 - expected 0 posix_fadvise016 FAIL : unexpected returnd value - -1 : Unknown error -1, advise 4 - expected 0 execution_status duration=0 termination_type=exited termination_id=1 corefile=no cutime=0 cstime=3 test_end test_start tag=posix_fadvise01_64 stime=946685502 cmdline= posix_fadvise01_64 contacts= analysis=exit initiation_status=ok test_output posix_fadvise011 PASS : call succeeded expectedly posix_fadvise012 PASS : call succeeded expectedly posix_fadvise013 PASS : call succeeded expectedly posix_fadvise014 PASS : call succeeded expectedly posix_fadvise015 PASS : call succeeded expectedly posix_fadvise016 PASS : call succeeded expectedly execution_status duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=3 test_end test_start tag=posix_fadvise02 stime=946685502 cmdline= posix_fadvise02 contacts= analysis=exit initiation_status=ok test_output posix_fadvise021 FAIL : unexpected returnd value - -1 : Unknown error -1 - expected 9 posix_fadvise022 FAIL
Re: [PATCH] Xtensa strcoll problem with LOCALE support
Chris Zankel wrote: Hi Carmelo, Sorry, I also forgot to add the 'signed-off' line. Looking at the log file, however, it seems that less than 5% of the commits are 'signed-off'. What's the policy? I'm used to sign-off my work being this a common/required policy on kernel side. I think generally in the open source world it should be add. Just a way to take responsibility for change and also recognition for contribution to the community. I wanted just remember this for the next time. uclibc community is not so sever in policy as glibc ;-). Carmelo Thanks, -Chris Carmelo AMOROSO wrote: Bob Wilson wrote: Carmelo AMOROSO wrote: Hi Bob, I don't see any problems in committing this on behalf of you, but proper signed-off-by should be added to these set of patches, as a general rule of thumbs. Possibly Acked-by Xtensa Maintainer (Chris Zankel) It looks like Chris already committed them, but thanks for offering. Yes he did. I've sent this message a lot before, but due to mail server problems, this has been received jjust few minutes ago. :-) I'll be sure to add a signed-off-by line in the future. Thanks, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Bernhard Reutner-Fischer wrote:
On Mon, Sep 15, 2008 at 01:55:56PM +0200, Carmelo AMOROSO wrote:
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64].
Indeed LTP tests expect that, when posix_fadvise[64] fails,
it should return as return value an error code (-errno) instead
of simply setting properly errno and returning -1.
Did you see my earlier message, detailing the errors I'm seeing? I have
very little experience with this low-level programming, and don't
really know how to begin fixing it, so if you have people already
working on it, I'll happily wait for your patch. :) Do you have an
estimate of when your patch will be available?
-Corinna
Hi Corinna, may you try the attached patch.
It worked fine for NPTL branch solving all LTP posix_fadvise tests.
Let me know, so we can enqueue for commit.
Thanks to Filippo for having fixed this.
Cheers,
Carmelo
This patch fixes posix_fadvise[64] function to return the
error number in case of failure instead of -1 and setting errno,
according to SuSv3 (IEEE Std 1003.1 2004 edition) specification.
Add INTERNAL_SYSCALL macros to libc/sysdeps/linux/sh/bits/syscalls.h
to align sh to other archs.
Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED]
Reviewed-by: Carmelo Amoroso [EMAIL PROTECTED]
Index: libc/sysdeps/linux/common/posix_fadvise64.c
===
--- libc/sysdeps/linux/common/posix_fadvise64.c (revision 23401)
+++ libc/sysdeps/linux/common/posix_fadvise64.c (working copy)
@@ -40,14 +40,35 @@
return INTERNAL_SYSCALL_ERRNO (ret, err);
}
#else
-_syscall4(int, posix_fadvise64, int, fd, __off64_t, offset,
+static int syscall_posix_fadvise(int fd, off_t offset1, off_t offset2,
off_t len, int advice);
+#define __NR_syscall_posix_fadvise64 __NR_posix_fadvise64
+_syscall4(int, syscall_posix_fadvise64, int, fd, __off64_t, offset,
I would have said static inline, like most of the rest does. Doesn't
matter though (but we should sync them up to one scheme, i guess).
Absolutely agreed. IIRC I should now use __inline__ keyword, right?
__off64_t, len, int, advice);
+int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
+{
+int ret = syscall_posix_fadvise64(fd, offset, len, advice);
+if (ret == -1)
+return errno;
+return ret;
+}
#endif
/* 32 bit implementation is kind of a pita */
#elif __WORDSIZE == 32
-#ifdef _syscall6 /* workaround until everyone has _syscall6() */
+#ifndef INTERNAL_SYSCALL
+int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
+{
+INTERNAL_SYSCALL_DECL (err);
+int ret = INTERNAL_SYSCALL (fadvise64_64, err, 6, fd,
Not sure.
#ifndef INTERNAL_SYSCALL
[clip]
ret INTERNAL_SYSCALL(...)
I suppose the 'n' was not intended.
You're right. It was a temporary change for testing the other case too.
Sorry for that.
--- libc/sysdeps/linux/common/posix_fadvise.c(revision 23401)
+++ libc/sysdeps/linux/common/posix_fadvise.c(working copy)
@@ -33,8 +33,18 @@
return 0;
}
#else
-_syscall4(int, posix_fadvise, int, fd, off_t, offset,
- off_t, len, int, advice);
+static int syscall_posix_fadvise(int fd, off_t offset1, off_t offset2,
off_t len, int advice);
+#define __NR_syscall_posix_fadvise __NR_fadvise64
+_syscall5(int, syscall_posix_fadvise, int, fd, off_t, offset1,
+ off_t, offset2, off_t, len, int, advice);
+
whitespace damage above will be cought by the pre-ci hook, so i don't
need to mention it now. hm.. ;)
sorry. fixed
Please fix the CPP logic and check it in.
TIA,
Bernhard
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr __tls_get_addr)
Search in the list for similar issues. I sugegsted a work-around in the past. I've got also a complete fix for uclibc, but up to now, never committed. Carmelo P.S. Please send emails in text/plain, not html Flemming Madsen wrote: Hello First of all: Thank you for all this wonderful stuff! I am having trouble building uclibc++ with uclibc for the ARM platform. Upon linking the .so file i get the output below. It seems that the eh_globals.o and unwind-dw2-fde-glibc.o files are extracted from gcc libraries, but that they contain references to functions that are not part of uClibc (Not libc.so anyway) I have tried to enable sjlj (setjmp() longjmp()) exceptions and new thread libraries in the buildroot config but this does not seem to help. I am using gcc 4.2.4 and uClibc 0.9.29 since these were the buildroot defaults (Full .config attached) Any help on this will be very much appreciated. TIA /Flemming WRAPPER_INCLUDEDIR=-I../include ../bin/g++-uc -Wall -Wno-trigraphs -pedantic -ansi -Os -fPIC -o vector.o -c vector.cpp arm-linux-uclibc-strip -x -R .note -R .comment vector.o WRAPPER_INCLUDEDIR=-I../include ../bin/g++-uc -Wall -Wno-trigraphs -pedantic -ansi -Os -fPIC -o abi/abi.o -c abi/abi.cpp arm-linux-uclibc-strip -x -R .note -R .comment abi/abi.o arm-linux-uclibc-ar rcs libuClibc++.a algorithm.o associative_base.o bitset.o char_traits.o complex.o del_op.o del_opnt.o del_opv.o del_opvnt.o deque.o eh_alloc.o eh_globals.o exception.o fstream.o func_exception.o iomanip.o ios.o iostream.o istream.o iterator.o limits.o list.o locale.o map.o new_handler.o new_op.o new_opnt.o new_opv.o new_opvnt.o numeric.o ostream.o queue.o set.o sstream.o stack.o stdexcept.o streambuf.o string.o utility.o valarray.o vector.o abi/abi.o abi/libgcc_eh/gthr-gnat.o abi/libgcc_eh/unwind-c.o abi/libgcc_eh/unwind-dw2-fde-glibc.o abi/libgcc_eh/unwind-dw2.o abi/libgcc_eh/unwind-sjlj.o abi/libsupc/cp-demangle.o abi/libsupc/eh_arm.o abi/libsupc/eh_aux_runtime.o abi/libsupc/eh_call.o abi/libsupc/eh_catch.o abi/libsupc/eh_exception.o abi/libsupc/eh_personality.o abi/libsupc/eh_term_handler.o abi/libsupc/eh_terminate.o abi/libsupc/eh_throw.o abi/libsupc/eh_type.o abi/libsupc/eh_unex_handler.o abi/libsupc/guard.o abi/libsupc/tinfo.o abi/libsupc/tinfo2.o abi/libsupc/vec.o abi/libsupc/vterminate.o arm-linux-uclibc-ranlib libuClibc++.a arm-linux-uclibc-gcc -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,defs -nodefaultlibs -shared -Wl,-soname,libuClibc++.so.0 `echo ` -Wl,-s -o libuClibc++-0.2.2.so http://0.2.2.so algorithm.o associative_base.o bitset.o char_traits.o complex.o del_op.o del_opnt.o del_opv.o del_opvnt.o deque.o eh_alloc.o eh_globals.o exception.o fstream.o func_exception.o iomanip.o ios.o iostream.o istream.o iterator.o limits.o list.o locale.o map.o new_handler.o new_op.o new_opnt.o new_opv.o new_opvnt.o numeric.o ostream.o queue.o set.o sstream.o stack.o stdexcept.o streambuf.o string.o utility.o valarray.o vector.o abi/abi.o abi/libsupc/cp-demangle.o abi/libsupc/eh_arm.o abi/libsupc/eh_aux_runtime.o abi/libsupc/eh_call.o abi/libsupc/eh_catch.o abi/libsupc/eh_exception.o abi/libsupc/eh_personality.o abi/libsupc/eh_term_handler.o abi/libsupc/eh_terminate.o abi/libsupc/eh_throw.o abi/libsupc/eh_type.o abi/libsupc/eh_unex_handler.o abi/libsupc/guard.o abi/libsupc/tinfo.o abi/libsupc/tinfo2.o abi/libsupc/vec.o abi/libsupc/vterminate.o abi/libgcc_eh/gthr-gnat.o abi/libgcc_eh/unwind-c.o abi/libgcc_eh/unwind-dw2-fde-glibc.o abi/libgcc_eh/unwind-dw2.o abi/libgcc_eh/unwind-sjlj.o -L/opt/toolchain-stable/t26/usr/bin/../lib/gcc/arm-linux-uclibc/4.2.4/ -lc -lgcc -ldl -Wl,--as-needed -lgcc_s -Wl,--no-as-needed eh_globals.o: In function `__cxa_get_globals': eh_globals.cpp:(.text+0xc): undefined reference to `__tls_get_addr' abi/libgcc_eh/unwind-dw2-fde-glibc.o: In function `_Unwind_Find_FDE': unwind-dw2-fde-glibc.c:(.text+0x17b8): undefined reference to `dl_iterate_phdr' collect2: ld returned 1 exit status make[1]: *** [libuClibc++-0.2.2.so http://0.2.2.so] Error 1 make[1]: Leaving directory `/home/fm/amplex/embedded/arm9/rootdisk/uclibcpp/uClibc++-0.2.2/src' make: *** [all] Error ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Khem Raj wrote: On Mon, Sep 15, 2008 at 4:55 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: Corinna Schultz wrote: Quoting Carmelo AMOROSO [EMAIL PROTECTED]: a colleague of mine is right now working to produce a patch for posix_fadvise to fix all LTP tests using posix_fadvise[64]. Indeed LTP tests expect that, when posix_fadvise[64] fails, it should return as return value an error code (-errno) instead of simply setting properly errno and returning -1. Did you see my earlier message, detailing the errors I'm seeing? I have very little experience with this low-level programming, and don't really know how to begin fixing it, so if you have people already working on it, I'll happily wait for your patch. :) Do you have an estimate of when your patch will be available? -Corinna Hi Corinna, may you try the attached patch. It worked fine for NPTL branch solving all LTP posix_fadvise tests. Let me know, so we can enqueue for commit. Thanks to Filippo for having fixed this. It needs to to be tested on all arches which use common/posix_fadvise* implementation. Thanks -Khem Well, waiting fro feedback from other archs... I did it on sh4 ;-) Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Rob Landley wrote: On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. Ok. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I think we've got that part covered. What I'm thinking is that if TLS can be added to the main svn branch as a separate chunk, that's can be considered a partial merge (brings the NPTL and mainline branches somewhat closer), and it's small and separate enough to go into a 0.9.30 release. Honestly, I'd do a 0.9.30 right now without delaying further as a lot of peoples are asking for a new release since a long time. Works for me, except that I'm still doing mroe testing and I've got bugs to fix. Well, we could ship now with a -rc1. Adding bug fixes as someone have tests/fixes for them, and go ahead shortly with a -rc2, and so... in a tight loop. I do not expect to go over -rc5... just like kernel do... Since I haven't got the authority to tell people _not_ to check random changes into svn, what I may do is grab a snapshot of the svn archive, put it into a mercurial archive, call that -rc1, and then do bugfix-only changes to it until I get a 0.9.30-final. ... and after, yeah let's ship a stable 0.9.30. But let's do... don't we waste more time. We can worry about official after the release. :) We can have a branch as a development tree for adding TLS support but independently from NPTL merge... I'd like to do this after .30 release. In this way we will have already TLS for arm/mips/sh4 as part as the nptl work... and it can be used as a reference implementation. Ok. At this stage, having a separate branch for adding TLS support for other archs (which one... i386 only ?) , may be done in a separate branch or directly to the main stream. I never bother with branches in subversion. *shrug* Also, rather than have _three_ threading branches (once NPTL is added), I'd like to yank LINUXTHREADS_OLD before releasing a 0.9.30 if the newer stuff works for everybody. (And if it doesn't, I want bug reports.) I honestly have never used linuxthreads so I don't how it work. Like anything else, really. Here's a test program for threading I wrote, which passes data from one thread to another via a simple mailbox implementation using mutexes and event semaphores: http://landley.net/hg/firmware/file/tip/sources/native/src/thread-hello2.c It's basically hello world, but way complicated. IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) Remeber that, even when merged, NPTL is available only for 3 archs at the time being. Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that most people haven't been testing because they're still on LINUXTHREADS_OLD. In this case I think you're right... we should push using it. There's not much point in having two of these right now, and adding NPTL would make _three_. I'd like to keep it to no more than two, which means I need to yank one before NPTL goes in. Rob Comments are welcome. Carmelo Rob Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Will Newton wrote: On Tue, Sep 16, 2008 at 7:23 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I was under the impression that TLS support was a requirement of implementing NPTL, is that not the case? http://www.linux-mips.org/wiki/NPTL but it can live without nptl. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Bernhard Reutner-Fischer wrote: On Tue, Sep 16, 2008 at 12:28:19PM +0200, Carmelo AMOROSO wrote: Well, we could ship now with a -rc1. Adding bug fixes as someone have Consider trunk the RC. bugs.uclibc.org has quite some stuff that currently does not work and also there were reports on this very list (e.g. the glob() report) recently. Ok, let's discard the -rc release, would you like to see al bugs fixed before .30 release will get shipped? We're not exactly running out of bugs yet.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Why does uclibc.org have server problems?
Hans-Christian Egtvedt wrote: Hi, I see web is up again, but the mail server seems to be down :/ PS! This email is more or less a check to see if the mail server is back up again. Indeed I've sent some messages hours ago and my smtp server could not reach uclibc.org. Now I can see your message :-) so should it be back. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: make clean/distclean broken in svn 23359?
Rob Landley wrote:
Would anyone like to speculate why make clean and even make distclean
leave tons of .o and .so files in libm and such?
$ find . -name *.o | wc
10861086 30230
Rob
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
works fine on rev 23401
[EMAIL PROTECTED] /home/work/uClibc-work/SVN/trunk]make clean
rm -f ldso/*/*.a libpthread/*/*.a libc/*.a libcrypt/*.a libintl/*.a \
libm/*.a libnsl/*.a libpthread/*.a libresolv/*.a librt/*.a \
libutil/*.a lib/*.a \
include/fpu_control.h include/dl-osinfo.h include/hp-timing.h
make objclean-y headers_clean-y
rm -f ./ldso/ldso/*.{o,os,oS,a} ./ldso/ldso/*/*.{o,os,oS}
rm -f ./ldso/libdl/*.{o,os,a,oS}
rm -f ./libcrypt/*.{o,os,oS,a}
rm -f ./libintl/*.{o,os,a}
rm -f ./libm/{,*/,*/*/}*.{o,os,oS,a}
...
[EMAIL PROTECTED] /home/work/uClibc-work/SVN/trunk]find . -name *.o
./extra/config/zconf.tab.o
./extra/config/conf.o
./extra/config/kxgettext.o
Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Rob Landley wrote: On Thursday 28 August 2008 09:25:32 Carmelo AMOROSO wrote: Looking at what we have into the nptl branch is useful. Walk trough ldso directory and look for USE_TLS to see where you should put your hands to add TLS support. Working code is a good guide. Feel free to ask for explanation whenever you want... if we can/know, we can help. Volunteers are always welcome. Has there been any follow-up on this? No that I'm aware of. I'm interested in this, because I'm trying to build Linux From Scratch 6.3 under the upcoming Firmware Linux 0.9.1, which means I'm trying to build glibc under uClibc. And current versions of glibc won't even cross compile from a host that doesn't support TLS. (Yeah, I know it's broken. It's maintained by the FSF.) I can't provide a working uClibc development environment for a target and then tell people building glibc, if you want it, is your problem if I myself can't make it work. So I need this. I note that the original paper on TLS is: http://people.redhat.com/drepper/tls.pdf Which might help... This is what I used for adding TLS/sh4 relocation support on ld.so (nptl branch) Rob Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: fadvise gclibc vs uclibc
Corinna Schultz wrote: Quoting Carmelo AMOROSO [EMAIL PROTECTED]: a colleague of mine is right now working to produce a patch for posix_fadvise to fix all LTP tests using posix_fadvise[64]. Indeed LTP tests expect that, when posix_fadvise[64] fails, it should return as return value an error code (-errno) instead of simply setting properly errno and returning -1. Did you see my earlier message, detailing the errors I'm seeing? I have very little experience with this low-level programming, and don't really know how to begin fixing it, so if you have people already working on it, I'll happily wait for your patch. :) Do you have an estimate of when your patch will be available? -Corinna hopefully today :-) Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: libc_hidden_proto removal en masse
Denys Vlasenko wrote: On Friday 12 September 2008 13:10, Bernhard Reutner-Fischer wrote: On Tue, Jul 08, 2008 at 08:57:40AM +0200, Carmelo AMOROSO wrote: Denys Vlasenko wrote: Hi, Seems like removal of libc_hidden_proto's for functions from string.h went without major catastrophes. I would like to go ahead and remove all other libc_hidden_proto's from .c files. I plan to do it on coming weekend. If this will interfere with your work, please let me know before Friday. I am especially worried about Carmelo's merge - Carmelo, is my plan ok with you? Hi Denys, yes go ahead. I'll resynch it later. I've almost all nptl merged with trunk (except for some misc/internal part) and I'll push back to nptl branch this week as agreed with Khem for the ARM port. vda, what's the status of you putting them into the headers? Still in your .plan? Yes. Has nptl fully landed? -- vda Not yet :-( due to other higher priority task on kernel side. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] Xtensa strcoll problem with LOCALE support
Bob Wilson wrote: Carmelo AMOROSO wrote: Hi Bob, I don't see any problems in committing this on behalf of you, but proper signed-off-by should be added to these set of patches, as a general rule of thumbs. Possibly Acked-by Xtensa Maintainer (Chris Zankel) It looks like Chris already committed them, but thanks for offering. Yes he did. I've sent this message a lot before, but due to mail server problems, this has been received jjust few minutes ago. :-) I'll be sure to add a signed-off-by line in the future. Thanks, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]
Corinna Schultz wrote:
Quoting Carmelo AMOROSO [EMAIL PROTECTED]:
a colleague of mine is right now working to produce a patch for
posix_fadvise to fix all LTP tests using posix_fadvise[64].
Indeed LTP tests expect that, when posix_fadvise[64] fails,
it should return as return value an error code (-errno) instead
of simply setting properly errno and returning -1.
Did you see my earlier message, detailing the errors I'm seeing? I have
very little experience with this low-level programming, and don't really
know how to begin fixing it, so if you have people already working on
it, I'll happily wait for your patch. :) Do you have an estimate of when
your patch will be available?
-Corinna
Hi Corinna, may you try the attached patch.
It worked fine for NPTL branch solving all LTP posix_fadvise tests.
Let me know, so we can enqueue for commit.
Thanks to Filippo for having fixed this.
Cheers,
Carmelo
This patch fixes posix_fadvise[64] function to return the
error number in case of failure instead of -1 and setting errno,
according to SuSv3 (IEEE Std 1003.1 2004 edition) specification.
Add INTERNAL_SYSCALL macros to libc/sysdeps/linux/sh/bits/syscalls.h
to align sh to other archs.
Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED]
Reviewed-by: Carmelo Amoroso [EMAIL PROTECTED]
Index: libc/sysdeps/linux/common/posix_fadvise64.c
===
--- libc/sysdeps/linux/common/posix_fadvise64.c (revision 23401)
+++ libc/sysdeps/linux/common/posix_fadvise64.c (working copy)
@@ -40,14 +40,35 @@
return INTERNAL_SYSCALL_ERRNO (ret, err);
}
#else
-_syscall4(int, posix_fadvise64, int, fd, __off64_t, offset,
+static int syscall_posix_fadvise(int fd, off_t offset1, off_t offset2, off_t
len, int advice);
+#define __NR_syscall_posix_fadvise64 __NR_posix_fadvise64
+_syscall4(int, syscall_posix_fadvise64, int, fd, __off64_t, offset,
__off64_t, len, int, advice);
+int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
+{
+ int ret = syscall_posix_fadvise64(fd, offset, len, advice);
+ if (ret == -1)
+ return errno;
+ return ret;
+}
#endif
/* 32 bit implementation is kind of a pita */
#elif __WORDSIZE == 32
-#ifdef _syscall6 /* workaround until everyone has _syscall6() */
+#ifndef INTERNAL_SYSCALL
+int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
+{
+ INTERNAL_SYSCALL_DECL (err);
+ int ret = INTERNAL_SYSCALL (fadvise64_64, err, 6, fd,
+
__LONG_LONG_PAIR(offset 32, offset 0x),
+
__LONG_LONG_PAIR(len 32, len 0x),
+ advice);
+ if (!INTERNAL_SYSCALL_ERROR_P (ret, err))
+ return 0;
+ return INTERNAL_SYSCALL_ERRNO (ret, err);
+}
+#elif defined _syscall6 /* workaround until everyone has _syscall6() */
#define __NR___syscall_fadvise64_64 __NR_fadvise64_64
static __inline__ _syscall6(int, __syscall_fadvise64_64, int, fd,
unsigned long, high_offset, unsigned long, low_offset,
@@ -55,14 +76,17 @@
int, advice);
int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advice)
{
- return (__syscall_fadvise64_64(fd,
+ int ret = __syscall_fadvise64_64(fd,
__LONG_LONG_PAIR(offset 32, offset 0x),
__LONG_LONG_PAIR(len 32, len 0x),
- advice));
+ advice);
+ if (ret == -1)
+ return errno;
+ return ret;
}
#else
-#warning _syscall6 has not been defined for your machine :(
-#endif /* _syscall6 */
+#warning neither INTERNAL_SYSCALL nor _syscall6 has been defined for your
machine :(
+#endif /* INTERNAL_SYSCALL */
#else
#error your machine is neither 32 bit or 64 bit ... it must be magical
Index: libc/sysdeps/linux/common/posix_fadvise.c
===
--- libc/sysdeps/linux/common/posix_fadvise.c (revision 23401)
+++ libc/sysdeps/linux/common/posix_fadvise.c (working copy)
@@ -33,8 +33,18 @@
return 0;
}
#else
-_syscall4(int, posix_fadvise, int, fd, off_t, offset,
- off_t, len, int, advice);
+static int syscall_posix_fadvise(int fd, off_t offset1, off_t offset2, off_t
len, int advice);
+#define __NR_syscall_posix_fadvise __NR_fadvise64
+_syscall5(int, syscall_posix_fadvise, int, fd, off_t, offset1,
+ off_t, offset2, off_t, len, int, advice);
+
+int posix_fadvise(int fd, off_t offset, off_t len, int advice)
+{
+ int ret = syscall_posix_fadvise(fd, __LONG_LONG_PAIR (offset 31,
offset), len, advice);
+ if (ret == -1)
+ return errno;
+ return ret;
+}
#endif
Index: libc/sysdeps/linux/sh/bits/syscalls.h
Re: set fPIC option for librt
Bernhard Reutner-Fischer wrote:
On Thu, Sep 11, 2008 at 07:32:09PM +0800, JACOB BENJAMIN-VGH684 wrote:
Hello ppl,
and ran the resultant a.out on a monta vista box
I got an error saying something to the effect of Can't modify text
section. Use GCC option -fPIC for shared objects, please.
I looked into the config files and echo-ed out stuff in the makefiles
(esp Makefile.in in uClibc/librt) only to find out the CC variable is
set to arm_v6_be_uclibc-gcc only. Using this compile the os files are
created.
I hardcoded CC:= arm_v6_be_uclibc-gcc -fPIC
and then re-compiled uClibc and the program as well and it ran perfectly
well.
Now how and where do i make the config files to have fPIC set for the
cross compiler??
I was under the impression that we already use pic for the shared
objects, but ok.
Yes, exactly. I do think that there is some bogus asm code that is not
PIC, and FORCE_SHAREBLAE_TEXT_SEGMENT is set so linker refuses loading
non pic libraries.
Carmelo
$ grep FLAGS .config
UCLIBC_EXTRA_CFLAGS=
i.e. run 'make menuconfig'
go to the uClibc development/debugging options menu and set the
Enter any extra CFLAGS to use to build uClibc according to your needs.
Of course you can pass UCLIBC_EXTRA_{C,LD}FLAGS down via make if you do
not want or need to keep them in your .config.
Just as a sidenote, you should not hardcode anything in any makefile,
that's what .config is for, or a wrapper-script that passes down the
desired flags, if you really need (you shouldn't).
All help appreciated.
HTH,
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: fadvise gclibc vs uclibc
Bernhard Reutner-Fischer wrote: Hi, On Mon, Sep 08, 2008 at 05:35:24PM -0400, Corinna Schultz wrote: I noticed this difference between glibc and uclibc, in the fadvise code (I'm trying to track down a bug on a ppc32 machine). Why the difference in the number of arguments? I don't know too much about the system call mechanism, so this may be something obvious :) There were historically bugs in that area IIRC due to the kernel lagging a bit behind. Look for e.g. ASSUME_FADVISE64_64_SYSCALL and look at e.g. http://sourceware.org/bugzilla/show_bug.cgi?id=781 Tested patches are welcome. HTH, Hi Corinna, a colleague of mine is right now working to produce a patch for posix_fadvise to fix all LTP tests using posix_fadvise[64]. Indeed LTP tests expect that, when posix_fadvise[64] fails, it should return as return value an error code (-errno) instead of simply setting properly errno and returning -1. Man pages are not clear on this behaviour, it depends on POSIX standards it want be compliant to, so a clear understanding it's required before closing this issues. Anyway, some real bugs have been discovered in uclibc implementation and will be fixed asap. As Bernhard said, tested patches are welcome. Cheers, Carmelo PS: since you seem to be interrested in powerpc, let me point you to the heads-up that we will remove problematic parts of libm for powerpc, in case you have not seen it: http://uclibc.org/lists/uclibc/2008-September/019988.html If nobody fixes these issues by either getting properly licensed impls or by reimplementing the problematic bits under an acceptable license, then the powerpc specific hunks of libm will be removed from svn. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/stdio
Carmelo AMOROSO wrote: Carmelo AMOROSO wrote: [EMAIL PROTECTED] wrote: Author: vda Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008) New Revision: 21683 Log: Factor out the core of vprintf() into separate function vprintf_internal, so that: * vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing, then calls vprintf_internal * vsnprintf, vdprintf.c, vasprintf.c use vprintf_internal directly This makes sprintf faster (since it doesn't do any locking) and stops it from pulling in fseek in static compile. Added: trunk/uClibc/libc/stdio/_vfprintf_internal.c trunk/uClibc/libc/stdio/_vfwprintf_internal.c Modified: trunk/uClibc/libc/stdio/Makefile.in trunk/uClibc/libc/stdio/_stdio.h trunk/uClibc/libc/stdio/_vfprintf.c trunk/uClibc/libc/stdio/vasprintf.c trunk/uClibc/libc/stdio/vdprintf.c trunk/uClibc/libc/stdio/vsnprintf.c trunk/uClibc/libc/stdio/vswprintf.c [SNIP] Modified: trunk/uClibc/libc/stdio/_vfprintf.c === --- trunk/uClibc/libc/stdio/_vfprintf.c2008-04-09 11:38:48 UTC (rev 21682) +++ trunk/uClibc/libc/stdio/_vfprintf.c2008-04-09 19:51:18 UTC (rev 21683) @@ -1198,7 +1198,7 @@ #endif /**/ -#if defined(L_vfprintf) || defined(L_vfwprintf) +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal) /* We only support ascii digits (or their USC equivalent codes) in * precision and width settings in *printf (wide) format strings. @@ -1207,14 +1207,15 @@ static size_t _charpad(FILE * __restrict stream, int padchar, size_t numpad); -#ifdef L_vfprintf +#ifdef L__vfprintf_internal -#define VFPRINTF vfprintf +#define VFPRINTF_internal _vfprintf_internal #define FMT_TYPE char #define OUTNSTR _outnstr #define STRLEN strlen #define _PPFS_init _ppfs_init -#define OUTPUT(F,S)fputs_unlocked(S,F) +/* Pulls in fseek: #define OUTPUT(F,S)fputs_unlocked(S,F) */ +#define OUTPUT(F,S)__stdio_fwrite((const unsigned char *)(S),strlen(S),(F)) Hi Denys, while running some test on nptl bracn with runtime assertion enabled, I've discoverd that this change is causing uclibc aborting due to an assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works fine. I'd like to understand better the rationale behind and I'm wondering if the problem is present in trunk with other arch than sh4. To exploit the problem you simply need to call a printf with a format string (i.e. printf(val=%d\n,x) ). Please let me know your comments, thanks. Carmelo Hi, doing further analysis, I've figure out why we fail using __stdio_fwrite. Basically __stdio_fwrite expects at least 1 bytes. fputs_unlocked(S,F) calls fwrite_unlocked and this calls __stdio_fwrite only if bytes to be written are 0, otherwise simply returs 0 (that is correct). During the parsing of format spec it could happen that __stdio_fwrite is called passing an empty string and with assertion enabled it will abort. So, I think that using fputs_unlocked is fine, I don't see any other reasons for calling __stdio_fwrite directly. Cheers, Carmelo Fix applied in rev 23367. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] locale test fix.
Carmelo Amoroso wrote: Bernhard Reutner-Fischer wrote: On Fri, Jul 11, 2008 at 02:12:51PM +0200, Carmelo AMOROSO wrote: Filippo ARCIDIACONO wrote: Hi all, The following patch solve several locale multibyte tests failures. It has been tested and works fine. The patch applies to the latest trunk revision. Any comment are welcome. Best Regards, Filippo. This patch fixes several locale tests: libc/stdlib/_strtod.c - tst_wcstod; libc/stdlib/stdlib.c- tst_mblen, tst_mbtowc, tst_wctomb; libc/stdio/_scanf.c - tst_swscanf; libc/string/strncmp.c - tst_wcsncmp; libc/misc/wchar/wchar.c - tst_mbrlen, tst_mbrtowc, tst_wcswidth. Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED] Hi All, is there anybody having some experience on locale that could review this patch. This work has been produced by Filippo (a my collegue) and I've already reviewed together, so may be worth someone else have a look at. We are confident on the fixes as confirmed by having fixed some tests from glibc. We would like to integrated them into trunk soon. Seems like nobody spotted problems with the patch, Carmelo, please apply. TIA, Yes, it is on on my next week todo list. Carmelo Done in rev 23369. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: extern_inline macro [was: Re: svn commit: trunk/uClibc: include libc/sysdeps/linux/common/bits]
Bernhard Reutner-Fischer wrote: On Tue, Sep 09, 2008 at 05:06:58AM -0700, [EMAIL PROTECTED] wrote: Author: carmelo Date: 2008-09-09 05:06:58 -0700 (Tue, 09 Sep 2008) New Revision: 23365 Log: Hush compiler for extern inline warnings by using __extern_inline macro, this also makes gcc 4.3 happy. (Taken from NPTL branch) Modified: trunk/uClibc/include/ctype.h trunk/uClibc/libc/sysdeps/linux/common/bits/cmathcalls.h Looks like there are some additional spots that would want to use this one macro? $ grep -r extern[[:space:]][[:space:]]*__inline * libc/sysdeps/linux/mips/sys/tas.h:# define _EXTERN_INLINE extern __inline libc/sysdeps/linux/mips/bits/socket.h:# define _EXTERN_INLINE extern __inline libc/sysdeps/linux/common/bits/socket.h:# define _EXTERN_INLINE extern __inline libc/sysdeps/linux/common/bits/sigset.h:# define _EXTERN_INLINE extern __inline libc/sysdeps/linux/common/bits/mathinline.h: Surround GCC-specific parts with #ifdef __GNUC__, and use `extern __inline'. and all of libc/sysdeps/linux/*/bits/mathinline.h:# define __MATH_INLINE extern __inline Hi, I cannot see warnings on my build produced by these missing changes, anyway I don't see any reason for not fixing them too. May you commit? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: libc/stdlib/malloc/calloc.c: No such file or directory with blackfin-toolchain-uclibc-default ([EMAIL PROTECTED])
gargs wrote: Hi I am cross compiling a program that is known to work on various other uClinux platforms, to target blackfin. When I compile using the blackfin-toolchain-uclibc-default ([EMAIL PROTECTED]), and debug the code using gdb, before the segmentation fault, I get numerous messages of this nature: calloc (nmemb=12, lsize=1) at libc/stdlib/malloc/calloc.c:34 34 libc/stdlib/malloc/calloc.c: No such file or directory. in libc/stdlib/malloc/calloc.c and *___GI_strrchr (s=0x920f86 pd, c=value optimized out) at libc/ string/generic/strrchr.c:29 29 libc/string/generic/strrchr.c: No such file or directory. in libc/string/generic/strrchr.c Why is this so? I installed the uclibc from the blackfin.uclinux.org RPM. cheers, -dee It seems to be a problem related to wrong settings in gdb, almost sure that the search path for source files is wrong. On gdb console try gdb show dir to see the current values and eventually fix it by using gdb dir your source root dir Otherwise, post message to gdb list. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh4: use optimized asm version of memcpy - add config option to support backward copying
Paul Mundt wrote: On Mon, May 28, 2007 at 02:44:47PM +0200, Carmelo Amoroso wrote: I've updated the previous patch to keep into account both suggestions made by Mike and Paul. A brief explanation of the changes follows: did you have time to look at this ? If accepted, may reduce a bit the diff from sh4 port and trunk. This ode is currently used on nptl/sh4 port. The updated version looks fine to me. Applied in rev 23370 with a minor modification. _wordcopy_fwd_aligned and _wordcopy_fwd_dest_aligned moved form memcpy.c file to an internal C file (_memcpy_fwd.c) to silent compiler for defined but unused symbol. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: status of 0.9.30 release
Rob Landley wrote: On Sunday 07 September 2008 02:47:49 Carmelo Amoroso wrote: Rob Landley wrote: On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote: Hi, Were there any plans for a 0.9.30 release before the NPTL merge? What is the status of the 0.9.30 release? vapier would know, ISTR that he was the designated RM. What are the outstanding regressions versus 0.9.29 on your arch? i386 seems to be in a good shape, AFAICS. Perhaps it would be nice to look at the open issues in mantis and fix a couple of them for .30-rc1. Just a thought.. I'm interested in finding regressions too, because I'm seriously considering putting out a .30 of my own just so there's a known set of bugs to test against. (Considering that nothing's been checked into the repository for two weeks, this seems like a nice point to do it...) I agree, I don't see any real issues for postponing to ship a .30 release just now. I've found a few, starting with the fact that it doesn't seem to build on mips: CC libc/stdlib/__cxa_finalize.os In file included from libc/stdlib/__cxa_finalize.c:8: libc/stdlib/_atexit.c: In function '__cxa_finalize': libc/stdlib/_atexit.c:205: warning: implicit declaration of function 'typeof' libc/stdlib/_atexit.c:205: error: expected ';' before '__prev' libc/stdlib/_atexit.c:205: error: '__prev' undeclared (first use in this function) libc/stdlib/_atexit.c:205: error: (Each undeclared identifier is reported only once libc/stdlib/_atexit.c:205: error: for each function it appears in.) libc/stdlib/_atexit.c:205: error: expected ';' before '__prev' libc/stdlib/_atexit.c:205: error: expected ';' before '__prev' libc/stdlib/_atexit.c:205: error: expected ';' before '__prev' libc/stdlib/_atexit.c:205: error: invalid lvalue in asm output 0 make: *** [libc/stdlib/__cxa_finalize.os] Error 1 Working on it... I stopped for a while nptl merge because involved in kernel stuff, but I'll go back to uclibc next week. I'm looking at the -svn version because 0.9.29 doesn't have TLS and current glibc absolutely won't build on a host that doesn't have TLS. (Yes, even when trying to cross-compile it.) This means you can't cross compile from a uClibc system to a glibc system, so you can't build Linux From Scratch 6.3 under FWL 0.9.0. I realize that moving to svn doesn't inherently solve that, but if I'm contemplating patching the heck out of something (I don't need NPTL, just TLS), then more than year old version probably isn't the best basis for it. As you have seen, I've fixed a problem in ntpl static link. Which nptl branch is this? The sjhill one that only does super hitachi, the arm one from the code sourcery guys, or the other one? To be honest, I haven't looked at any of those this year because they all seem totally stalled. Yes, there is just one NPTL branch supporting now, all integrated together, mips/arm/sh4. Almost synchronized with trunk. Containing the patches I was referring missing from trunk... at least for sh4 fully tested (LTP too), really used in a production system from ST's customers. It seems you have missed a lot of recent works and commit done by Khem and myself. I've discovered similar problrms on trunk (using linuxthreads.old) at least on sh4 (but I think it's a common problem). I don't have an emulator I can run an sh4 linux kernel under. I've build an sh4 cross compiler and uClibc (0.9.29) based root filesystem with busybox and a native toolchain, but qemu 0.9.1 system emulation only has a toy sh4 board that nobody knows how to make work and doesn't have any interesting hardware attached to it anyway. (The systems I'm using have a virtual hard drive and network card so I can build natively under 'em using distcc to call out to the cross compiler. The qemu sh4 emulation I can't even get to boot to a shell prompt via serial console.) Don't worry, I've real working sh4 hw with its toolchain. I'll test it. I'll come with a test case soon, but being this issue affecting static binaries, I don't think it can delay .30 release. I had a 0.9.29 patch required to make static binaries work, i dunno if current svn still needs it... Haven't looked yet. I don't know Mike's plan, but he is silent since a long time. I no longer particularly care. It's been longer than Erik ever went without a release, I'm stabilizing an -svn fork for my own use and putting a tarball _somewhere_ I can point to and go this is what I'm using. It can be -rc1, or a renamed nightly snapshot. (I'll send _myself_ cake when it's over. Sheesh.) I was working on this last week, but upgrading my laptop to Kubuntu 8.04 knocked me offline for a week. Back now. :) Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to svn. I'll let you know what breaks, and hopefully patch it up for a quick .30. I should
Re: Has uClibc passed the LTP tests?
Corinna Schultz wrote: Hello, all. I'm trying to track down a bug in the fadvise functions. I'm seeing a failure in the LTP tests for posix_fadvise and posix_fadvise64, on a ppc 32 machine. The specific failures are: * in the posix_fadvise64 tests, the function call is still returning -1 on error and setting ERRNO. On my machine, the INTERNAL_SYSCALL version of the function is not being called -- it's the __syscall_fadvise64_64 version that's being called. * in the posix_fadvise tests, the advice value the kernel is seeing is corrupted - it sees 63794 for all values passed in (the tests send each advice value from 0-5). Interestingly, if I run the tests using strace, the value the kernel sees is 87, except for the first one, where it correctly sees 0. The returns values are correct, as the INTERNAL_SYSCALL code is being used in this case. So I'm wondering if there has been a successful run of the LTP tests on the various arches, and this is my problem, or if this is a new issue. My kernel is 2.6.16. I'm not sure what version of uClibc I'm using, but it's some flavor of 0.9.28. I copied the most recent version of posix_fadvise.c and posix_fadvise64.c from the cvs repository. -Corinna Schultz IBM LTC Hi COrinna, please try adding #include sysdep.h... you should get INTERNALL_SYSCALL macro defined. We are going to commit a fix for this. Let me know, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] locale test fix.
Bernhard Reutner-Fischer wrote: On Fri, Jul 11, 2008 at 02:12:51PM +0200, Carmelo AMOROSO wrote: Filippo ARCIDIACONO wrote: Hi all, The following patch solve several locale multibyte tests failures. It has been tested and works fine. The patch applies to the latest trunk revision. Any comment are welcome. Best Regards, Filippo. This patch fixes several locale tests: libc/stdlib/_strtod.c - tst_wcstod; libc/stdlib/stdlib.c- tst_mblen, tst_mbtowc, tst_wctomb; libc/stdio/_scanf.c - tst_swscanf; libc/string/strncmp.c - tst_wcsncmp; libc/misc/wchar/wchar.c - tst_mbrlen, tst_mbrtowc, tst_wcswidth. Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED] Hi All, is there anybody having some experience on locale that could review this patch. This work has been produced by Filippo (a my collegue) and I've already reviewed together, so may be worth someone else have a look at. We are confident on the fixes as confirmed by having fixed some tests from glibc. We would like to integrated them into trunk soon. Seems like nobody spotted problems with the patch, Carmelo, please apply. TIA, Yes, it is on on my next week todo list. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: status of 0.9.30 release
Rob Landley wrote: On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote: Hi, Were there any plans for a 0.9.30 release before the NPTL merge? What is the status of the 0.9.30 release? vapier would know, ISTR that he was the designated RM. What are the outstanding regressions versus 0.9.29 on your arch? i386 seems to be in a good shape, AFAICS. Perhaps it would be nice to look at the open issues in mantis and fix a couple of them for .30-rc1. Just a thought.. I'm interested in finding regressions too, because I'm seriously considering putting out a .30 of my own just so there's a known set of bugs to test against. (Considering that nothing's been checked into the repository for two weeks, this seems like a nice point to do it...) I agree, I don't see any real issues for postponing to ship a .30 release just now. I stopped for a while nptl merge because involved in kernel stuff, but I'll go back to uclibc next week. As you have seen, I've fixed a problem in ntpl static link. I've discovered similar problrms on trunk (using linuxthreads.old) at least on sh4 (but I think it's a common problem). I'll come with a test case soon, but being this issue affecting static binaries, I don't think it can delay .30 release. I don't know Mike's plan, but he is silent since a long time. I was working on this last week, but upgrading my laptop to Kubuntu 8.04 knocked me offline for a week. Back now. :) Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to svn. I'll let you know what breaks, and hopefully patch it up for a quick .30. I should be able to test x86, x86-64, mips (both endiannesses), arm little endian, and powerpc. (And maybe sparc if it suddenly decides to work, but it didn't under 0.9.29.) I'll try to test sh4 on trunk too. Rob _ Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: status of 0.9.30 release
Carmelo Amoroso wrote: Rob Landley wrote: On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote: Hi, Were there any plans for a 0.9.30 release before the NPTL merge? What is the status of the 0.9.30 release? vapier would know, ISTR that he was the designated RM. What are the outstanding regressions versus 0.9.29 on your arch? i386 seems to be in a good shape, AFAICS. Perhaps it would be nice to look at the open issues in mantis and fix a couple of them for .30-rc1. Just a thought.. I'm interested in finding regressions too, because I'm seriously considering putting out a .30 of my own just so there's a known set of bugs to test against. (Considering that nothing's been checked into the repository for two weeks, this seems like a nice point to do it...) I agree, I don't see any real issues for postponing to ship a .30 release just now. I stopped for a while nptl merge because involved in kernel stuff, but I'll go back to uclibc next week. As you have seen, I've fixed a problem in ntpl static link. I've discovered similar problrms on trunk (using linuxthreads.old) at least on sh4 (but I think it's a common problem). I'll come with a test case soon, but being this issue affecting static binaries, I don't think it can delay .30 release. Indeed I've few pending patches to push that may be worth including in .30 release. - locale supports fixes - an optimized sh4 memcpy implementation (currently used since a long time in uclibc-nptl, glibc and kernel) - getdents I don't know Mike's plan, but he is silent since a long time. I was working on this last week, but upgrading my laptop to Kubuntu 8.04 knocked me offline for a week. Back now. :) Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to svn. I'll let you know what breaks, and hopefully patch it up for a quick .30. I should be able to test x86, x86-64, mips (both endiannesses), arm little endian, and powerpc. (And maybe sparc if it suddenly decides to work, but it didn't under 0.9.29.) I'll try to test sh4 on trunk too. Rob _ Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: static linking for pthreads in nptl branch?
Carmelo AMOROSO wrote: Chris Metcalf wrote: On 9/2/2008 10:25 AM, Chris Metcalf wrote: On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote: I had to read it more carefully.. you are right, and yes, probably the issue you were referring to about static link and pthread was raised by me in the past. It was related to opendir function that is the only function within libc that calls pthread_mutex_init, and yes, when statically linked, even if using -lpthread, it was bind to the libc stub. At that time I fixed opendir by adding a memset to clear the lock data. (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625view=rev) Since I just made that example up, it's funny that it was a real problem :-) What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init) in nptl/init.c ? were you thinking to this with the word 'register'. I did not test it, but it may be sufficient. I had been thinking of just using the same shared model of struct pthread_functions, but that's probably overkill, since it would bring in all of libpthread.a even if the application only used a few functions. So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the right approach. It also avoids the scary assumption that PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms. I think we also need to add /* Used by __UCLIBC_MUTEX_LOCK for the libc locking code. */ PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_pop_restore) PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_push_defer) in pthread_create.c to avoid getting the stub versions. Yes, I've already add this into my working dir. It's on the way for svn too. Carmelo I did it yesterday Revision: 23310 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Revision 20625, opendir
Bernd Schmidt wrote: Carmelo Amoroso wrote: When libpthread is included in the link, __pthread_mutex_init will do the initialization. So, what's going on? likely you're right ... but this is not true for the nptl branch. I've almost completed to port a lot of changes from th trunk to the nptl branch (one of this changes are exactly on weaks pthread symbols) and I'll check again if this fix is still required (anyway, glibc has the memset as I added into the uclibc), but your point is correct. Thanks for the update. I don't really mind the change itself, but I wanted to be sure it's not hiding a bug elsewhere. It would be bad if NPTL used real locking for single-threaded, statically linked binaries. Bernd Hi Bernd, just an update. The problem was just the opposite. In NPTL multi-threaded, statically linked binaries, the locking functions were always empty stab (from weaks.o) instead of real ones from libpthread.a. After recent discussions with Chris Metcalf, I figured out a better fix to be done in NPTL to force linking real locking functions in MT applications. At this point the memset from opendir can be removed and reverted to the previous code: it was basically a work around. Anyway, before committing, I'd try to check what happens on trunk with linuxthreads too. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
Paul Mundt wrote: On Tue, Sep 02, 2008 at 02:09:20PM +0200, Carmelo AMOROSO wrote: I did not success to create a test that could fail. application ctor/dtor defined by gcc attribute ((__contructor__)) on ((__destructor__)) are correctly invoked. Indeed, if I put the ctor/dtor in a separate object file and I build it as a PIC object, then the compiler will create the proper _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and use r12. Yes, glibc _init function does it, but I'm thinking that it is useless. I cannot see a scenario in which this may fail. Are we sure we need this code at all? or we simply have taken the code as is from glibc in the past ? I expect it is just something that was blindly copied from glibc. I wasn't the one that copied it in to uclibc originally, but I would wager it's a sanity measure to work around old compilers. interesting ! The GCC ident references 3.3.2, I don't have anything that old sitting around any more, neither I have. but it might be worth testing out with something before that to see if the proper entry is generated without the init/fini help before deciding whether to axe the code completely or not. Yoshii, are you able to try with older gcc ? or was you able to produce a testcase ? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
Paul Mundt wrote: On Thu, Aug 28, 2008 at 07:58:15AM +0200, Carmelo AMOROSO wrote: Paul Mundt wrote: On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote: Takashi Yoshii wrote: For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I had to think about this briefly. It was part of the SH-2 work done by Mark Shinwell (added to Cc). The disabling of GOT related code in the non-shared case was intentional, but I don't immediately recall what the rationale was. yes, but as Yoshii spotted, the code now seems doing just the opposite. Good point, it seems I'm unable to read in that case. :-) Inverting it seems to be the reasonable thing to do. I'll give it a test and check in Yoshii-san's patch if nothing breaks. Hi Paul, I did not success to create a test that could fail. application ctor/dtor defined by gcc attribute ((__contructor__)) on ((__destructor__)) are correctly invoked. Indeed, if I put the ctor/dtor in a separate object file and I build it as a PIC object, then the compiler will create the proper _GLOBAL_OFFSET_TABLE_ entry and will produce the proper code to load and use r12. Yes, glibc _init function does it, but I'm thinking that it is useless. I cannot see a scenario in which this may fail. Are we sure we need this code at all? or we simply have taken the code as is from glibc in the past ? I agree that the patch is logically correct, but we might add extra useless code. Indeed, never before, I had problem using uclibc on sh4 due to this missing code. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: static linking for pthreads in nptl branch?
Chris Metcalf wrote: On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote: I had to read it more carefully.. you are right, and yes, probably the issue you were referring to about static link and pthread was raised by me in the past. It was related to opendir function that is the only function within libc that calls pthread_mutex_init, and yes, when statically linked, even if using -lpthread, it was bind to the libc stub. At that time I fixed opendir by adding a memset to clear the lock data. (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625view=rev) Since I just made that example up, it's funny that it was a real problem :-) :-) What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init) in nptl/init.c ? were you thinking to this with the word 'register'. I did not test it, but it may be sufficient. I had been thinking of just using the same shared model of struct pthread_functions, but that's probably overkill, since it would bring in all of libpthread.a even if the application only used a few functions. So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the right approach. It also avoids the scary assumption that PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms. Well, I've tried it using the old test case I had for the opendir problem, and with this fix pthread_mutex_init, in a static multi-threaded app, is now linked from libptrhead.a instead of libc.a (weaks.o). If the app were single-threaded (- pthread_create not called), then it would correctly resolved into the empty stub provided ad hoc by weaks.o. Please, may you try with your application and see if it works as well ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
REJECT : Re: [PATCH] sh : a little optimization in clone.S
Paul Mundt wrote: On Thu, Aug 28, 2008 at 07:56:03AM +0200, Carmelo AMOROSO wrote: Carmelo AMOROSO wrote: Hi Paul, All attached a little fix in clone asm code for SH to use a delayed branch instead of a normal branch. Let me know so I can commit it. Regards, Carmelo Please hold on. After a discussion with a colleague of mine, really sh4 architectural expert, we are thinking that it could not be a real optimization due to potential unuseful i-cache miss. So, I need to clarify it before. sorry ;-) You could work around that by prefetching the icache line earlier on in the entry, but if you do that, you will want to measure to see if you still have any savings from using the delayed branch. I expect the prefetch will negate any micro-optimized win you are aiming for with the delayed branch. Thanks Paul for this feedback. Indeed, in the delay slot it should be done instruction that are required to the instruction at the destination target and later. So, discard this patch. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
Paul Mundt wrote: On Tue, Aug 26, 2008 at 03:53:18PM +0200, Carmelo AMOROSO wrote: Takashi Yoshii wrote: For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I had to think about this briefly. It was part of the SH-2 work done by Mark Shinwell (added to Cc). The disabling of GOT related code in the non-shared case was intentional, but I don't immediately recall what the rationale was. yes, but as Yoshii spotted, the code now seems doing just the opposite. Original thread here: http://www.uclibc.org/lists/uclibc/2006-October/016617.html I expect that it's related to the ABI, in that we also don't have the GOT references in the FDPIC case, so it should likely be conditionalized for the targets that actually emit _GLOBAL_OFFSET_TABLE_, rather than depending on __HAVE_SHARED__. While I hit this on FDPIC, I would wager that Mark hit this on shared FLAT (which we don't have support in-tree for anyways) on his internal libc. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 12:58:50PM +0300, Cristi Magherusan wrote: Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? Perhaps it would be better to update the non-old libpthread to something recent and add TLS to that. The .old is the proven fallback AFAIU. absolutely agreed. I can volunteer, but I may need someone more experienced to guide me. Looking at what we have into the nptl branch is useful. Walk trough ldso directory and look for USE_TLS to see where you should put your hands to add TLS support. Working code is a good guide. Feel free to ask for explanation whenever you want... if we can/know, we can help. Volunteers are always welcome. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh : a little optimization in clone.S
Carmelo AMOROSO wrote: Hi Paul, All attached a little fix in clone asm code for SH to use a delayed branch instead of a normal branch. Let me know so I can commit it. Regards, Carmelo Please hold on. After a discussion with a colleague of mine, really sh4 architectural expert, we are thinking that it could not be a real optimization due to potential unuseful i-cache miss. So, I need to clarify it before. sorry ;-) Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] sh : a little optimization in clone.S
Hi Paul, All attached a little fix in clone asm code for SH to use a delayed branch instead of a normal branch. Let me know so I can commit it. Regards, Carmelo A little optimization in clone sanity check: use a delayed branch instruction (bt/s) so that null pointer check for second input argument (hold on r5) is done into the delay slot. Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED] Index: libc/sysdeps/linux/sh/clone.S === --- libc/sysdeps/linux/sh/clone.S (revision 23105) +++ libc/sysdeps/linux/sh/clone.S (working copy) @@ -44,7 +44,7 @@ clone: /* sanity check arguments. */ tst r4, r4 - bt 0f + bt/s0f tst r5, r5 bf/s1f mov#+__NR_clone, r3 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.
Takashi Yoshii wrote: Hi, For SH, init/fini function prologue is defined in libc/sysdeps/linux/sh/crti.S as follows. | (frame entry) |#ifndef __HAVE_SHARED__ | (GOT pointer initialization) |#endif I think this should be ifdef, but ifndef. Or, are there any reason that GOT should be used (only)in NON-shared case ? Well, this change has been committed by lethal at http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/sh/crti.S?rev=16426view=diffr1=16426r2=16425p1=trunk/uClibc/libc/sysdeps/linux/sh/crti.Sp2=/trunk/uClibc/libc/sysdeps/linux/sh/crti.S so, unless there something I'm not understanding too, I suppose it was a typo by Paul (aka lethal). Paul, my you give some lights on this change ? I'm wondering anyway it the could be a testcase to show a potential problem (if this is wrong). Carmelo I did some cleanups as well as invert that conditions. Actually, push r12 is not needed in non-shared case. But, I've left it untouched, because I don't want to modify the function epilogue(crtn.S). If fixed, we will have 4 bytes smaller code. Anyone want it ? Regards, /yoshii --- libc/sysdeps/linux/sh/crti.S: Fix(invert) __HAVE_SHARED__ condition. Reorder/eliminate instructions. Signed-off-by: Takashi YOSHII [EMAIL PROTECTED] --- diff --git a/libc/sysdeps/linux/sh/crti.S b/libc/sysdeps/linux/sh/crti.S index a74f96e..a092b78 100644 --- a/libc/sysdeps/linux/sh/crti.S +++ b/libc/sysdeps/linux/sh/crti.S @@ -12,20 +12,17 @@ _init: mov.l r12,@-r15 mov.l r14,@-r15 sts.l pr,@-r15 -#ifndef __HAVE_SHARED__ + mov r15,r14 +#ifdef __HAVE_SHARED__ mova.L6,r0 mov.l .L6,r12 - add r0,r12 -#endif - mov r15,r14 bra 1f - nop + add r0,r12 .align 2 -#ifndef __HAVE_SHARED__ .L6: .long _GLOBAL_OFFSET_TABLE_ -#endif 1: +#endif .section .fini .hidden _fini @@ -37,19 +34,15 @@ _fini: mov.l r14,@-r15 sts.l pr,@-r15 mov r15,r14 -#ifndef __HAVE_SHARED__ +#ifdef __HAVE_SHARED__ mov.l .L11,r12 mova.L11,r0 - add r0,r12 -#endif - bra 1f - nop + add r0,r12 .align 2 -#ifndef __HAVE_SHARED__ .L11: .long _GLOBAL_OFFSET_TABLE_ -#endif 1: +#endif .ident GCC: (GNU) 3.3.2 ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: branches/uClibc-nptl: include libc/stdlib/malloc-standard libc etc...
Chris Metcalf wrote: On 7/29/2008 10:50 AM, Carmelo AMOROSO wrote: Carmelo AMOROSO wrote: [...] libc/misc/utmp/utent.c:38: warning: braces around scalar initializer libc/misc/utmp/utent.c:38: warning: (near initialization for 'utmplock.__data.__spins') any idea ? I'm not sure it's related to use of futex. Carmelo Looked at this better, and I'm convinced it's not correct. pthread_mutex_t contains all scalar entries, extra braces are not required. I'm also seeing this in my port on the tile architecture, using the latest nptl branch code now. In my build I use -Werror, since I don't want to accidentally start building code with obvious warnings in it, so I'll have to #ifdef the extra braces away on our architecture (yuck). I have a different, though somewhat related problem; I've changed the lowlevellock code to be more efficient on our architecture, so the int __lock has to be __lll_lock_t lock (a two-word struct), and I pull that type and the __LLL_LOCK_INITIALIZER into pthreadtypes.h, then use it in pthread.h. But maybe we should just admit that there's going to be architectural skew here, and move the definition of the initializer into the per-architecture pthreadtypes.h, to go next to the actual structure definition that it's initializing? Hi Chris, let me have a look... Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: gentoo patchset
Cristi Magherusan wrote: Hello, On Fri, 2008-08-08 at 12:15 +0200, Carmelo AMOROSO wrote: Cristi Magherusan wrote: Hello, I noticed that the gentoo uclibc ebuild[1] applies a considerable amount of patches[2]. Has anyone investigated how many of them worth including in the main uclibc tree? Personally, I'm most interested about the libm ones, but the other ones may be nice to have too. Best regards, Cristi [1] http://www.gentoo-portage.com/AJAX/Ebuild/66923 [2] http://mirror.mcs.anl.gov/pub/gentoo/distfiles/ uClibc-0.9.28.3-patches-1.8.tar.bz2 Being this patch set against 0.9.28 release, that is an old release, I assume that most of these fixes should be already into the current main stream. Doing this kind of analysis, even if could shown some unknown problem, is time consuming. I honestly don't have time for this now. The ones I know for sure that are missing both from the latest release and CVS are the ones that add those extra functions to libm, and that I really need in order to compile kvm and link it against uClibc. Best regards, Cristi May you create an ad hoc patch for this missing libm functions and propose for adding to uclibc. A config option will be required to selectively enable/disable this extra... what are they ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Default Password for uclibc login
Mandeep Ahuja wrote: Hi everyone, I have a buildroot which builds uclibc tool chain with busybox1.2.2.1. When I telnet into my board it says uclibc login: root Password: username is root, I dont know what the password is? I have tried nothing, blank, root, rootmenothing worked. Does anyone whats the default password is? need your guys help.. thanks Mandeep Hi, not a uclibc issue, Please ask to busybox list. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
Takashi Yoshii wrote: Hi, Hum... I think that we are lucky because _dl_fini is defined in ldso.c that includes dl-startup.c that includes dl-startup.h... but if _dl_fini were defined in another compilation units ? does it work ? am I correct ? Well, that strange structure of the source code tells us that this program is more or less under such a restriction, I think. But, yes, this one could result some difficulty on future re-construction. My solution is based on a more generic solution using a GOT entry. What is the best solution ? comments ? May I? May I say, My code is better because it is 12 bytes smaller! as a joke. Thank you. Your GOT approach is more generic, and seems to be common seeing other ARCHs does the same(except m68k and mips?). Please feel free to ignore my code. I'm happy to see the issue fixed by the combined code. Cheers. /yoshii Ok, I'll commit it. Good collaborative work ;-) Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
Takashi Yoshii wrote: Thank you for your review. I've found some of architectures other than SH set a pointer to _dl_fini() to rtld_fini in ldso/ldso/*/dl-startup.h, which apparently SH should have, too. Yes, we need. please look at my previous reply, where I've a patch to solve it in a different way. I've add small patch. Though I am really not confidence of correctness This one set the pointer to _dl_init() after simple PC-relative relocation. [SNIP] I even dont know if what rtld_fini do is this or not, though ;) But, without fix, no fini line appears. Yes, it's rtld_fini doing this. This is the flow: __uClibc_main - main() - exit - __uClibc_fini() - rtld_fini /yoshii --- SH: dl-startup.h: Set pointer to _dl_fini as an arg to _start. ldso/ldso/sh/dl-startup.h |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ldso/ldso/sh/dl-startup.h b/ldso/ldso/sh/dl-startup.h index 3e59093..398846c 100644 --- a/ldso/ldso/sh/dl-startup.h +++ b/ldso/ldso/sh/dl-startup.h @@ -12,10 +12,14 @@ __asm__( bsrfr0\n add#4, r4\n .jmp_loc:\n +stspr, r1! pr == here\n +mov.l.L_dl_fini, r4\n jmp@r0\n -mov#0, r4 !call _start with arg == 0\n +addr1, r4 !call _start with arg _dl_init\n .L_dl_start:\n .long _dl_start-.jmp_loc\n +.L_dl_fini:\n +.long _dl_fini-.jmp_loc\n .size_start,.-_start\n .previous\n ); -- 1.5.4.5 Hum... I think that we are lucky because _dl_fini is defined in ldso.c that includes dl-startup.c that includes dl-startup.h... but if _dl_fini were defined in another compilation units ? does it work ? am I correct ? My solution is based on a more generic solution using a GOT entry. What is the best solution ? comments ? Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
Takashi Yoshii wrote: Hi, As a comment in libc/sysdeps/linux/sh/crt1.S says /* __uClibc_main (main, argc, argv, init, fini) */ , something wrong here. There should be two more args. 7th arg stack_end seems to be missing. 6th one is not listed, but the original code pushed register r4 here. It is not documented, but because ldso/ldso/sh/dl-startup.h explicitly sets 0 to r4 just before jump here, there must be a kind of calling convention. So, I preserve the code, and add a comment that this is the way to pass rtld_fini from prior routine. I really can't find any documents about this convention, though. /yoshii --- sh: Fix args for __uClibc_main() in crt1.S add missing 7th arg stack_end. add comment of undocumented usage of r4. fix comment of expected __uClibc_main() prototype. diff --git a/libc/sysdeps/linux/sh/crt1.S b/libc/sysdeps/linux/sh/crt1.S --- a/libc/sysdeps/linux/sh/crt1.S +++ b/libc/sysdeps/linux/sh/crt1.S @@ -24,6 +24,11 @@ At this entry point, most registers' values are unspecified, except: + r4Contains a function pointer to be registered with `atexit'. + This is how the dynamic linker arranges to have DT_FINI + functions called for shared libraries that have been loaded + before this code runs. + spThe stack contains the arguments and environment: 0(sp) argc 4(sp) argv[0] @@ -48,7 +53,8 @@ _start: mov.l @r15+,r5 mov r15, r6 - /* Push the fini func onto the stack */ + /* Push the stack_end, rtld_fini and fini func onto the stack */ + mov.l r6,@-r15 mov.l r4,@-r15 mov.l L_fini,r0 mov.l r0,@-r15 @@ -57,7 +63,7 @@ _start: mov.l L_main,r4 mov.l L_init,r7 - /* __uClibc_main (main, argc, argv, init, fini) */ + /* __uClibc_main (main, argc, argv, init, fini, rtld_fini, stack_end) */ /* Let the libc call main and exit with its return code. */ mov.l L_uClibc_main,r1 Hi Takashi, your point is correct and the patch looks fine. Looking again at the ld.so - _start flow, yes sh4 forces rtld_fini to be NULL (r4 = 0 set in dl-startup.h as you told), so this means that on sh4 we do not call the _dl_fini destructor, loosing eventually to call the destructors of the dependant shared objects. It should be simple enough to write a test showing this. I'll spend a few time longer to look at what it's happening on glibc part, and eventually integrate your patch by setting the rtld_fini (6 ^ args) too. Thanks a lot, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [PATCH] sh: Fix args for __uClibc_main() in crt1.S
Carmelo AMOROSO wrote: Takashi Yoshii wrote: Hi, As a comment in libc/sysdeps/linux/sh/crt1.S says /* __uClibc_main (main, argc, argv, init, fini) */ , something wrong here. There should be two more args. 7th arg stack_end seems to be missing. 6th one is not listed, but the original code pushed register r4 here. It is not documented, but because ldso/ldso/sh/dl-startup.h explicitly sets 0 to r4 just before jump here, there must be a kind of calling convention. So, I preserve the code, and add a comment that this is the way to pass rtld_fini from prior routine. I really can't find any documents about this convention, though. /yoshii --- sh: Fix args for __uClibc_main() in crt1.S add missing 7th arg stack_end. add comment of undocumented usage of r4. fix comment of expected __uClibc_main() prototype. diff --git a/libc/sysdeps/linux/sh/crt1.S b/libc/sysdeps/linux/sh/crt1.S --- a/libc/sysdeps/linux/sh/crt1.S +++ b/libc/sysdeps/linux/sh/crt1.S @@ -24,6 +24,11 @@ At this entry point, most registers' values are unspecified, except: + r4 Contains a function pointer to be registered with `atexit'. +This is how the dynamic linker arranges to have DT_FINI +functions called for shared libraries that have been loaded +before this code runs. + sp The stack contains the arguments and environment: 0(sp) argc 4(sp) argv[0] @@ -48,7 +53,8 @@ _start: mov.l @r15+,r5 mov r15, r6 -/* Push the fini func onto the stack */ +/* Push the stack_end, rtld_fini and fini func onto the stack */ +mov.l r6,@-r15 mov.l r4,@-r15 mov.l L_fini,r0 mov.l r0,@-r15 @@ -57,7 +63,7 @@ _start: mov.l L_main,r4 mov.l L_init,r7 -/* __uClibc_main (main, argc, argv, init, fini) */ +/* __uClibc_main (main, argc, argv, init, fini, rtld_fini, stack_end) */ /* Let the libc call main and exit with its return code. */ mov.l L_uClibc_main,r1 Hi Takashi, your point is correct and the patch looks fine. Looking again at the ld.so - _start flow, yes sh4 forces rtld_fini to be NULL (r4 = 0 set in dl-startup.h as you told), so this means that on sh4 we do not call the _dl_fini destructor, loosing eventually to call the destructors of the dependant shared objects. It should be simple enough to write a test showing this. Well, I've written the test and, as I thought, we do not call the destructor for any dependant shared objects. I'll spend a few time longer to look at what it's happening on glibc part, and eventually integrate your patch by setting the rtld_fini (6 ^ args) too. Indeed glibc (sysdeps/sh/dl-machine.h: _start) passes in r4 the _dl_fini instead of NULL. This makes dso's destructor get properly called. I'll see how to integrate a test case into the test-suite too. Full fix will come soon. Carmelo Thanks a lot, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/stdio
[EMAIL PROTECTED] wrote: Author: vda Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008) New Revision: 21683 Log: Factor out the core of vprintf() into separate function vprintf_internal, so that: * vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing, then calls vprintf_internal * vsnprintf, vdprintf.c, vasprintf.c use vprintf_internal directly This makes sprintf faster (since it doesn't do any locking) and stops it from pulling in fseek in static compile. Added: trunk/uClibc/libc/stdio/_vfprintf_internal.c trunk/uClibc/libc/stdio/_vfwprintf_internal.c Modified: trunk/uClibc/libc/stdio/Makefile.in trunk/uClibc/libc/stdio/_stdio.h trunk/uClibc/libc/stdio/_vfprintf.c trunk/uClibc/libc/stdio/vasprintf.c trunk/uClibc/libc/stdio/vdprintf.c trunk/uClibc/libc/stdio/vsnprintf.c trunk/uClibc/libc/stdio/vswprintf.c [SNIP] Modified: trunk/uClibc/libc/stdio/_vfprintf.c === --- trunk/uClibc/libc/stdio/_vfprintf.c 2008-04-09 11:38:48 UTC (rev 21682) +++ trunk/uClibc/libc/stdio/_vfprintf.c 2008-04-09 19:51:18 UTC (rev 21683) @@ -1198,7 +1198,7 @@ #endif /**/ -#if defined(L_vfprintf) || defined(L_vfwprintf) +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal) /* We only support ascii digits (or their USC equivalent codes) in * precision and width settings in *printf (wide) format strings. @@ -1207,14 +1207,15 @@ static size_t _charpad(FILE * __restrict stream, int padchar, size_t numpad); -#ifdef L_vfprintf +#ifdef L__vfprintf_internal -#define VFPRINTF vfprintf +#define VFPRINTF_internal _vfprintf_internal #define FMT_TYPE char #define OUTNSTR _outnstr #define STRLEN strlen #define _PPFS_init _ppfs_init -#define OUTPUT(F,S) fputs_unlocked(S,F) +/* Pulls in fseek: #define OUTPUT(F,S) fputs_unlocked(S,F) */ +#define OUTPUT(F,S) __stdio_fwrite((const unsigned char *)(S),strlen(S),(F)) Hi Denys, while running some test on nptl bracn with runtime assertion enabled, I've discoverd that this change is causing uclibc aborting due to an assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works fine. I'd like to understand better the rationale behind and I'm wondering if the problem is present in trunk with other arch than sh4. To exploit the problem you simply need to call a printf with a format string (i.e. printf(val=%d\n,x) ). Please let me know your comments, thanks. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/stdio
Carmelo AMOROSO wrote: [EMAIL PROTECTED] wrote: Author: vda Date: 2008-04-09 12:51:18 -0700 (Wed, 09 Apr 2008) New Revision: 21683 Log: Factor out the core of vprintf() into separate function vprintf_internal, so that: * vprintf() does locking and __STDIO_STREAM_TRANS_TO_WRITE thing, then calls vprintf_internal * vsnprintf, vdprintf.c, vasprintf.c use vprintf_internal directly This makes sprintf faster (since it doesn't do any locking) and stops it from pulling in fseek in static compile. Added: trunk/uClibc/libc/stdio/_vfprintf_internal.c trunk/uClibc/libc/stdio/_vfwprintf_internal.c Modified: trunk/uClibc/libc/stdio/Makefile.in trunk/uClibc/libc/stdio/_stdio.h trunk/uClibc/libc/stdio/_vfprintf.c trunk/uClibc/libc/stdio/vasprintf.c trunk/uClibc/libc/stdio/vdprintf.c trunk/uClibc/libc/stdio/vsnprintf.c trunk/uClibc/libc/stdio/vswprintf.c [SNIP] Modified: trunk/uClibc/libc/stdio/_vfprintf.c === --- trunk/uClibc/libc/stdio/_vfprintf.c 2008-04-09 11:38:48 UTC (rev 21682) +++ trunk/uClibc/libc/stdio/_vfprintf.c 2008-04-09 19:51:18 UTC (rev 21683) @@ -1198,7 +1198,7 @@ #endif /**/ -#if defined(L_vfprintf) || defined(L_vfwprintf) +#if defined(L__vfprintf_internal) || defined(L__vfwprintf_internal) /* We only support ascii digits (or their USC equivalent codes) in * precision and width settings in *printf (wide) format strings. @@ -1207,14 +1207,15 @@ static size_t _charpad(FILE * __restrict stream, int padchar, size_t numpad); -#ifdef L_vfprintf +#ifdef L__vfprintf_internal -#define VFPRINTF vfprintf +#define VFPRINTF_internal _vfprintf_internal #define FMT_TYPE char #define OUTNSTR _outnstr #define STRLEN strlen #define _PPFS_init _ppfs_init -#define OUTPUT(F,S) fputs_unlocked(S,F) +/* Pulls in fseek: #define OUTPUT(F,S) fputs_unlocked(S,F) */ +#define OUTPUT(F,S) __stdio_fwrite((const unsigned char *)(S),strlen(S),(F)) Hi Denys, while running some test on nptl bracn with runtime assertion enabled, I've discoverd that this change is causing uclibc aborting due to an assert(bytes) in __stdio_fwrite, while calling fputs_unlocked all works fine. I'd like to understand better the rationale behind and I'm wondering if the problem is present in trunk with other arch than sh4. To exploit the problem you simply need to call a printf with a format string (i.e. printf(val=%d\n,x) ). Please let me know your comments, thanks. Carmelo Hi, doing further analysis, I've figure out why we fail using __stdio_fwrite. Basically __stdio_fwrite expects at least 1 bytes. fputs_unlocked(S,F) calls fwrite_unlocked and this calls __stdio_fwrite only if bytes to be written are 0, otherwise simply returs 0 (that is correct). During the parsing of format spec it could happen that __stdio_fwrite is called passing an empty string and with assertion enabled it will abort. So, I think that using fputs_unlocked is fine, I don't see any other reasons for calling __stdio_fwrite directly. Cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Changing runtime directory
Khem Raj wrote: On (27/07/08 16:31), [EMAIL PROTECTED] wrote: Hello! I am pretty new to this mailing list and the whole uclibc thing and I ave a question: I downloaded the pre-installed buildroot toolchain, mounted the image, copied my sources in it and chrooted in the toolchain. I am building my target system in /target/ I can simply compile uClibc for my target system without any errors. But when I chose make PREFIX=/target install_runtime the uClibc-runtimes are installed in /target/usr/i586-linux-uclibc/lib. I think, that this is not a big problem, but is it possible to install it just in /target/lib ? what happens when you set RUNTIME_PREFIX=/target/lib either in .config or on make commandline. Thx -Khem Hi, to achieve what you want, you need to set RUNTIME_PREFIX=target root dir (/target in your case) and set in .config the following SHARED_LIB_LOADER_PREFIX=/lib RUNTIME_PREFIX=/ DEVEL_PREFIX=/usr If you have other doubts, please post your .config. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
