Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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=20625&view=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

Re: Does the svn offer anonymous http access?

[Carmelo AMOROSO]

163Xman wrote:
>  Hello all,
>   It seems i am behind a firewall, and not able to access svn protocol.
> 
> Songmao
>  
>  
Yes, http is not supported. svn protocol requires same HTTP requests 
that your firewall should allow.

Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Revision 20625, opendir

[Carmelo AMOROSO]

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.

[Carmelo AMOROSO]

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: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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=20625&view=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


___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: [PATCH] sh: fix __HAVE_SHARED__ condition in crti.S.

[Carmelo AMOROSO]

Paul Mundt wrote:
> On Wed, Sep 03, 2008 at 05:47:56PM +0200, Carmelo AMOROSO wrote:
>> 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 ?
>>
> Well, Sugioka-san has 3.04 and 2.97 binaries, but nothing beyond that.
> On the other hand, we're not even realistically able to build the kernel
> with anything that old, so it's likely not even worth bothering with.
> 
> Given that, and the fact we don't have a test case that manages to trip
> up the logic, we may as well just kill it off. The logic has been
> completely inverted from day one also, so it's unlikely anyone seriously
> tested or depended on this in the first place. If there were compiler
> issues earlier on, the inverted logic would obviously not have fixed this
> either. So, how about this?
> 
Absolutely agreed. That's what I was thinking.
Please commit.

Carmelo
> ---
> 
>  libc/sysdeps/linux/sh/crti.S |   23 ---
>  1 file changed, 23 deletions(-)
> 
> Index: libc/sysdeps/linux/sh/crti.S
> ===
> --- libc/sysdeps/linux/sh/crti.S  (revision 23132)
> +++ libc/sysdeps/linux/sh/crti.S  (working copy)
> @@ -1,5 +1,3 @@
> -#include 
> -
>   .file   "crti.S"
>   .text
>   
> @@ -12,19 +10,10 @@
>   mov.l   r12,@-r15
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
> -#ifndef __HAVE_SHARED__
> - mova.L6,r0
> - mov.l   .L6,r12
> - add r0,r12
> -#endif   
>   mov r15,r14
>   bra 1f
>   nop
>   .align 2
> -#ifndef __HAVE_SHARED__
> -.L6:
> - .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
>   
>   .section .fini
> @@ -37,19 +26,7 @@
>   mov.l   r14,@-r15
>   sts.l   pr,@-r15
>   mov r15,r14
> -#ifndef __HAVE_SHARED__
> - mov.l   .L11,r12
> - mova.L11,r0
> - add r0,r12
> -#endif   
> -
>   bra 1f
>   nop
>   .align 2
> -#ifndef __HAVE_SHARED__
> -.L11:
> - .long   _GLOBAL_OFFSET_TABLE_
> -#endif
>  1:
> - 
> - .ident  "GCC: (GNU) 3.3.2"
> 

___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

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=20625&view=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: [PATCH] locale test fix.

[Carmelo Amoroso]

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

[Carmelo Amoroso]

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]

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: status of 0.9.30 release

[Carmelo Amoroso]

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&#x

Re: Has uClibc passed the LTP tests?

[Carmelo AMOROSO]

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 ... 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: fadvise gclibc vs uclibc

[Carmelo AMOROSO]

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]

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]

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]

[Carmelo AMOROSO]

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])

[Carmelo AMOROSO]

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=) 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 

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

[Carmelo AMOROSO]

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: set fPIC option for librt

[Carmelo AMOROSO]

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: Why does uclibc.org have server problems?

[Carmelo AMOROSO]

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?

[Carmelo AMOROSO]

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?

[Carmelo AMOROSO]

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: [PATCH] Xtensa strcoll problem with LOCALE support

[Carmelo AMOROSO]

