Future branch status

[Peter Mazinger]

Hi,

generally seen, the __NR_X64 syscalls do not exist on 64bit archs (like __NR_fcntl64), on these (64bit) archs, the name used is __NR_X (__NR_fcntl). So, if we want to provide the same interface on 32 and 64 bit archs, we need to provide the "versionsort / 32bit and versionsort64", as examples on all archs independently of 32/64 bit. On 64 bit archs versionsort = versionsort64.

Personally, the *LFS* config option should be removed and LFS enabled all over the place (applies to any "old_time" stuff as well).
We should provide only the "newer" version of the function.
My patches are not finished here (only 1/4 of them are in the future branch), my intention is to get rid of X() and X64() at all (even if glibc does it, this does not mean, that it has to be followed), leaving only X() with functionality for both.

Regards, Peter

-------- Original-Nachricht --------
> Datum: Tue, 24 Apr 2012 16:14:46 +0200
> Von: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
> An: Peter Mazinger <ps.m at gmx.net>
> CC: Khem Raj <raj.khem at gmail.com>, uclibc at uclibc.org, Carmelo AMOROSO <carmelo.amoroso at st.com>
> Betreff: Re: Future branch status

> Peter,

> On 23 April 2012 19:49, Carmelo AMOROSO <carmelo.amoroso at st.com> wrote:
> > On 23/04/2012 18.12, Bernhard Reutner-Fischer wrote:
> >> On 21 April 2012 19:36, Khem Raj <raj.khem at gmail.com> wrote:
> >>> On Sat, Apr 21, 2012 at 1:37 AM, Bernhard Reutner-Fischer
> >>> <rep.dot.nop at gmail.com> wrote:
> >>>>
> >>>> Let's leave this out for the merge and look at it after the merge
> >>>> (unless you can fix it for the failing arches), ok?
> >>>>
> >>>> I'm going through the other commits during the weekend (I have a few
> >>>> remarks).
> >>>>
> >>>
> >>> Yes thats a good plan I think. However there are some cleanup fixes
> that
> >>> are sort of obvious and some bug fixes that we can safely take after
> testing
> >>
> >> My notes so far:
> >>
> >> include/sched.h: remove __clone{,2}
> >> libc/misc/internals/__uClibc_main.c: vis of __uclibc_progname? Why not
> hidden?
> >>                                    : _dl_skip_args
> only for SH ?!
> >
> > It depends on how the asm SH startup code handle __dl_skip_args, that it
> > is not aligned with other archs, when running in standalone-mode-
> >
> > Something we should look at, indeed. I'll discuss with my colleague.
> >
> >> libc/misc/internals/tempname.h: __gen_tempname duplicated in nptl.. vis
> public?
> >> libc/sysdeps/linux/arm/posix_fadvise.c: __NR___syscall_arm_fadvise64_64
> ?
> >> "[PATCH 382/408] linuxthreads: use __UCLIBC_HAS_TLS__ consistently"
> impossible
> >>       impossible combo for __resp
> >> syslog.c: disable locking in setlogmask (why?)
> >> pread_write.c: endianess broken? if so use __LONG_LONG_PAIR() !
> 
> I get alot of errors when compiling for x86_64 (i.e. 64bit), e.g.:
> 
> libc/misc/dirent/versionsort.c:16:1: warning: return type defaults to
> 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: warning: function declaration
> isn't a prototype [-Wstrict-prototypes]
> libc/misc/dirent/versionsort.c: In function 'strongs_alias_untyped':
> libc/misc/dirent/versionsort.c:16:1: warning: type of 'versionsort'
> defaults to 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: warning: type of 'versionsort64'
> defaults to 'int' [enabled by default]
> libc/misc/dirent/versionsort.c:16:1: error: expected '{' at end of input
> libc/misc/dirent/versionsort.c:16:1: warning: control reaches end of
> non-void function [-Wreturn-type]
> 
> In the respective commit, you write:
> 
> versionsort*.c, alphasort*.c: do not need *64 compiled for __WORDSIZE = 64
> 
> but for this to really happen one would, i think, have to say:
> diff --git a/libc/misc/dirent/versionsort.c
> b/libc/misc/dirent/versionsort.c
> index e298728..6269862 100644
> --- a/libc/misc/dirent/versionsort.c
> +++ b/libc/misc/dirent/versionsort.c
> @@ -12,6 +12,6 @@ int versionsort(const struct dirent **a, const
> struct dirent **b)
>  {
>  	return strverscmp((*a)->d_name, (*b)->d_name);
>  }
> -#if defined __UCLIBC_HAS_LFS__ && __WORDSIZE == 64
> +#if defined __UCLIBC_HAS_LFS__ && __WORDSIZE != 64
>  strongs_alias_untyped(versionsort,versionsort64)
>  #endif
> 
> Since this also happens in other such places like below, i must be
> doing something wrong?
> Please elaborate how you meant the hunks above and below to work.
> 
> fcntl{64,}.c: fix x86_64 && LFS duly:
> -#if defined __UCLIBC_HAS_LFS__ && (__WORDSIZE == 64 || !defined
> __NR_fcntl64)
> +#if defined __UCLIBC_HAS_LFS__ && (__WORDSIZE != 64 && defined
> __NR_fcntl64)
> 
> thanks,

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de