Bob Wilson wrote:
> The Xtensa-specific strcmp.S file is testing the __UCLIBC_HAS_LOCALE__ 
> macro but it does not include , so that macro is never 
> defined.  This causes problems with strcoll when locale support is enabled.
> 
> 
> 
> 
> 
> ___
> uClibc mailing list
> uClibc@uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
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)

Cheers,
Carmelo

___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: fadvise gclibc vs uclibc

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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]

[Carmelo AMOROSO]

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;

Re: make clean/distclean broken in svn 23359?

[Carmelo AMOROSO]

Rob Landley wrote:
> On Monday 15 September 2008 10:41:42 Carmelo AMOROSO wrote:
>> 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
> 
> I just did an svn update and a fresh distclean, and it didn't fix anything 
> here.  I'm not sure what the difference is between my system and yours...
> 
> Rob
> 
Rob,
my tree is taken from trunk as is.
When doing make clean, can you see the line
rm -f ./libm/{,*/,*/*/}*.{o,os,oS,a} ?

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]

[Carmelo AMOROSO]

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?

[Carmelo AMOROSO]

Rob Landley wrote:
> On Monday 15 September 2008 10:57:37 Carmelo AMOROSO wrote:
>> 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.
> 
> Consider this a follow-up then.
> 
>>> 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)
> 
> Ok, questions:
> 
> 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.

> 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.
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.

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.


> 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. 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.
Remeber that, even when merged, NPTL is available only for 3 archs at 
the time being.
> Rob
> 
Comments are welcome.
Carmelo


___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: confirmed working NPTL revision?

[Carmelo AMOROSO]

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?

[Carmelo AMOROSO]

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?

[Carmelo AMOROSO]

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: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr & __tls_get_addr)

[Carmelo AMOROSO]

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  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 ] 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]

[Carmelo AMOROSO]

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
<<>>
tag=posix_fadvise01 stime=946685502
cmdline=" posix_fadvise01"
contacts=""
analysis=exit
initiation_status="ok"
<<>>
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
<<>>
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=3
<<>>
<<>>
tag=posix_fadvise01_64 stime=946685502
cmdline="   posix_fadvise01_64"
contacts=""
analysis=exit
initiation_status="ok"
<<>>
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
<<>>
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=3
<<>>
<<>>
tag=posix_fadvise02 stime=946685502
cmdline=" posix_fadvise02"
contacts="&q

Re: [PATCH] Xtensa strcoll problem with LOCALE support

[Carmelo AMOROSO]

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]

[Carmelo AMOROSO]

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: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]

[Carmelo AMOROSO]

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 ;-)

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]

[Carmelo AMOROSO]

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]

[Carmelo AMOROSO]

Fathi Boudra wrote:
> 
> fails to build on my config.
> 
>   LD 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

[Carmelo AMOROSO]

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
> 
> #include
> .
> .
> .
> 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: libdl usage count wrapping

[Carmelo Amoroso]

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 
> 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 
> #include 
> #include 
> 
> #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) {
>   error

Re: [PATCH] posix_favise{64} error handling fixes [was Re: fadvise gclibc vs uclibc]

[Carmelo AMOROSO]

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]

[Carmelo AMOROSO]

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.

[Carmelo AMOROSO]

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.

[Carmelo AMOROSO]

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

[PATCH] __syscall_rt_sigaction should use kernel_sigaction

[Carmelo AMOROSO]

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 
+#include 
 
-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] all arches: c89 touchup

[Carmelo Amoroso]

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

Re: in function 'memcpy': undefined reference to `WORD_COPY_FWD'

[Carmelo AMOROSO]

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]

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] posix_fadvise for ppc32

[Carmelo Amoroso]

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, 

Re: SH2aeb support

[Carmelo Amoroso]

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: SH2aeb support

[Carmelo AMOROSO]

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: fix building with locales

[Carmelo AMOROSO]

Bernhard Reutner-Fischer wrote:
> Hi,
> 
> Currently locales are broken when you have:
> 
> $ grep LOCALE .config
> UCLIBC_HAS_LOCALE=y
> UCLIBC_PREGENERATED_LOCALE_DATA=y (or =n)
> UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA=y (or =n)
> UCLIBC_HAS_XLOCALE=y (doesn't matter)
> 
> A couple of headers are not found, most notably uClibc_ctype.h, and
> extra/locale/* falls apart in various funny ways.
> 
> In an attempt to cure this, i'm proposing something like the
> attached patchlet (which is untested).
> 
> So i'm asking anybody who uses locale to try the attached patch and to
> let me know if it builds fine now (with -j1; I'm pretty sure that -j
> will not work yet, we can fix that later).
> 
> TIA,
> Bernhard
> 
Hi Bernhard,
I'll try the path (not immediately anyway, too busy in other stuff),
but I don't have problem in compiling with locale (except for -j2).

I have some changes in my branch in Makefile regarding headers target,
that at this point are doing the difference. I'll check them too.

Carmelo
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: svn commit: trunk/uClibc/test/misc

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: aldot
> Date: 2008-10-09 03:46:42 -0700 (Thu, 09 Oct 2008)
> New Revision: 23630
> 
> Log:
> - fix test. Tests are normal userspace and are _not_ part of the libc itself
>   Thanks to Tobias Poschwatta for pointing out this error.
> 
> 
Sorry. my fault.

> Modified:
>trunk/uClibc/test/misc/tst-scandir.c
> 
> 
> Changeset:
> Modified: trunk/uClibc/test/misc/tst-scandir.c
> ===
> --- trunk/uClibc/test/misc/tst-scandir.c  2008-10-09 05:06:42 UTC (rev 
> 23629)
> +++ trunk/uClibc/test/misc/tst-scandir.c  2008-10-09 10:46:42 UTC (rev 
> 23630)
> @@ -3,7 +3,7 @@
>  
>  int skip_all(const struct dirent *dirbuf)
>  {
> - __set_errno(EBADF);
> + errno = EBADF;
>   return 0;
>  }
>  
> 
> ___
> 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

Re: How goes the -rc2 todo list?

[Carmelo Amoroso]

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: uClibc system call to get stack trace information

[Carmelo AMOROSO]

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 
> 
>  
> 
> 
> 
> 
> 
> ___
> 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: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr & __tls_get_addr)

[Carmelo Amoroso]

Rob Landley wrote:
> On Wednesday 17 September 2008 06:29:34 Carmelo AMOROSO wrote:
>> 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
> 
> You say this while top-posting. :)
> 
> Is your fix for uClibc, or uClibc++?  This appears to be a uClibc++ issue, 
> how 
> do you fix it in uClibc?
> 
Hi Rob,
the fix is in uClibc, it consists of moving the implementation from ld.so
and libdl.a to libc.so/libc.a.
I posted a pacth months ago, but, my fault, never integrated into trunk.
See threads http://www.uclibc.org/lists/uclibc/2008-January/018969.html

I hope to re-start my active contribution soo, once finished a my top priority
kernel task.

Cheers,
Carmelo
> Rob
> ___
> 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] __syscall_rt_sigaction should use kernel_sigaction

[Carmelo Amoroso]

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: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr & __tls_get_addr)

[Carmelo AMOROSO]

Rob Landley wrote:
> On Sunday 26 October 2008 01:49:53 Carmelo Amoroso wrote:
>> Rob Landley wrote:
>>> On Wednesday 17 September 2008 06:29:34 Carmelo AMOROSO wrote:
>>>> 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
>>> You say this while top-posting. :)
>>>
>>> Is your fix for uClibc, or uClibc++?  This appears to be a uClibc++
>>> issue, how do you fix it in uClibc?
>> Hi Rob,
>> the fix is in uClibc, it consists of moving the implementation from ld.so
>> and libdl.a to libc.so/libc.a.
> 
> Could you give me a little more detail about exactly what the issue is?  (Ok, 
> I read the patch, but "it breaks" and "this fixes it" doesn't really help me 
> form a good mental model of what's going on here...)
> 
> The error message Flemming reported was trying to access a tls symbol, which 
> uClibc still doesn't support...?  (Or is this a patch to the nptl branch?)
> 
> Rob
> 
Ok,
I read the message of Flemming not carefully... the patch I proposed was 
referring to the dl_iterate_phdr missing symbols.

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'

Indeed, as he replied after my post, the reference to the __tls_get_addr 
function was due a configuration error of uClibc++.

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).

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: Fwd: Cannot build uclibc++ against toolchain (dl_iterate_phdr & __tls_get_addr)

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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: Strange location of kernel-features.h

[Carmelo AMOROSO]

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
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:uclibc-cvs-
>> [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
>> Sent: den 9 september 2008 14:02
>> To: [EMAIL PROTECTED]
>> Subject: svn commit: trunk/uClibc: libc/sysdeps/linux/common libpthread/lin 
>> etc...
>>
>> Author: carmelo
>> Date: 2008-09-09 05:01:37 -0700 (Tue, 09 Sep 2008)
>> New Revision: 23363
>>
>> Log:
>> Use getdents syscall if kernel provide supports for this
>> instead of relying upon getdents64.
>>
>> Signed-off-by: Filippo Arcidiacono <[EMAIL PROTECTED]>
>> Signed-off-by: Carmelo Amoroso <[EMAIL PROTECTED]>
>>
>>
>> Modified:
>>trunk/uClibc/libc/sysdeps/linux/common/getdents.c
>>trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-features.h
>>
>>
>> Changeset:
>> Modified: trunk/uClibc/libc/sysdeps/linux/common/getdents.c
>> ===
>> --- trunk/uClibc/libc/sysdeps/linux/common/getdents.c   2008-09-09
>> 08:50:18 UTC (rev 23362)
>> +++ trunk/uClibc/libc/sysdeps/linux/common/getdents.c   2008-09-09
>> 12:01:37 UTC (rev 23363)
>> @@ -18,8 +18,7 @@
>>  #include 
>>
>>  /* With newer versions of linux, the getdents syscall returns d_type
>> - * information after the name field.  Someday, we should add support for
>> - * that instead of always calling getdents64 ...
>> + * information after the name field.
>>   *
>>   * See __ASSUME_GETDENTS32_D_TYPE in glibc's kernel-features.h for specific
>>   * version / arch details.
>> @@ -39,14 +38,42 @@
>>
>>  ssize_t __getdents (int fd, char *buf, size_t nbytes) attribute_hidden;
>>
>> -#if ! defined __UCLIBC_HAS_LFS__ || ! defined __NR_getdents64
>> +#define __NR___syscall_getdents __NR_getdents
>> +static inline _syscall3(int, __syscall_getdents, int, fd, unsigned char *, 
>> kdirp, size_t, count);
>>
>> +#ifdef __ASSUME_GETDENTS32_D_TYPE
>> +ssize_t __getdents (int fd, char *buf, size_t nbytes)
>> +{
>> +   ssize_t retval;
>> +
>> +   retval = __syscall_getdents(fd, (unsigned char *)buf, nbytes);
>> +
>> +   /* The kernel added the d_type value after the name.  Change
>> +   this now.  */
>> +   if (retval != -1) {
>> +   union {
>> +   struct kernel_dirent k;
>> +   struct dirent u;
>> +   } *kbuf = (void *) buf;
>> +
>> +   while ((char *) kbuf < buf + retval) {
>> +   char d_type = *((char *) kbuf + kbuf->k.d_reclen - 
>> 1);
>> +   memmove (kbuf->u.d_name, kbuf->k.d_name,
>> +   strlen (kbuf->k.d_name) + 1);
>> +   kbuf->u.d_type = d_type;
>> +
>> +   kbuf = (void *) ((char *) kbuf + kbuf->k.d_reclen);
>> +   }
>> +   }
>> +
>> +   return retval;
>> +}
>> +
>> +#elif ! defined __UCLIBC_HAS_LFS__ || ! defined __NR_getdents64
>> +
>>  /* Experimentally off - libc_hidden_proto(memcpy) */
>>  libc_hidden_proto(lseek)
>>
>> -#define __NR___syscall_getdents __NR_getdents
>> -static __inline__ _syscall3(int, __syscall_getdents, int, fd, unsigned char 
>> *, kdirp, size_t, count);
>> -
>>  ssize_t __getdents (int fd, char *buf, size_t nbytes)
>>  {
>>  struct dirent *dp;
>>
>> Modified: trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-
>> features.h
>> ===
>> -

Re: [RFC] Fix various compiler warning

[Carmelo AMOROSO]

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: NPTL branch almost merged with trunk @ rev 22714

[Carmelo AMOROSO]

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 synch&merge 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: Fun with the dynamic loader.

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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 
+#include 
+#include 
+
+#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 
+#include 
+
+#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_ini

Re: linuxthreads changes from upstream

[Carmelo Amoroso]

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: libc_hidden_proto removal

[Carmelo AMOROSO]

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: Strange location of kernel-features.h

[Carmelo AMOROSO]

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)

[Carmelo AMOROSO]

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: How to build JFFS2 image?

[Carmelo AMOROSO]

×èíêîâ Àíäðåé 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: svn commit: branches/uClibc-nptl/libc/inet

[Carmelo AMOROSO]

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: testsuite: wcsxfrm

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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/include: arpa netinet rpc sys

[Carmelo AMOROSO]

[EMAIL PROTECTED] wrote:
> Author: carmelo
> Date: 2008-11-26 07:45:55 -0800 (Wed, 26 Nov 2008)
> New Revision: 24158
> 
> Log:
> Synch with trunk @ 24157
> Step 11: More libc_hidden_proto removal
> 
> 

I know... it does not compile.. please wait :-)

Carmelo
> Modified:
>branches/uClibc-nptl/include/arpa/inet.h
>branches/uClibc-nptl/include/arpa/nameser.h
>branches/uClibc-nptl/include/assert.h
>branches/uClibc-nptl/include/ctype.h
>branches/uClibc-nptl/include/dirent.h
>branches/uClibc-nptl/include/err.h
>branches/uClibc-nptl/include/fcntl.h
>branches/uClibc-nptl/include/fnmatch.h
>branches/uClibc-nptl/include/glob.h
>branches/uClibc-nptl/include/grp.h
>branches/uClibc-nptl/include/langinfo.h
>branches/uClibc-nptl/include/libc-internal.h
>branches/uClibc-nptl/include/libc-symbols.h
>branches/uClibc-nptl/include/locale.h
>branches/uClibc-nptl/include/malloc.h
>branches/uClibc-nptl/include/mntent.h
>branches/uClibc-nptl/include/netinet/ether.h
>branches/uClibc-nptl/include/netinet/in.h
>branches/uClibc-nptl/include/pwd.h
>branches/uClibc-nptl/include/rpc/auth.h
>branches/uClibc-nptl/include/rpc/auth_des.h
>branches/uClibc-nptl/include/rpc/auth_unix.h
>branches/uClibc-nptl/include/rpc/clnt.h
>branches/uClibc-nptl/include/rpc/netdb.h
>branches/uClibc-nptl/include/rpc/pmap_clnt.h
>branches/uClibc-nptl/include/rpc/pmap_prot.h
>branches/uClibc-nptl/include/rpc/pmap_rmt.h
>branches/uClibc-nptl/include/rpc/rpc.h
>branches/uClibc-nptl/include/rpc/rpc_msg.h
>branches/uClibc-nptl/include/rpc/svc.h
>branches/uClibc-nptl/include/rpc/svc_auth.h
>branches/uClibc-nptl/include/rpc/xdr.h
>branches/uClibc-nptl/include/search.h
>branches/uClibc-nptl/include/shadow.h
>branches/uClibc-nptl/include/signal.h
>branches/uClibc-nptl/include/stdio.h
>branches/uClibc-nptl/include/stdio_ext.h
>branches/uClibc-nptl/include/stdlib.h
>branches/uClibc-nptl/include/string.h
>branches/uClibc-nptl/include/sys/ioctl.h
>branches/uClibc-nptl/include/sys/mman.h
>branches/uClibc-nptl/include/sys/poll.h
>branches/uClibc-nptl/include/sys/resource.h
>branches/uClibc-nptl/include/sys/select.h
>branches/uClibc-nptl/include/sys/socket.h
>branches/uClibc-nptl/include/sys/stat.h
>branches/uClibc-nptl/include/sys/statfs.h
>branches/uClibc-nptl/include/sys/statvfs.h
>branches/uClibc-nptl/include/sys/syslog.h
>branches/uClibc-nptl/include/sys/time.h
>branches/uClibc-nptl/include/sys/times.h
>branches/uClibc-nptl/include/sys/timex.h
>branches/uClibc-nptl/include/sys/utsname.h
>branches/uClibc-nptl/include/sys/wait.h
>branches/uClibc-nptl/include/termios.h
>branches/uClibc-nptl/include/time.h
>branches/uClibc-nptl/include/ttyent.h
>branches/uClibc-nptl/include/unistd.h
>branches/uClibc-nptl/include/utime.h
>branches/uClibc-nptl/include/utmp.h
>branches/uClibc-nptl/include/wchar.h
>branches/uClibc-nptl/include/wctype.h
>branches/uClibc-nptl/include/wordexp.h
> 
> 
> Changeset:
> 
> Sorry, the patch is too large to include (3830 lines).
> Please use ViewCVS to see it!
> 
> http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=24158
> ___
> 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

Re: testsuite: wcsxfrm

[Carmelo Amoroso]

Filippo ARCIDIACONO wrote:
>  
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Carmelo AMOROSO
>> Sent: Tuesday, November 25, 2008 5:53 PM
>> To: Tobias Poschwatta
>> Cc: uclibc@uclibc.org
>> Subject: 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.
> The rigth solution IMO is run the tests setting only the C locale
> The others one aren't supported when __UCLIBC_HAS_LOCALE__ is off.
> Now there are few failures (tst_iswctype, tst_wcswidth and tst_wcwidth)
> I'm investigating on their.
> The problem has been fixed into the trunk revision 24155.
>> Carmelo
> Cheers,
> Filippo.
>> ___

Thanks Filippo. Please TObia may you give 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
> 

___
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

[Carmelo AMOROSO]

[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

[Carmelo AMOROSO]

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: svn commit: trunk/uClibc: include libc/sysdeps/linux/sh/bits

[Carmelo Amoroso]

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

[Carmelo Amoroso]

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: Regarding setting of errno on System Call fail.

[Carmelo Amoroso]

Arvind Kumar wrote:
> Hello!
> Any clue will be appreciated.
> I am running my application on target machine which contain uclibc 
> version 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?

[Carmelo AMOROSO]

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: branches/uClibc-nptl: include libc/misc/internals

[Carmelo AMOROSO]

[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]

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

[Carmelo AMOROSO]

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: svn commit: branches/uClibc-nptl/libpthread: nptl nptl/sysdeps/generic nptl/sysdeps/p etc...

[Carmelo Amoroso]

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: Strange location of kernel-features.h

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:

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


Hi All,
the attached patch try to address the issue raised by Peter.

Let me know.
Cheers,
Carmelo


move_kernel-features.patch
Description: application/mbox
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

Re: Strange location of kernel-features.h

[Carmelo Amoroso]

Khem Raj wrote:
> I dont see where the file got added after removing.
> 
libc/sysdeps/linux/common/bits.
indeed it's missing from the patch... strange.

> On Thu, Dec 4, 2008 at 5:41 AM, Carmelo AMOROSO <[EMAIL PROTECTED]> wrote:
>> Carmelo AMOROSO wrote:
>>> 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
>>>
>> Hi All,
>> the attached patch try to address the issue raised by Peter.
>>
>> Let me know.
>> 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
> 

___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

NPTL branch temporarily broken

[Carmelo AMOROSO]

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: [PATCH] bug in __check_pf() (getaddrinfo.c)

[Carmelo Amoroso]

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)

[Carmelo Amoroso]

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)

[Carmelo Amoroso]

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

Re: __libc_xxx functions: what are they?

[Carmelo Amoroso]

Denys Vlasenko wrote:
> Hi,
> 
> We have the following aliases witj __libc prefix:
> 
> # grep -rh $'[ \t]__libc_[a-z_0-9]*;$' . | sort | uniq | grep __typeof
> extern __typeof(accept) __libc_accept;
> extern __typeof(close) __libc_close;
> extern __typeof(connect) __libc_connect;
> extern __typeof(creat) __libc_creat;
> extern __typeof(creat64) __libc_creat64;
> extern __typeof(fcntl) __libc_fcntl;
> extern __typeof(fcntl64) __libc_fcntl64;
> extern __typeof(fork) __libc_fork;
> extern __typeof(fstatfs) __libc_fstatfs;
> extern __typeof(fsync) __libc_fsync;
> extern __typeof(getdomainname) __libc_getdomainname;
> extern __typeof(getpid) __libc_getpid;
> extern __typeof(lseek) __libc_lseek;
> extern __typeof(lseek64) __libc_lseek64;
> extern __typeof(msync) __libc_msync;
> extern __typeof(nanosleep) __libc_nanosleep;
> extern __typeof(open) __libc_open;
> extern __typeof(open64) __libc_open64;
> extern __typeof(pause) __libc_pause;
> extern __typeof(poll) __libc_poll;
> extern __typeof(pread) __libc_pread;
> extern __typeof(pread64) __libc_pread64;
> extern __typeof(pselect) __libc_pselect;
> extern __typeof(pwrite) __libc_pwrite;
> extern __typeof(pwrite64) __libc_pwrite64;
> extern __typeof(read) __libc_read;
> extern __typeof(readv) __libc_readv;
> extern __typeof(recv) __libc_recv;
> extern __typeof(recvfrom) __libc_recvfrom;
> extern __typeof(recvmsg) __libc_recvmsg;
> extern __typeof(select) __libc_select;
> extern __typeof(send) __libc_send;
> extern __typeof(sendmsg) __libc_sendmsg;
> extern __typeof(sendto) __libc_sendto;
> extern __typeof(sigaction) __libc_sigaction;
> extern __typeof(sigsuspend) __libc_sigsuspend;
> extern __typeof(statfs) __libc_statfs;
> extern __typeof(system) __libc_system;
> extern __typeof(tcdrain) __libc_tcdrain;
> extern __typeof(wait) __libc_wait;
> extern __typeof(waitpid) __libc_waitpid;
> extern __typeof(write) __libc_write;
> extern __typeof(writev) __libc_writev;
> 
> I do not see any explanation what are these?
> 
> I do see that some of them are used from libpthread, but
> many are not (__libc_accept, __libc_getdomainname...).
> 
> One purpose I might imagine if to make sure you are using
> libc implementation of a function, not something from
> another library...
> 
IIRC, this is one of the reason.

> Anyone knows better?

probably these were intended to be used with
libc_hidden_proto/defs for avoing PLT entries
when called from within libc itself... but now
it should be the case any more.
> --
> 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: NPTL branch temporarily broken

[Carmelo AMOROSO]

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: NPTL branch temporarily broken

[Carmelo AMOROSO]

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.

> 
>> ___
>> 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: NPTL branch temporarily broken

[Carmelo AMOROSO]

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

[Carmelo AMOROSO]

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