Re: Upgrading uClibc in uClinux distro
On Wed, Jul 6, 2011 at 20:01, Gilles wrote: > On Wed, 6 Jul 2011 10:11:24 +0200, Thomas Petazzoni wrote: > Pardon my newbie question, but I thought Buildroot was just a set of > Makefiles to build an image that included the kernel and some > applications, ie. it wasn't specific to a Linux source code. > > So what do you mean by "Buildroot should be an alternative to uClinux > to build embedded Linux systems"? and the uClinux-dist is simply a set of Makefiles to build an image that included the kernel and some applications. the term "uClinux" to refer to the Linux kernel is horribly antiquated and really needs to die. the kernel coming from uClinux.org nowadays is simply another vendor kernel ... it's full of patches to add drivers, boards, and fix bugs in random arches. you can take the kernel from kernel.org and run it on a Blackfin system unmodified. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Upgrading uClibc in uClinux distro
On Thu, Jul 7, 2011 at 12:06, Gilles wrote: > On Thu, 7 Jul 2011 12:02:16 -0400, Mike Frysinger wrote: >>die. the kernel coming from uClinux.org nowadays is simply another >>vendor kernel ... it's full of patches to add drivers, boards, and fix >>bugs in random arches. you can take the kernel from kernel.org and >>run it on a Blackfin system unmodified. > > I know this is the wrong ng to ask, but what would Gentoo-embedded > bring to non-MMU platforms like Blackfin that uClinux-dist doesn't > already provide? the "non-MMU" aspect makes no difference to the question. uClinux-dist provides a complete build system that easily generates rootfs/kernel images. Gentoo embedded can do the same, but requires a lot more manual interaction as there is no glue today to make the process nice (like kconfig). the upside is that Gentoo provides up-to-date packages for everything while uClinux-dist does not. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Upgrading uClibc in uClinux distro
On Tue, Jul 5, 2011 at 05:10, Ed W wrote: > Mike - just for interest, what do you do to run an up to date linux > install on blackfin? I see you posting commits to kernel and uclibc for > blackfin, so you presumably run something fairly bleeding edge? How > should technical end users develop against say uclibc 0.9.32? i usually build a small initramfs using the FLAT format (so my init/shell are statically linked), and then drop in up-to-date uClibc code from there to test. or i just use qemu > I also see you involved in gentoo-embedded - does gentoo provide a > platform to build for blackfin? Is uClinux still the best way to compile > applications? Gentoo embedded doesnt hardcode targets (ignoring KEYWORDS). so any target should "just work" out of the box with crossdev & friends (assuming the toolchain itself supports it). -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Upgrading uClibc in uClinux distro
On Thu, Jul 7, 2011 at 12:15, Gilles wrote: > On Thu, 7 Jul 2011 12:12:33 -0400, Mike Frysinger wrote: >> the upside is that Gentoo provides up-to-date packages >> for everything while uClinux-dist does not. > > Right, apps in uClinux-dist can be a bit old. Can we expect a > Blackfin-capable Gentoo-embedded in the coming months, or does it > require much more work? it doesnt require any more work than any other port. at some point, i'd like to create a fancy frontend like uClinux-dist/buildroot has, but that's going to be a while. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: proposal for CONFIG_EXPERIMENTAL
On Thu, Jul 7, 2011 at 15:47, Peter Mazinger wrote: > I am proposing to add CONFIG_EXPERIMENTAL to guard all config options that ive found this option to be wholly useless in the kernel. i dont see it being any different in any other project. what does seem to work is manually adding "(EXPERIMENTAL)" or "(DEPRECATED)" to the Kconfig line of text. > This way we limit the general bug reports to working configs, bugs are bugs. if you want to classify them "lower", bugzilla has a priority field in it already. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: proposal for CONFIG_EXPERIMENTAL
On Thu, Jul 7, 2011 at 16:29, Peter Mazinger wrote: > Von: Khem Raj >> On Thu, Jul 7, 2011 at 12:50 PM, Mike Frysinger wrote: >> > what does seem to work is manually adding "(EXPERIMENTAL)" or >> > "(DEPRECATED)" to the Kconfig line of text. >> >> yes that seems a good approach > > Even if I do not think, that people are reading the text (they are using > some preprepared .config files and are not confronted with the fact, that > they should read the text in Kconfig), I can live with that too ;-) only so far we can hold the hand of people building uClibc. we havent catered to the lowest common denominator in the past when it's been more hassle than benefit, and i dont think we should start. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: ipc.h struct layout fix
On Friday, July 08, 2011 10:05:35 Peter Mazinger wrote: > > On 07/07/11 20:41, Peter Mazinger wrote: > > >> This fixes a problem identified by Mark Salter on C6X big-endian > > >> systems. We should not use "unsigned short int mode"; the proper > > >> type is in theory mode_t, but here we need to use kernel_mode_t > > >> since this structure is used for communication with the kernel, and > > >> some targets have a 16-bit kernel_mode_t and 32-bit mode_t. > > > > > > haven't looked closely, but if this header gets installed on target, > > > [__]kernel_mode_t is not/should not be defined. If the structure is > > > not meant to be used on target, than it should be guarded (like > > > _LIBC), else we should use mode_t here and handle accordingly in > > > code. > > > > Accordingly meaning...? Should we translate kernel structures to user > > structures here? That would get really ugly. > > It is, we do that in some places already like xstatconv.c, where we provide > a common stat structure. The sigaction implementation had also similar > problems, at least 3 types of arch-specific structures are present, the > members are not even the same (or in same order), vda intended to make > changes, but sincerely I did not follow up how far the changes went. > > > Can't we ensure that the necessary type is defined somewhere? > > My understanding for a libc is that we try to expose to userspace a common > interface, hiding specialities of the kernel. Let's see what others > think... we resort to adding this layer of indirection between the kernel and C library users only when we dont have a choice. shuffling bytes around from one struct layout to the other is wasteful overhead ... i wouldnt take xstatconv as a golden standard to be replicated. also, Bernd is modifying a struct that has already been shipped to C library users. we can change very few things now without breaking the ABI. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: ipc.h struct layout fix
On Thursday, July 07, 2011 08:04:37 Bernd Schmidt wrote: > This fixes a problem identified by Mark Salter on C6X big-endian > systems. We should not use "unsigned short int mode"; the proper type is > in theory mode_t, but here we need to use kernel_mode_t since this > structure is used for communication with the kernel, and some targets > have a 16-bit kernel_mode_t and 32-bit mode_t. my concern here would be for big endian arches where kernel_mode_t is not a short. i think that would break the ABI for them if they're using the common ipc.h ? > Please also compare linux-2.6/include/asm-generic/ipcbuf.h, which uses > the same definition for mode/pad1 as the one introduced by the patch. right, but many of the ports predate the asm-generic code :). -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: ipc.h struct layout fix
On Sat, Jul 9, 2011 at 18:38, Bernd Schmidt wrote: > So, the list of those that have an int kernel_mode_t and use > common/bits/ipc.h is x86_64 and v850. v850 has "select > ARCH_LITTLE_ENDIAN" and x86_64 is known to be LE as well. looks fine then from that angle. i cant think of any reason to not merge it (other than i think some compilers barf on 0 length arrays, but we'll worry about that when it comes up). you have commit access already dont you ? -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: ipc.h struct layout fix
On Monday, July 11, 2011 08:23:26 Bernd Schmidt wrote: > I still need to worry about the problem Peter mentioned about > __kernel_mode_t not always being available. bits/kernel_types.h should be exported for all arches -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly
On Friday, July 01, 2011 17:50:15 Khem Raj wrote:
> --- a/include/sys/signalfd.h
> +++ b/include/sys/signalfd.h
> @@ -64,6 +64,15 @@ enum
> # define SFD_NONBLOCK SFD_NONBLOCK
>};
>
> +#elif defined __mips__
> +enum
> + {
> +SFD_CLOEXEC = 0200,
> +# define SFD_CLOEXEC SFD_CLOEXEC
> +SFD_NONBLOCK = 0200
> +# define SFD_NONBLOCK SFD_NONBLOCK
> + };
seems like this would be better as a bits/signalfd.h rather than inlining arch
ifdef checks all over the place
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly
On Tue, Jul 12, 2011 at 10:37, Khem Raj wrote:
> On 07/11/2011 08:39 PM, Mike Frysinger wrote:
>> On Friday, July 01, 2011 17:50:15 Khem Raj wrote:
>>> --- a/include/sys/signalfd.h
>>> +++ b/include/sys/signalfd.h
>>> @@ -64,6 +64,15 @@ enum
>>> # define SFD_NONBLOCK SFD_NONBLOCK
>>> };
>>>
>>> +#elif defined __mips__
>>> +enum
>>> + {
>>> + SFD_CLOEXEC = 0200,
>>> +# define SFD_CLOEXEC SFD_CLOEXEC
>>> + SFD_NONBLOCK = 0200
>>> +# define SFD_NONBLOCK SFD_NONBLOCK
>>> + };
>>
>> seems like this would be better as a bits/signalfd.h rather than inlining
>> arch ifdef checks all over the place
>
> there is tendency to consolidate headers thats why its like this. Initially
> I wondered too
yes, so the common pieces arent duplicated. i didnt mean copy the
entire file to bits/signalfd.h, just break out the arch-specific
pieces.
also, signalfd() last i checked is linux-specific. so it shouldnt be
in include/ ... it needs to be in libc/sysdeps/linux/...
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly
On Tue, Jul 12, 2011 at 14:54, Rich Felker wrote:
> On Tue, Jul 12, 2011 at 11:47:51AM -0400, Mike Frysinger wrote:
>> On Tue, Jul 12, 2011 at 10:37, Khem Raj wrote:
>> > On 07/11/2011 08:39 PM, Mike Frysinger wrote:
>> >> On Friday, July 01, 2011 17:50:15 Khem Raj wrote:
>> >>> --- a/include/sys/signalfd.h
>> >>> +++ b/include/sys/signalfd.h
>> >>> @@ -64,6 +64,15 @@ enum
>> >>> # define SFD_NONBLOCK SFD_NONBLOCK
>> >>> };
>> >>>
>> >>> +#elif defined __mips__
>> >>> +enum
>> >>> + {
>> >>> + SFD_CLOEXEC = 0200,
>> >>> +# define SFD_CLOEXEC SFD_CLOEXEC
>> >>> + SFD_NONBLOCK = 0200
>> >>> +# define SFD_NONBLOCK SFD_NONBLOCK
>> >>> + };
>> >>
>> >> seems like this would be better as a bits/signalfd.h rather than inlining
>> >> arch ifdef checks all over the place
>> >
>> > there is tendency to consolidate headers thats why its like this. Initially
>> > I wondered too
>>
>> yes, so the common pieces arent duplicated. i didnt mean copy the
>> entire file to bits/signalfd.h, just break out the arch-specific
>> pieces.
>>
>> also, signalfd() last i checked is linux-specific. so it shouldnt be
>> in include/ ... it needs to be in libc/sysdeps/linux/...
>
> Are the values always the same as the O_ constants from fcntl.h? If
> so, it's stupid that they even exist, but the cleanest solution would
> be to just have signalfd.h include fcntl.h and then use
>
> #define SFD_NONBLOCK O_NONBLOCK
> #define SFD_CLOEXEC O_CLOEXEC
i vaguely recall the same situation coming up on the glibc lists, and
the same proposal thrown up, but it was swatted down for two reasons:
- it pollutes the name space (including signalfd.h should not
implicitly include fcntl.h)
- most, but not all, arches are the same (but maybe i remember this wrong)
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly
On Tue, Jul 12, 2011 at 16:55, Rich Felker wrote:
> On Tue, Jul 12, 2011 at 03:05:56PM -0400, Mike Frysinger wrote:
>> On Tue, Jul 12, 2011 at 14:54, Rich Felker wrote:
>> > On Tue, Jul 12, 2011 at 11:47:51AM -0400, Mike Frysinger wrote:
>> >> On Tue, Jul 12, 2011 at 10:37, Khem Raj wrote:
>> >> > On 07/11/2011 08:39 PM, Mike Frysinger wrote:
>> >> >> On Friday, July 01, 2011 17:50:15 Khem Raj wrote:
>> >> >>> --- a/include/sys/signalfd.h
>> >> >>> +++ b/include/sys/signalfd.h
>> >> >>> @@ -64,6 +64,15 @@ enum
>> >> >>> # define SFD_NONBLOCK SFD_NONBLOCK
>> >> >>> };
>> >> >>>
>> >> >>> +#elif defined __mips__
>> >> >>> +enum
>> >> >>> + {
>> >> >>> + SFD_CLOEXEC = 0200,
>> >> >>> +# define SFD_CLOEXEC SFD_CLOEXEC
>> >> >>> + SFD_NONBLOCK = 0200
>> >> >>> +# define SFD_NONBLOCK SFD_NONBLOCK
>> >> >>> + };
>> >> >>
>> >> >> seems like this would be better as a bits/signalfd.h rather than
>> >> >> inlining
>> >> >> arch ifdef checks all over the place
>> >> >
>> >> > there is tendency to consolidate headers thats why its like this.
>> >> > Initially
>> >> > I wondered too
>> >>
>> >> yes, so the common pieces arent duplicated. i didnt mean copy the
>> >> entire file to bits/signalfd.h, just break out the arch-specific
>> >> pieces.
>> >>
>> >> also, signalfd() last i checked is linux-specific. so it shouldnt be
>> >> in include/ ... it needs to be in libc/sysdeps/linux/...
>> >
>> > Are the values always the same as the O_ constants from fcntl.h? If
>> > so, it's stupid that they even exist, but the cleanest solution would
>> > be to just have signalfd.h include fcntl.h and then use
>> >
>> > #define SFD_NONBLOCK O_NONBLOCK
>> > #define SFD_CLOEXEC O_CLOEXEC
>>
>> i vaguely recall the same situation coming up on the glibc lists, and
>> the same proposal thrown up, but it was swatted down for two reasons:
>> - it pollutes the name space (including signalfd.h should not
>> implicitly include fcntl.h)
>
> I would consider sanctity of the namespace pretty irrelevant when
> you're using a highly Linux-specific feature. Certainly there's no
> standard document that says signalfd.h can't include fcntl.h because
> it's not covered by any standard to begin with.
while true, the purist in me still finds it distasteful ;). and what
is Linux-specific today could be in POSIX tomorrow! just look at the
all the fun new funcs in 2008 vs 2004 specs to see this isnt
unthinkable.
>> - most, but not all, arches are the same (but maybe i remember this wrong)
>
> Why do the kernel developers keep doing idiotic things like this?
> *sigh*
well, once you're stuck with an overlapping pile, there's really
nothing you can do to sort them out. you might be able to blame the
original source, but past that, they're pretty much pucked.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit prelink] ARM: introduce blind options to select & force THUMB mode
On Tuesday, July 12, 2011 15:03:43 Yann E. MORIN wrote: > On Tuesday 12 July 2011 20:04:36 Bernhard Reutner-Fischer wrote: > > On Jul 9, 2011 8:50 PM, "Yann E. MORIN": > > > - this selects: HAS_THUMB, COMPILE_IN_THUMB_MODE and USE_BX > > > > I would prefer to name the knob USE_THUMB instead. > > Comments? > > I am not a native english-speaker, but to me, USE_THUMB does not convey > the important meaning that Thumb mode is forced; it is not as strong. > Really, I named it thus to highlight the fact that some other config > option did force Thumb to be used. "USE_XXX" means "build code to actually use feature XXX". "HAS_XXX" means "the processor has support for feature XXX", but that doesnt necessarily mean that the user wants to support it. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] mips/signalfd.h: SFD_NONBLOCK for mips is 0200 unlike 04000 commonly
On Tuesday, July 12, 2011 20:43:45 Rich Felker wrote: > On Tue, Jul 12, 2011 at 05:47:22PM -0400, Mike Frysinger wrote: > > >> - most, but not all, arches are the same (but maybe i remember this > > >> wrong) > > > > > > Why do the kernel developers keep doing idiotic things like this? > > > *sigh* > > > > well, once you're stuck with an overlapping pile, there's really > > nothing you can do to sort them out. you might be able to blame the > > original source, but past that, they're pretty much pucked. > > Well they could be consistent and either say everything new is going > to use universal generic constants and structures with clean > alignment, or they could say they're always going to reuse the > existing arch-specific stuff. But reusing it on some archs and using > new generics on others make a whole new meta level of arch-dependence > that's even a bigger pain to deal with. often times, it's simply not possible. take the bits that every arch defines, OR them together, and then AND them with all the other arches. often times there will be no common bit values that are available. what they're doing with the asm-generic stuff makes sense and is really the only option when maintaining ABI is required. existing arches with warts have to live with them, but new arches are based on the common code and do not. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: The joy of buildroot - anyone know what's causing this?
On Wednesday, August 10, 2011 07:17:12 Neil Higgins wrote: > Trying to buidroot for the ICnova AP7000 Base, 20110104 release, on > Ubuntu 10.04.3 > > All suggestions gratefully received. please ask on the buildroot mailing list -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: usefulness of UCLIBC_CTOR_DTOR ?
On Friday, August 12, 2011 17:01:01 Yann E. MORIN wrote: > On Friday 12 August 2011 17:34:49 John Spencer wrote: > > overall this looks like a pretty useless and confusing option, which > > imho should get removed. > > even if there's a way to build a binary without those 2 object files, > > which i'm not aware of (please point it out if you know how), it doesn't > > cost nothing except of 1200 bytes harddisk storage to still build them. > > I just looked on PPC-32, uClibc-0.9.30.2. The total size of code is > 128 bytes, plus one long; which is a grand total of 132 bytes (if my > maths are not too busted, and I did not miss any symbol). if you're just counting the .o files, you missed the usage in the libc. there's also init/fini in the ldso, but that is always enabled. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: usefulness of UCLIBC_CTOR_DTOR ?
On Friday, August 12, 2011 13:59:51 Rich Felker wrote: > On Fri, Aug 12, 2011 at 01:53:23PM -0400, Lennart Sorensen wrote: > > C libraries can have constructors and destructors too. > > No they cannot. Those may be "GNU C" libraries but they are not C > libraries. libraries written in C can have constructors and deconstructors too. see the init/fini gcc attributes. this is part of the ELF spec and the language (C/C++/...) is irrelevant. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] resolv: simple optimizations and style/readability fixes
please split code changes from style changes into sep commits -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: usefulness of UCLIBC_CTOR_DTOR ?
On Saturday, August 20, 2011 23:24:17 Rich Felker wrote: > On Sat, Aug 20, 2011 at 10:00:44PM -0400, Mike Frysinger wrote: > > On Friday, August 12, 2011 13:59:51 Rich Felker wrote: > > > On Fri, Aug 12, 2011 at 01:53:23PM -0400, Lennart Sorensen wrote: > > > > C libraries can have constructors and destructors too. > > > > > > No they cannot. Those may be "GNU C" libraries but they are not C > > > libraries. > > > > libraries written in C can have constructors and deconstructors too. see > > the init/fini gcc attributes. this is part of the ELF spec and the > > language (C/C++/...) is irrelevant. > > Just because the ELF binary format makes it possible to do something > doesn't mean that's C. There's plenty you can do with ELF making an > ELF file by hand that would be impossible with any C compiler or even > a GNU C compiler. Ctors/dtors are part of ELF so it can support C++. > GNU C just added an extension to use them in "C" too, but that doesn't > make it C. in the context of uClibc, it's the same thing. you can quote the spec all you like, it doesnt change the behavior of uClibc -- we do ELF, and we do constructors in C. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Invitation to connect on LinkedIn
On Thursday, September 15, 2011 22:08:28 Ben Kloosterman wrote: > I'd like to add you to my professional network on LinkedIn. punted from the list -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] Defeat compiler optimization which assumes function addresses are never NULL
On Thursday, September 15, 2011 10:59:21 Denys Vlasenko wrote:
> From email:
> A warning for people who can be hit by the same or similar issue:
> gcc 4.1.2 with -march=i486 here with -Os and even with -O2 or -O
> is "optimizing away" the check
>if (_stdio_term)
> in libc/stdlib/_atexit.c
> which results in a "call 0" and a segfault at exit
> if you do not happen to link in stdio.
there's quite a lot of noise in this changeset because you're mixing style
with functional. please refrain from this in the future.
> --- a/libc/stdlib/_atexit.c
> +++ b/libc/stdlib/_atexit.c
>
> +/* Defeat compiler optimization which assumes function addresses are never
> +static __always_inline int not_null_ptr(const void *p)
> +{
> + const void *q;
> + __asm__ (""
> + : "=r" (q) /* output */
> + : "0" (p) /* input */
> + );
> + return q != 0;
> +}
>
> --- a/libc/stdlib/abort.c
> +++ b/libc/stdlib/abort.c
>
> +/* Defeat compiler optimization which assumes function addresses are never
> +static __always_inline int not_null_ptr(const void *p)
> +{
> + const void *q;
> + __asm__ (""
> + : "=r" (q) /* output */
> + : "0" (p) /* input */
> + );
> + return q != 0;
> +}
ugh, you copy & pasted the same thing. please locate a common header to stick
this into. or drop it.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Use executable's RPATH in looking up library searching path.
On Thursday, September 22, 2011 11:39:24 Filippo ARCIDIACONO wrote: > When the dynamic linker load and resolve the library dependencies for an > executable, It should use the executable's rpath as searching path for all > his needed libraries. i don't see any justification to back up this statement other than "this is what glibc does". i'm honestly not too concerned by that as there are places already we deviate from glibc behavior by design. what i do want to know is what the ELF spec says. could you look that up (i dont have a copy off hand and the LF is down still) ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Use executable's RPATH in looking up library searching path.
On Friday, September 23, 2011 15:39:38 Allan Clark wrote: > As a past embedded guy, I like the idea of this being around as a way to > fix dependency issues based on how developers are accustomed to coding on > common platforms. you can also trivially make it work with other knobs: ld.so.conf, LD_PRELOAD, LD_LIBRARY_PATH, etc... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Use executable's RPATH in looking up library searching path.
On Fri, Sep 23, 2011 at 11:23, Filippo ARCIDIACONO wrote: > The ELF spec says what is the RPATH, but nothing about the dynamic linker > Use the rpath in library search path. i'm afraid this appears to be incorrect. when i read the spec, it sounds to me like the glibc behavior is wrong and uClibc is right. note that while the spec says DT_RUNPATH below and not DT_RPATH, the behavior is the same in this regard. the only difference between DT_RUNPATH and DT_RPATH is precedence wrt $LD_LIBRARY_PATH. on to the spec (everything below) ! http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies The set of directories specified by a given DT_RUNPATH entry is used to find only the immediate dependencies of the executable or shared object containing the DT_RUNPATH entry. That is, it is used only for those dependencies contained in the DT_NEEDED entries of the dynamic structure containing the DT_RUNPATH entry, itself. One object's DT_RUNPATH entry does not affect the search for any other object's dependencies. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Use executable's RPATH in looking up library searching path.
On Tuesday, September 27, 2011 08:04:27 Filippo ARCIDIACONO wrote: > From Mike Frysinger > > On Fri, Sep 23, 2011 at 11:23, Filippo ARCIDIACONO wrote: > > > The ELF spec says what is the RPATH, but nothing about the dynamic > > > linker Use the rpath in library search path. > > > > i'm afraid this appears to be incorrect. when i read the > > spec, it sounds to me like the glibc behavior is wrong and > > uClibc is right. > > > > note that while the spec says DT_RUNPATH below and not > > DT_RPATH, the behavior is the same in this regard. the only > > difference between DT_RUNPATH and DT_RPATH is precedence wrt > > $LD_LIBRARY_PATH. > > > > on to the spec (everything below) ! > > I already read this spec, but unfortunately it was very old. the latest changes went in 19 Oct 2010. how recent does it need to be ?? :p > I also knew that this could be solved using ldsoconfig, > LD_LIBRARY_PATH , but I wonder if it could be worth fix > in the Dynamic Linker. > Finally, I agreed with you, being also the DT_RPATH's use > superseded by DT_RUNPATH, as the spec says, the DL works fine > and the fix is useless. i've come across a case where glibc works the same as uClibc kmail has custom rpath and needs libkmailprivate, and it is found via the custom rpath. but libkmailprivate needs libmailprivate, but it is found via the normal paths ... the custom rpath is not considered. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 3/5] microblaze can be either big or little endian
On Thursday, September 29, 2011 18:40:21 Steve Bennett wrote: > -#define __BYTE_ORDER __BIG_ENDIAN > +#ifdef _BIG_ENDIAN > +# define __BYTE_ORDER __BIG_ENDIAN > +#else > +# ifdef _LITTLE_ENDIAN > +# define __BYTE_ORDER __LITTLE_ENDIAN > +# endif > +#endif are you sure this is correct ? who defines "_BIG_ENDIAN" ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 4/5] microblaze linux has no SDA support
On Thursday, September 29, 2011 18:40:22 Steve Bennett wrote: > +/* No SDAs on linux */ > +#if 0 > /* Load SDAs */ > la r2, r0, C_SYMBOL_NAME(_SDA_BASE_) > la r13, r0, C_SYMBOL_NAME(_SDA2_BASE_) > +#endif so delete the code -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 5/5] microblaze mmu/elf/shared lib support
On Thursday, September 29, 2011 18:40:23 Steve Bennett wrote: > --- a/extra/Configs/Config.microblaze > +++ b/extra/Configs/Config.microblaze > > +choice > + prompt "Microblaze MMU Capability" > + default CONFIG_MICROBLAZE_NO_MMU > + depends on TARGET_microblaze > + help > + Determines the MMU capability of your microblaze CPU. > + > +config CONFIG_MICROBLAZE_NO_MMU > + bool "no mmu" > + select HAVE_NO_PIC > + select ARCH_HAS_NO_SHARED > select ARCH_HAS_NO_MMU > + > +config CONFIG_MICROBLAZE_MMU > + bool "mmu" > + select ARCH_HAS_MMU > + > +endchoice why do you need your own ? we already have common ARCH_USE_MMU. > --- a/include/elf.h > +++ b/include/elf.h > > +/* Xilinx Microblaze (unofficial). Note that there is now an official > microblaze > + * magic number, but all the toolchains currently in existence > use the old number > + */ > +#define EM_MICROBLAZE 0xbaab please keep in sync with binutils. they use 189 for EM_MICROBLAZE and 0xbaab for EM_MICROBLAZE_OLD -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 5/5] microblaze mmu/elf/shared lib support
_On Thursday, September 29, 2011 18:40:23 Steve Bennett wrote: > --- /dev/null > +++ b/ldso/ldso/microblaze/dl-debug.h > > +static const char *_dl_reltypes_tab[] = static const char * const _dl_reltypes_tab[] = -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 3/5] microblaze can be either big or little endian
On Sunday, October 02, 2011 19:47:43 Steve Bennett wrote:
> On 02/10/2011, at 4:57 AM, Mike Frysinger wrote:
> > On Thursday, September 29, 2011 18:40:21 Steve Bennett wrote:
> >> -#define __BYTE_ORDER __BIG_ENDIAN
> >> +#ifdef _BIG_ENDIAN
> >> +# define __BYTE_ORDER __BIG_ENDIAN
> >> +#else
> >> +# ifdef _LITTLE_ENDIAN
> >> +# define __BYTE_ORDER __LITTLE_ENDIAN
> >> +# endif
> >> +#endif
> >
> > are you sure this is correct ? who defines "_BIG_ENDIAN" ?
>
> It's defined by the toolchain.
that's fairly unusual for the toolchain. but i guess it's too late now to fix
gcc to use better names. please add a comment that _{BIG,LITTLE}_ENDIAN come
from the toolchain.
> c.f. libc/sysdeps/linux/mips/bits/endian.h
they aren't using _{BIG,LITTLE}_ENDIAN. they're using sane name-spaced
defines which are a bit more obvious in that they're coming from gcc.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 5/5] microblaze mmu/elf/shared lib support
On Monday, October 03, 2011 04:16:36 Ryan Flux wrote:
> On 10/02/2011 05:01 AM, Mike Frysinger wrote:
> > On Thursday, September 29, 2011 18:40:23 Steve Bennett wrote:
> >> --- a/extra/Configs/Config.microblaze
> >> +++ b/extra/Configs/Config.microblaze
> >>
> >> +choice
> >> + prompt "Microblaze MMU Capability"
> >> + default CONFIG_MICROBLAZE_NO_MMU
> >> + depends on TARGET_microblaze
> >> + help
> >> + Determines the MMU capability of your microblaze CPU.
> >> +
> >> +config CONFIG_MICROBLAZE_NO_MMU
> >> + bool "no mmu"
> >> + select HAVE_NO_PIC
> >> + select ARCH_HAS_NO_SHARED
> >>
> >>select ARCH_HAS_NO_MMU
> >>
> >> +
> >> +config CONFIG_MICROBLAZE_MMU
> >> + bool "mmu"
> >> + select ARCH_HAS_MMU
> >> +
> >> +endchoice
> >
> > why do you need your own ? we already have common ARCH_USE_MMU.
>
> The reason behind not using ARCH_USE_MMU is that the
> Microblaze core may not necessarily have a MMU. (The
> MMU is an optional feature of the core).
i'm not sure how this is relevant. ARCH_{HAVE,USE}_MMU are presented to the
user already so the user gets to decide whether to utilize the MMU (or if the
hardware has it in the first place).
> The configuration is based on how the ARM architecture
> uses the target processor choice in extra/Configs/Config.arm
> for the various MMU/no-MMU processors.
is your tree up to date ? extra/Configs/Config.arm in latest master doesn't
have any MMU defines.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v2 0/5] Microblaze shared library support for uClibc
On Monday, October 03, 2011 20:50:44 Steve Bennett wrote: > This patch series adds uClibc shared library support for > microblaze with mmu, taken largely from glibc. i don't see any problems in this patchset. i'll merge it in a few days if no one else has any feedback. thanks ! -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH 1/3] ldso: merge duplicate dl-syscalls.h code to common header
Signed-off-by: Mike Frysinger
---
ldso/include/dl-syscall.h |7 +++
ldso/ldso/arm/dl-syscalls.h |6 --
ldso/ldso/avr32/dl-syscalls.h |7 +--
ldso/ldso/bfin/dl-syscalls.h|6 --
ldso/ldso/c6x/dl-syscalls.h |8
ldso/ldso/cris/dl-syscalls.h|7 +--
ldso/ldso/frv/dl-syscalls.h |6 --
ldso/ldso/i386/dl-syscalls.h|7 +--
ldso/ldso/m68k/dl-syscalls.h|7 +--
ldso/ldso/mips/dl-syscalls.h|7 +--
ldso/ldso/powerpc/dl-syscalls.h |7 +--
ldso/ldso/sh/dl-syscalls.h |7 ---
ldso/ldso/sh64/dl-syscalls.h|7 ---
ldso/ldso/sparc/dl-syscalls.h |7 +--
ldso/ldso/x86_64/dl-syscalls.h |7 +--
ldso/ldso/xtensa/dl-syscalls.h |8 +---
16 files changed, 16 insertions(+), 95 deletions(-)
diff --git a/ldso/include/dl-syscall.h b/ldso/include/dl-syscall.h
index da3ac7f..7539c22 100644
--- a/ldso/include/dl-syscall.h
+++ b/ldso/include/dl-syscall.h
@@ -8,6 +8,13 @@
#ifndef _LD_SYSCALL_H_
#define _LD_SYSCALL_H_
+/* We can't use the real errno in ldso, since it has not yet
+ * been dynamicly linked in yet. */
+#include "sys/syscall.h"
+extern int _dl_errno;
+#undef __set_errno
+#define __set_errno(X) {(_dl_errno) = (X);}
+
/* Pull in the arch specific syscall implementation */
#include
/* For MAP_ANONYMOUS -- differs between platforms */
diff --git a/ldso/ldso/arm/dl-syscalls.h b/ldso/ldso/arm/dl-syscalls.h
index 1c0e669..195461f 100644
--- a/ldso/ldso/arm/dl-syscalls.h
+++ b/ldso/ldso/arm/dl-syscalls.h
@@ -1,9 +1,3 @@
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
/* _call_via_rX calls are used in thumb ldso because of calls via
* function pointers, but ldso is not linked with anything which
* provides them, so define them here (only required for thumb).
diff --git a/ldso/ldso/avr32/dl-syscalls.h b/ldso/ldso/avr32/dl-syscalls.h
index 996bb87..f40c4fd 100644
--- a/ldso/ldso/avr32/dl-syscalls.h
+++ b/ldso/ldso/avr32/dl-syscalls.h
@@ -1,6 +1 @@
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
+/* stub for arch-specific syscall issues */
diff --git a/ldso/ldso/bfin/dl-syscalls.h b/ldso/ldso/bfin/dl-syscalls.h
index f74cf1a..a119c74 100644
--- a/ldso/ldso/bfin/dl-syscalls.h
+++ b/ldso/ldso/bfin/dl-syscalls.h
@@ -18,12 +18,6 @@ License along with uClibc; see the file COPYING.LIB. If
not, write to
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA. */
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
#include
/* The code below is extracted from libc/sysdeps/linux/frv/_mmap.c */
diff --git a/ldso/ldso/c6x/dl-syscalls.h b/ldso/ldso/c6x/dl-syscalls.h
index 9ff3358..66d96ab 100644
--- a/ldso/ldso/c6x/dl-syscalls.h
+++ b/ldso/ldso/c6x/dl-syscalls.h
@@ -4,14 +4,6 @@
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
-#include
-
#ifdef __NR_pread64
#define __NR___syscall_pread __NR_pread64
static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
diff --git a/ldso/ldso/cris/dl-syscalls.h b/ldso/ldso/cris/dl-syscalls.h
index 996bb87..f40c4fd 100644
--- a/ldso/ldso/cris/dl-syscalls.h
+++ b/ldso/ldso/cris/dl-syscalls.h
@@ -1,6 +1 @@
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
+/* stub for arch-specific syscall issues */
diff --git a/ldso/ldso/frv/dl-syscalls.h b/ldso/ldso/frv/dl-syscalls.h
index a4bff1d..13b887b 100644
--- a/ldso/ldso/frv/dl-syscalls.h
+++ b/ldso/ldso/frv/dl-syscalls.h
@@ -4,12 +4,6 @@
* Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
*/
-/* We can't use the real errno in ldso, since it has not yet
- * been dynamicly linked in yet. */
-#include "sys/syscall.h"
-extern int _dl_errno;
-#undef __set_errno
-#define __set_errno(X) {(_dl_errno) = (X);}
#include
/* The code below is extracted from libc/sysdeps/linux/frv/_mmap.c */
diff --git a/ldso/ldso/i386/dl-syscalls.h b/ldso/ldso/i386/dl-syscalls.h
index 996bb87..f40c4fd 100644
--- a/ldso/ldso/i386/dl-s
[PATCH 0/3] misc ldso cleanups
Lightly tested ... make sure I didn't do anything too stupid here. Mike Frysinger (3): ldso: merge duplicate dl-syscalls.h code to common header ldso: bfin/frv: drop dead simulator code ldso: unify pread syscall definition ldso/include/dl-syscall.h | 29 +++ ldso/ldso/arm/dl-syscalls.h |6 -- ldso/ldso/avr32/dl-syscalls.h |7 +-- ldso/ldso/bfin/dl-syscalls.h| 170 - ldso/ldso/c6x/dl-syscalls.h | 26 +-- ldso/ldso/cris/dl-syscalls.h|7 +-- ldso/ldso/frv/dl-syscalls.h | 176 +-- ldso/ldso/i386/dl-syscalls.h|7 +-- ldso/ldso/m68k/dl-syscalls.h|7 +-- ldso/ldso/mips/dl-syscalls.h|7 +-- ldso/ldso/powerpc/dl-syscalls.h |7 +-- ldso/ldso/sh/dl-syscalls.h |7 -- ldso/ldso/sh64/dl-syscalls.h|7 -- ldso/ldso/sparc/dl-syscalls.h |7 +-- ldso/ldso/x86_64/dl-syscalls.h |7 +-- ldso/ldso/xtensa/dl-syscalls.h |8 +-- 16 files changed, 40 insertions(+), 445 deletions(-) -- 1.7.6.1 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH 3/3] ldso: unify pread syscall definition
A few arches want pread() defined, so move it to common code.
Signed-off-by: Mike Frysinger
---
ldso/include/dl-syscall.h| 22 ++
ldso/ldso/bfin/dl-syscalls.h | 12
ldso/ldso/c6x/dl-syscalls.h | 18 +-
ldso/ldso/frv/dl-syscalls.h | 18 +-
4 files changed, 24 insertions(+), 46 deletions(-)
diff --git a/ldso/include/dl-syscall.h b/ldso/include/dl-syscall.h
index 7539c22..547dad1 100644
--- a/ldso/include/dl-syscall.h
+++ b/ldso/include/dl-syscall.h
@@ -108,6 +108,28 @@ static __always_inline _syscall0(gid_t, _dl_getpid)
static __always_inline _syscall3(int, _dl_readlink, const char *, path, char
*, buf,
size_t, bufsiz)
+#ifdef __NR_pread64
+#define __NR___syscall_pread __NR_pread64
+static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
+ size_t, count, off_t, offset_hi, off_t, offset_lo)
+
+static __always_inline ssize_t
+_dl_pread(int fd, void *buf, size_t count, off_t offset)
+{
+ return __syscall_pread(fd, buf, count, offset, offset >> 31);
+}
+#elif defined __NR_pread
+#define __NR___syscall_pread __NR_pread
+static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
+ size_t, count, off_t, offset_hi, off_t, offset_lo)
+
+static __always_inline ssize_t
+_dl_pread(int fd, void *buf, size_t count, off_t offset)
+{
+ return __syscall_pread(fd, buf, count, __LONG_LONG_PAIR(offset >> 31,
offset));
+}
+#endif
+
#ifdef __UCLIBC_HAS_SSP__
# include
# define __NR__dl_gettimeofday __NR_gettimeofday
diff --git a/ldso/ldso/bfin/dl-syscalls.h b/ldso/ldso/bfin/dl-syscalls.h
index f9577ba..29a4514 100644
--- a/ldso/ldso/bfin/dl-syscalls.h
+++ b/ldso/ldso/bfin/dl-syscalls.h
@@ -18,18 +18,6 @@ License along with uClibc; see the file COPYING.LIB. If
not, write to
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA. */
-#ifdef __NR_pread
-#define __NR___syscall_pread __NR_pread
-static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
- size_t, count, off_t, offset_hi, off_t, offset_lo)
-
-static __always_inline ssize_t
-_dl_pread(int fd, void *buf, size_t count, off_t offset)
-{
- return(__syscall_pread(fd,buf,count,__LONG_LONG_PAIR (offset >> 31,
offset)));
-}
-#endif
-
#ifdef __NR_sram_alloc
#define __NR__dl_sram_alloc __NR_sram_alloc
static __always_inline _syscall2(__ptr_t, _dl_sram_alloc,
diff --git a/ldso/ldso/c6x/dl-syscalls.h b/ldso/ldso/c6x/dl-syscalls.h
index 66d96ab..f40c4fd 100644
--- a/ldso/ldso/c6x/dl-syscalls.h
+++ b/ldso/ldso/c6x/dl-syscalls.h
@@ -1,17 +1 @@
-/* Copyright (C) 2010 Texas Instruments Incorporated
- * Contributed by Mark Salter
- *
- * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
- */
-
-#ifdef __NR_pread64
-#define __NR___syscall_pread __NR_pread64
-static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
- size_t, count, off_t, offset_hi, off_t, offset_lo);
-
-static __always_inline ssize_t
-_dl_pread(int fd, void *buf, size_t count, off_t offset)
-{
- return(__syscall_pread(fd,buf,count, offset, offset >> 31));
-}
-#endif
+/* stub for arch-specific syscall issues */
diff --git a/ldso/ldso/frv/dl-syscalls.h b/ldso/ldso/frv/dl-syscalls.h
index ce9435a..f40c4fd 100644
--- a/ldso/ldso/frv/dl-syscalls.h
+++ b/ldso/ldso/frv/dl-syscalls.h
@@ -1,17 +1 @@
-/* Copyright (C) 2003, 2004 Red Hat, Inc.
- * Contributed by Alexandre Oliva
- *
- * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
- */
-
-#ifdef __NR_pread
-#define __NR___syscall_pread __NR_pread
-static __always_inline _syscall5(ssize_t, __syscall_pread, int, fd, void *,
buf,
- size_t, count, off_t, offset_hi, off_t, offset_lo);
-
-static __always_inline ssize_t
-_dl_pread(int fd, void *buf, size_t count, off_t offset)
-{
- return(__syscall_pread(fd,buf,count,__LONG_LONG_PAIR (offset >> 31,
offset)));
-}
-#endif
+/* stub for arch-specific syscall issues */
--
1.7.6.1
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH 2/3] ldso: bfin/frv: drop dead simulator code
Nowhere do we define DYNAMIC_LOADER_IN_SIMULATOR, so drop the little bit
of code that depends on it. At least in the Blackfin case, we can run an
FDPIC ldso just fine under the simulator without hacks.
Signed-off-by: Mike Frysinger
---
ldso/ldso/bfin/dl-syscalls.h | 152 --
ldso/ldso/frv/dl-syscalls.h | 152 --
2 files changed, 0 insertions(+), 304 deletions(-)
diff --git a/ldso/ldso/bfin/dl-syscalls.h b/ldso/ldso/bfin/dl-syscalls.h
index a119c74..f9577ba 100644
--- a/ldso/ldso/bfin/dl-syscalls.h
+++ b/ldso/ldso/bfin/dl-syscalls.h
@@ -18,158 +18,7 @@ License along with uClibc; see the file COPYING.LIB. If
not, write to
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA. */
-#include
-
-/* The code below is extracted from libc/sysdeps/linux/frv/_mmap.c */
-
-#if DYNAMIC_LOADER_IN_SIMULATOR
-#define __NR___syscall_mmap2 __NR_mmap2
-static __inline__ _syscall6(__ptr_t, __syscall_mmap2, __ptr_t, addr,
- size_t, len, int, prot, int, flags, int, fd, off_t, offset)
-
-/* Make sure we don't get another definition of _dl_mmap from the
- machine-independent code. */
-#undef __NR_mmap
-#undef __NR_mmap2
-
-/* This is always 12, even on architectures where PAGE_SHIFT != 12. */
-# ifndef MMAP2_PAGE_SHIFT
-# define MMAP2_PAGE_SHIFT 12
-# endif
-
-#include /* for PAGE_SIZE */
-static __always_inline void *_dl_memset(void*,int,size_t);
-static __always_inline ssize_t _dl_pread(int fd, void *buf, size_t count,
off_t offset);
-
-static __ptr_t
-_dl_mmap(__ptr_t addr, size_t len, int prot, int flags, int fd, __off_t offset)
-{
- size_t plen = (len + PAGE_SIZE - 1) & -PAGE_SIZE;
-
-/* This is a hack to enable the dynamic loader to run within a
- simulator that doesn't support mmap, with a number of very ugly
- tricks. Also, it's not as useful as it sounds, since only dynamic
- executables without DT_NEEDED dependencies can be run. AFAIK, they
- can only be created with -pie. This trick suffices to enable the
- dynamic loader to obtain a blank page that it maps early in the
- bootstrap. */
- if ((flags & MAP_FIXED) == 0)
-{
- void *_dl_mmap_base = 0;
- __ptr_t *ret = 0;
-
- if (! _dl_mmap_base)
- {
- void *stack;
- __asm__ ("mov sp, %0" : "=r" (stack));
- _dl_mmap_base = (void *)(((long)stack + 2 * PAGE_SIZE) & -PAGE_SIZE);
- retry:
- if (((void **)_dl_mmap_base)[0] == _dl_mmap_base
- && ((void **)_dl_mmap_base)[1023] == _dl_mmap_base
- && (((void **)_dl_mmap_base)[177]
- == ((void **)_dl_mmap_base)[771]))
- {
- while (((void**)_dl_mmap_base)[177])
- {
- _dl_mmap_base = ((void**)_dl_mmap_base)[177];
- if (!(((void **)_dl_mmap_base)[0] == _dl_mmap_base
- && ((void **)_dl_mmap_base)[1023] == _dl_mmap_base
- && (((void **)_dl_mmap_base)[177]
- == ((void**)_dl_mmap_base)[771])))
- ((void(*)())0)();
- }
- }
- else
- {
- int i;
- for (i = 0; i < (int)PAGE_SIZE; i++)
- if (*(char*)(_dl_mmap_base + i))
- break;
- if (i != PAGE_SIZE)
- {
- _dl_mmap_base = (void*)((long)_dl_mmap_base + PAGE_SIZE);
- goto retry;
- }
- ((void**)_dl_mmap_base)[-1] =
- ((void**)_dl_mmap_base)[0] =
- ((void**)_dl_mmap_base)[1023] =
- _dl_mmap_base;
- }
- }
-
- if (_dl_mmap_base)
- {
- if (!(((void **)_dl_mmap_base)[0] == _dl_mmap_base
- && ((void **)_dl_mmap_base)[1023] == _dl_mmap_base
- && (((void **)_dl_mmap_base)[177]
- == ((void**)_dl_mmap_base)[771])))
- ((void(*)())0)();
- ret = (__ptr_t)((char*)_dl_mmap_base + PAGE_SIZE);
- _dl_mmap_base =
- ((void**)_dl_mmap_base)[177] =
- ((void**)_dl_mmap_base)[771] =
- (char*)_dl_mmap_base + plen + PAGE_SIZE;
- ((void**)_dl_mmap_base)[0] =
- ((void**)_dl_mmap_base)[1023] =
- _dl_mmap_base;
- }
-
- if ((flags & MAP_ANONYMOUS) != 0)
- {
- _dl_memset (ret, 0, plen);
- return ret;
- }
-
- flags |= MAP_FIXED;
- addr = ret;
-}
-if (offset & ((1 << MMAP2_PAGE_SHIFT) - 1)) {
-#if 0
- __set_errno (EINVAL);
-#endif
- return MAP_FAILED;
-}
-if ((flags & MAP_FIXED) != 0)
- {
- if (_dl_pread(fd, addr, len, offset) != (ssize_t)len)
- return (void*)MAP_FAILED;
- if (plen != len)
- _dl_memset (addr + len, 0
Re: timer_create fails (return=-1 errno=0)
On Tuesday 18 October 2011 16:03:13 Khem Raj wrote: > On Tue, Oct 18, 2011 at 11:23 AM, Grant Edwards wrote: > > there any documentation that lists places like this where uClibc > > doesn't meet POSIX standards? > > I doubt if this is documented. we try with docs/uClibc_vs_SuSv3.txt, but i know we aren't good with keeping it up to date. patches welcome ;). -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Where __NR_getxuid and __NR_getxgid should be defined?
On Tue, Oct 25, 2011 at 05:57, stl wrote: > I have dug in the uClibc source code, and I have found that the > definition of __NR_getuid and __NR_getgid depend on > __NR_getxuid and __NR_getxgid. no. those are fallbacks only for alpha. all other arches should be defining getuid/getgid in your linux's asm/unistd.h. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: s/CROSS/CROSS_COMPILE/g
On Thu, Oct 27, 2011 at 16:42, Carmelo AMOROSO wrote: > +ifndef CROSS_COMPILE > +CROSS_COMPILE= > endif this is kind of useless logic. i would change it to one line: CROSS_COMPILE ?= $(CROSS) -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: s/CROSS/CROSS_COMPILE/g
On Thu, Oct 27, 2011 at 17:54, Carmelo AMOROSO wrote: > On 27/10/2011 17.32, Mike Frysinger wrote: >> On Thu, Oct 27, 2011 at 16:42, Carmelo AMOROSO wrote: >>> +ifndef CROSS_COMPILE >>> +CROSS_COMPILE= >>> endif >> >> this is kind of useless logic. i would change it to one line: >> CROSS_COMPILE ?= $(CROSS) > > I've really done a sed, so I've kept the original logic. > IIUC you are suggesting to keep both CROSS and CROSS_COMPILE option, > If so, it should be the opposite > > CROSS ?= $(CROSS_COMPILE) > > shouldn't it ? considering you changed everything else to use $(CROSS_COMPILE), i think what i proposed makes the most sense. that way we emphasize that CROSS_COMPILE is what people should be using, but if they don't but do continue to use CROSS, then the old way works. your proposal would prefer CROSS over CROSS_COMPILE if both were specified. -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] daemon: ignore SIGHUP
On Wednesday 16 November 2011 14:38:17 Bernhard Reutner-Fischer wrote:
> even with MMU (and only ignore HUP on !MMU to re-unify them).
> +~98b
i'm not sure about this. you're introducing a race condition: if someone
sends a signal and it happens to be delivered right after the clone(), then
the child will have its signal handler called and utilize the stack.
although i wonder why you're making this change. glibc doesn't seem to ignore
SIGHUP when forking.
> -static inline attribute_optimize("O3")
> -pid_t _fork_parent(void)
> +static __always_inline
> +pid_t fork_parent(void)
> {
dropping of the -O3 is probably bad. this is to try and make sure there is no
stack usage even when people build with debug flags. if the cloned child tries
to scribble on the stack, everything blows up.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] daemon: block SIGHUP on MMU
On Wednesday 16 November 2011 15:54:02 Bernhard Reutner-Fischer wrote: > +#ifdef __ARCH_USE_MMU__ > + /* Upon _exit of the parent we may get a HUP that we do not want. */ do we have a simple test case ? sounds like glibc would have the same bug. > + fd = sigprocmask(SIG_BLOCK, &new_set, &old_set); > +#else > + sigprocmask(SIG_BLOCK, &new_set, &old_set); > +#endif > ... > +#ifdef __ARCH_USE_MMU__ > + if (fd != -1) > +#endif > + sigprocmask(SIG_SETMASK, &old_set, NULL); probably is fine to let NOMMU do the same thing as MMU with the save/restore -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Friday 04 November 2011 10:07:08 Rich Felker wrote: > On Fri, Nov 04, 2011 at 03:08:25AM +, Grant Edwards wrote: > > On 2011-11-04, Rich Felker wrote: > > > On Thu, Nov 03, 2011 at 01:23:30PM +, Grant Edwards wrote: > > >> It appears that the abort() function somehow breaks the resulting > > >> corefile so that you can't do a post-mortem backtrace. I suspect that > > >> gcc has figured out that the abort() function never returns, so it > > >> doesn't push a return address onto the stack. > > >> > > >> I've managed to work around the problem by doing something like this > > >> > > >> to cause a segfault instead of calling abort(): > > >> *((volatile char*)0) = 0; > > >> > > >> That produces a usable core file. > > >> > > >> But, it would be nice if abort() could be "fixed" somehow... > > > > > > This probably just entails eliminating the noreturn attribute from the > > > prototype... > > > > That's what I thought at first, but when I looked at the source code I > > couldn't find it... Ah, there it is... I finally found the include > > files by switching to the "future" branch. There are no include files > > under "master" for some reason. Well, there are now, but 10 minutes > > ago it said "no repository found". :/ > > > > Removing the __noreturn__ attribute from abort's declaration seems > > like a pretty good idea if it makes core files usable. It's not like > > adding one instruction and taking up one word of stack space is really > > worth the sacrifice in the case of abort(). Premature optimization > > rears it's ugly head once again... ;) > > I would say the same thing about **ALL** noreturn functions, even > exit. For instance if exit crashes (e.g. closing stdio files or > running atexit handlers) you probably want to be able to see where it > was called from... putting that under a debug knob might be fine, but by default, noreturn makes a lot more sense (bloating the code just for debugging? yikes). have you tried not writing crashy code ? :P -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: do not rely upon ulimit kernel syscall.
On Friday 04 November 2011 08:50:02 Bernhard Reutner-Fischer wrote:
> On 3 November 2011 09:31, Carmelo AMOROSO wrote:
> > On several architectures __NR_ulimit syscall number is currently
> > defined but it is remapped onto sys_ni_syscall, while on other
> > architectures they are not longer defined.
> > So use {get,set}rlimit only to implement ulimit interface.
> >
> > It fixes LTP ulimit01 test case.
>
> What about fixing the kernel instead to not define numbers for the
> unavailable stuff?
yeah, that makes more sense to me. if your headers say you have the ulimit
syscall, we shouldn't bother trying to emulate it in userspace. fix the kernel
and be done.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: Add support for bringing librt as needed.
On Wednesday 16 November 2011 05:24:28 William Pitcock wrote: > This helps improve portability with broken applications which expect that > linking directly against libc will bring in mq_*() functions. sorry, but no. fix the broken apps. glibc has the same "problem". -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/2] libcrypt: add support for SHA512-crypt.
On Wednesday 16 November 2011 06:53:34 William Pitcock wrote: > --- a/extra/Configs/Config.in > +++ b/extra/Configs/Config.in > @@ -1174,6 +1174,12 @@ config UCLIBC_HAS_CRYPT_IMPL > help > libcrypt contains crypt(), setkey() and encrypt() > > +config UCLIBC_HAS_SHA512_CRYPT_IMPL > + bool "libcrypt SHA512 support" > + default y > + help > + Say N here if you do not need SHA512 crypt support. shouldn't this "depend UCLIBC_HAS_CRYPT_IMPL" ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: e2fsprogs 1.41.4 builed failed
On Wednesday 16 November 2011 22:28:37 wyang wrote: > GEN_ELF_SOLIB libcom_err.so.2.1 > /homelocal/gcc-4.5.97-uclibc-0.9.97/m68k-uclinux/bin/../m68k-uclinux/libc/m > 5329/usr/lib/crt1.o: In function `_start': > (.text+0x1c): undefined reference to `main' > collect2: ld returned 1 exit status > make[2]: *** [libcom_err.so.2.1] Error 1 you're using a uclinux toolchain which is probably FLAT only (i don't recall m68k ever getting a FDPIC port). thus building shared libraries makes no sense. so don't do that. that said, this isn't a uClibc issue ... might want to try asking whatever vendor gave you your toolchain, or whatever distro you're using. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/2] libcrypt: make crypt() more modular
On Wednesday 16 November 2011 06:27:48 William Pitcock wrote:
> + unsigned int i;
size_t
> + for (i = 0; i < ARRAY_SIZE(crypt_impl_tab); i++)
> + {
cuddle that brace
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: daemon : not atomic, depends on scheduling options
On Tuesday 15 November 2011 11:20:44 Stern, Eli wrote: > Following is a concern that daemon() might fail due to scheduling. > > The daemon() function does not synchronize itself, and so it is prone to > failure depending on system scheduling. Example: > - Last line in a script is a process that uses daemon(). Within daemon: > * parent does fork(); > * Parent gets CPU, child did not start. > * Parent does _exit(); > * The script recognizes that the last line of the script has been > executed, and send a SIGHUP to the pgrp. * Child receives SIGHUP and > exits. > > All this can be avoided if the parent waits on waitpid till the child > detaches (setsid()). At this point the parent receives ECHILD on the > waitpid, and can exit safely. doesn't your test case fail the same way on glibc ? i can't see the glibc code being any different here. and since daemon() isn't covered under POSIX, i'd simply say "if glibc fails in the same way, then oh well". -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Thursday 17 November 2011 14:33:16 Grant Edwards wrote: > On 2011-11-17, Mike Frysinger wrote: > > On Friday 04 November 2011 10:07:08 Rich Felker wrote: > >> On Fri, Nov 04, 2011 at 03:08:25AM +, Grant Edwards wrote: > >> > On 2011-11-04, Rich Felker wrote: > >> > > On Thu, Nov 03, 2011 at 01:23:30PM +, Grant Edwards wrote: > >> > >> It appears that the abort() function somehow breaks the resulting > >> > >> corefile so that you can't do a post-mortem backtrace. I suspect > >> > >> that gcc has figured out that the abort() function never returns, > >> > >> so it doesn't push a return address onto the stack. > >> > >> > >> > >> I've managed to work around the problem by doing something like > >> > >> this > >> > >> > >> > >> to cause a segfault instead of calling abort(): > >> > >> *((volatile char*)0) = 0; > >> > >> > >> > >> That produces a usable core file. > >> > >> > >> > >> But, it would be nice if abort() could be "fixed" somehow... > >> > > > >> > > This probably just entails eliminating the noreturn attribute from > >> > > the prototype... > >> > > >> > That's what I thought at first, but when I looked at the source code I > >> > couldn't find it... Ah, there it is... I finally found the include > >> > files by switching to the "future" branch. There are no include files > >> > under "master" for some reason. Well, there are now, but 10 minutes > >> > ago it said "no repository found". :/ > >> > > >> > Removing the __noreturn__ attribute from abort's declaration seems > >> > like a pretty good idea if it makes core files usable. It's not like > >> > adding one instruction and taking up one word of stack space is really > >> > worth the sacrifice in the case of abort(). Premature optimization > >> > rears it's ugly head once again... ;) > >> > >> I would say the same thing about **ALL** noreturn functions, even > >> exit. For instance if exit crashes (e.g. closing stdio files or > >> running atexit handlers) you probably want to be able to see where it > >> was called from... > > > > putting that under a debug knob might be fine, but by default, > > noreturn makes a lot more sense (bloating the code just for > > debugging? yikes). > > Bloat? It's _one_ flipping instruction! (Two if you do it for exit() > and abort()). incorrect -- you're ignoring the call sites. by assuming the call never returns, it means the caller doesn't have to waste time saving/restoring state. it can also make a difference to DCE. > > have you tried not writing crashy code ? :P > > It's not a "crashy code". It's a way to generate a traceback for fatal > events. based on other responses, sounds like your toolchain needs work independent of uClibc. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: Add support for bringing librt as needed.
On Thursday 17 November 2011 21:12:08 Rich Felker wrote: > On Thu, Nov 17, 2011 at 11:18:16AM -0500, Mike Frysinger wrote: > > On Wednesday 16 November 2011 05:24:28 William Pitcock wrote: > > > This helps improve portability with broken applications which expect > > > that linking directly against libc will bring in mq_*() functions. > > > > sorry, but no. fix the broken apps. glibc has the same "problem". > > For what it's worth, having them in a separate library to begin with > is purely a waste of resources. Every additional .so file loaded > consumes several pages of memory, and of course disk space is also > wasted on extra elf headers and block alignment. Copying the glibc > practice of separating libpthread and librt from libc was just a > mistake that should really be corrected... Users who don't want to > waste the space for these functions can just disable them in the build > config... it isn't that cut & dry. having single images is painful on nommu because it means much bigger chunks of contiguous memory which are often in short supply. it's also slower: the GOT/PLT are larger which means larger insns, symbol lookup is longer (although hashing mitigates much of that), and you have useless pthread overhead all the time. look at how we do thread safe functions in the C library (and how some 3rd party libs do it) -- if libpthread isn't actually loaded, the calls are simple "return 0" stubs. that said, a config option to get a "build everything into libc.so" might be interesting, although probably a bit of work due to the current build system. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: do not rely upon ulimit kernel syscall.
On Thursday 17 November 2011 21:09:57 Rich Felker wrote:
> On Thu, Nov 17, 2011 at 11:14:10AM -0500, Mike Frysinger wrote:
> > On Friday 04 November 2011 08:50:02 Bernhard Reutner-Fischer wrote:
> > > On 3 November 2011 09:31, Carmelo AMOROSO wrote:
> > > > On several architectures __NR_ulimit syscall number is currently
> > > > defined but it is remapped onto sys_ni_syscall, while on other
> > > > architectures they are not longer defined.
> > > > So use {get,set}rlimit only to implement ulimit interface.
> > > >
> > > > It fixes LTP ulimit01 test case.
> > >
> > > What about fixing the kernel instead to not define numbers for the
> > > unavailable stuff?
> >
> > yeah, that makes more sense to me. if your headers say you have the
> > ulimit syscall, we shouldn't bother trying to emulate it in userspace.
> > fix the kernel and be done.
>
> I really have to ask... WHY? Why bother with extra code complexity and
> maintenance burden to support using an ancient, deprecated syscall for
> a deprecated nonstandard userspace function when it can be cleanly and
> universally emulated in terms of a modern, universally-supported
> standard function?
your argument has nothing to do with the topic at hand
ulimit() is part of POSIX, although marked as obsolete in Issue 7. so if you
don't want it, don't enable UCLIBC_SUSV4_LEGACY.
taking all of that into consideration, i don't know what the point of your e-
mail is here.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCHv2] libc/x86: fix stack unwinding and backtrace information
please split this patch up. looks to me like you're addressing at least 3 different issues here. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: s/CROSS/CROSS_COMPILE/g
On Friday 28 October 2011 00:32:35 Carmelo AMOROSO wrote: > On 27/10/2011 23.04, Mike Frysinger wrote: > > On Thu, Oct 27, 2011 at 17:54, Carmelo AMOROSO wrote: > >> On 27/10/2011 17.32, Mike Frysinger wrote: > >>> On Thu, Oct 27, 2011 at 16:42, Carmelo AMOROSO wrote: > >>>> +ifndef CROSS_COMPILE > >>>> +CROSS_COMPILE= > >>>> endif > >>> > >>> this is kind of useless logic. i would change it to one line: > >>> CROSS_COMPILE ?= $(CROSS) > >> > >> I've really done a sed, so I've kept the original logic. > >> IIUC you are suggesting to keep both CROSS and CROSS_COMPILE option, > >> If so, it should be the opposite > >> > >> CROSS ?= $(CROSS_COMPILE) > >> > >> shouldn't it ? > > > > considering you changed everything else to use $(CROSS_COMPILE), i > > think what i proposed makes the most sense. > > I've understood you suggested to keep the code as is, and in case > CROSS_COMPILE was used, use it to set CROSS. i'll try to be clear then: we should use CROSS_COMPILE everywhere, and the only place $(CROSS) should show up is as the default value of CROSS_COMPILE (purely to keep existing systems that compile uClibc working). so rather than this: ifndef CROSS_COMPILE CROSS_COMPILE= endif use this one line: CROSS_COMPILE ?= $(CROSS) -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/3] libc/x86: add dwarf-2 cfi unwinding information to syscalls
On Sunday 20 November 2011 03:50:46 Timo Teräs wrote: > Fixes unwinding of stack traces across system calls. Thus debuggers can > show proper backtrace when inside a syscall. > > Additionally, this fixes a race condition: if a signal happens while inside > syscall, and the signal handler aborts the thread, we would have been > unable to unwind the stack and run the proper error handler. > > This patch also removes the "xchg ebx, register" trickery - it's very hard > to add proper CFI info within macroes. It apparently never worked 100% > reliably, and the speed gain is probably insignificant on modern > processors. we should import the sysdeps/unix/sysv/linux/i386/sysdep.h logic from glibc to fix this. they have the optimizations we want, and have cfi handling. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Sunday 20 November 2011 15:13:17 Grant Edwards wrote:
> On 2011-11-17, Mike Frysinger wrote:
> >> I would say the same thing about **ALL** noreturn functions, even
> >> exit. For instance if exit crashes (e.g. closing stdio files or
> >> running atexit handlers) you probably want to be able to see where it
> >> was called from...
> >
> > putting that under a debug knob might be fine, but by default,
> > noreturn makes a lot more sense (bloating the code just for
> > debugging? yikes).
>
> After removing __noreturn__ from abort() my complete
> kernel+rootfs+apps uImage size (compressed) increased from 7373224
> bytes to 7373412 bytes. That's a change of 188 bytes out of 7.3
> million, or 0.0025%.
it also introduces wrong warnings to valid code:
int foo(int j) {
int i;
if (j < 100)
abort();
else
i = 100;
return j - i;
}
w/out noreturn attribute, "i" gets warned about because it's used
uninitialized. yes, this is a contrived example, but it's trivial to see how
this is used in real world code. try disabling BUG() in the kernel and look
at all the build warnings due to that.
> Not really a lot of "bloat", but it's apparently a moot point now: I
> filed a bug requesting that the __noreturn__ attribute be removed from
> abourt() so that it produces backtraceable core files, but the bug has
> been declared "invalid".
yes, because from the perspective of uClibc, your report is invalid. there is
a bug in the toolchain, but it most likely is not from uClibc. report it to
whoever is providing your gcc/gdb ports.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Monday 21 November 2011 10:11:29 Grant Edwards wrote: > Then put the __noreturn__ back in for the version of stdlib.h used by > that code. To fix the "no return PC" problem, all that matters is that > when the source code for abort() is compiled you don't tell gcc not to > provide a return address. that makes it sound even more like a gcc/gdb bug > > yes, because from the perspective of uClibc, your report is invalid. > > there is a bug in the toolchain, but it most likely is not from uClibc. > > report it to whoever is providing your gcc/gdb ports. > > It's plain vanilla gcc/gdb as built by crosstool-ng for ARM. Can you > recommend a different toolchain that works correctly with uClibc? Or > perhaps we shouldn't use ARM processors with uClibc? ask someone working on gcc/gdb -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
at this point, you're just wasting people's time. uClibc is not broken. you're barking up the wrong tree. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Thursday 24 November 2011 00:51:08 Grant Edwards wrote: > Sorry if I stepped on somebody's toes, but I thought it seemed like a > reasonable request. AFAICT, GCC is the only toolchain that uClibc is > used with, and ARM is by far the most popular embedded Linux > architecture, so I presumed that making uClibc play well with gcc/ARM > would be A Good Thing(TM). it is not a reasonable request to add workarounds to common uClibc code in order to workaround bugs in other projects and specific arches. you haven't shown that this is a bug in uClibc, so until you do, it makes no sense to change the code. we don't go blindly throwing changes in the source tree until things "seem to work". you find the *real* problem, figure out *why*, and then post fixes to the *correct* places. anything else is an unmaintainable pile of crap. so as soon as you come up with real information that says that there is an actual bug in uClibc, you're wasting everyone's time. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: do not rely upon ulimit kernel syscall.
On Wednesday 23 November 2011 11:22:04 Carmelo AMOROSO wrote:
> On 17/11/2011 17.14, Mike Frysinger wrote:
> > On Friday 04 November 2011 08:50:02 Bernhard Reutner-Fischer wrote:
> >> On 3 November 2011 09:31, Carmelo AMOROSO wrote:
> >>> On several architectures __NR_ulimit syscall number is
> >>> currently defined but it is remapped onto sys_ni_syscall, while
> >>> on other architectures they are not longer defined. So use
> >>> {get,set}rlimit only to implement ulimit interface.
> >>>
> >>> It fixes LTP ulimit01 test case.
> >>
> >> What about fixing the kernel instead to not define numbers for
> >> the unavailable stuff?
> >
> > yeah, that makes more sense to me. if your headers say you have
> > the ulimit syscall, we shouldn't bother trying to emulate it in
> > userspace. fix the kernel and be done. -mike
>
> you are lucky because blackfin is one of the few arch that have a
> cleaned syscall table lists (all ni are commented in unistd.h).
>
> In my case, SH4, I hit the problem, and as in my case all other archs
> with "dirty" syscall table are affected as well.
if the syscall is dead in your arch, then delete it from asm/unistd.h. the
__NR_ table is not an immutable list.
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3
On Saturday 26 November 2011 19:07:44 Khem Raj wrote: > If I build the root file system without this patch everything works > as expected. Could you explain why this commit is needed ? it's a merge commit that happens when you merge a branch that isn't a fast forward. it isn't an actual "commit" ... -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Wednesday 23 November 2011 18:39:50 Rich Felker wrote: > On Mon, Nov 21, 2011 at 11:35:24PM -0500, Mike Frysinger wrote: > > at this point, you're just wasting people's time. uClibc is not broken. > > you're barking up the wrong tree. > > This sounds unsettlingly drepperesque... there is no information to show uClibc is broken. i don't think it's broken. glibc doesn't seem to have a problem with building abort() with noreturn. so until there is more information that shows a change in uClibc is necessary, he is wasting people's time. if saying no to changes that lack any real details is "drepperesque" in your opinion, then i guess that's your problem. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] Make link-local addresses resolvable via running avahi-daemon.
On Wednesday 23 November 2011 08:31:33 Nikolaus Voss wrote:
> nss-mdns is an extension to glibc to support resolution of link-local
> (.local) addresses via GNU Name Service Switch (NSS) which redirects
> the queries to a running avahi-daemon, which in turn does the resolution
> via multicast DNS (mdns).
>
> However, this does not work for uClibc, as it does not support NSS.
since we don't support NSS (or any similar approach), this is unfortunately
the only way to handle things. if we get more requests, perhaps we can look
at adding an array of callbacks which the resolv code would walk ...
> --- /dev/null
> +++ b/libc/inet/avahi.c
>
> +int __avahi_resolve_name(int af, const char* name, void* data)
> attribute_hidden;
> +int __avahi_resolve_address(int af, const void *data, char* name,
> + size_t name_len) attribute_hidden;
once you have a local header, you can delete this
> +static int set_cloexec(int fd)
> +static FILE *open_socket(void)
please add "avahi" prefixes to these (yes, even though they're static)
> +static int set_cloexec(int fd)
> +{
> + int n;
> +
> + assert(fd >= 0);
> +
> + if ((n = fcntl(fd, F_GETFD)) < 0)
> + return -1;
> +
> + if (n & FD_CLOEXEC)
> + return 0;
> +
> + return fcntl(fd, F_SETFD, n|FD_CLOEXEC);
> +}
delete this func ...
> +static FILE *open_socket(void)
> +{
> + int fd = -1;
> + struct sockaddr_un sa;
> + FILE *f = NULL;
> +
> + if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0)
> + goto fail;
add SOCK_CLOEXEC to the type field
> + set_cloexec(fd);
add __ASSUME_SOCK_CLOEXEC to sysdeps/linux/common/bits/kernel-features.h (see
the file in glibc). then use:
#ifndef __ASSUME_SOCK_CLOEXEC
fcntl_not_cancel(fd, F_SETFD, FD_CLOEXEC);
#endif
i don't think there's any actual flags we need to worry about here ?
> + if (!(f = fdopen(fd, "r+")))
> + goto fail;
i wonder if we really need to use the stdio layer here. we currently always
build dprintf(), and that seems to be the only real reason for it ...
> + fprintf(f, "RESOLVE-HOSTNAME%s %s\n", af == AF_INET ? "-IPV4" : "-IPV6",
> name);
might as well trim this slightly:
fprintf(f, "RESOLVE-HOSTNAME-IPV%c %s\n", af == AF_INET ? 4 : 6, name);
> + if (!(fgets(ln, sizeof(ln), f)))
don't need the paren around fgets here
> + /* Cut off end of line */
> + *(p + strcspn(p, "\n\r\t ")) = 0;
p[strcspn(p, "\n\r\t ")] = 0;
> --- a/libc/inet/resolv.c
> +++ b/libc/inet/resolv.c
>
> +#ifdef __UCLIBC_HAS_AVAHI_RES__
> +extern int __avahi_resolve_name(int af, const char* name,
> + void* data) attribute_hidden;
> +
> +extern int __avahi_resolve_address(int af, const void *data, char* name,
> +size_t name_len) attribute_hidden;
> +#endif
please add a local header file for this. most of the local extern's in this
file are due to the multiplexed nature (all the L_xxx), so the extern's are in
the same file as both the definition and the users. but that doesn't apply to
the avahi code.
> @@ -1963,7 +1971,6 @@
> libc_hidden_def(getnameinfo)
> #endif
>
> -
> #ifdef L_gethostbyname_r
>
> /* Bug 671 says:
please don't add unrelated whitespace changes
> - if (inet_aton(name, in)) {
> +#ifdef __UCLIBC_HAS_AVAHI_RES__
> + if (!__avahi_resolve_name(AF_INET, name, in) ||
> +#else
> + if (
> +#endif
in the local header, you can do:
#ifdef __UCLIBC_HAS_AVAHI_RES__
extern ...;
#else
static inline int ...{ return 1; }
#endif
then we can drop the #ifdef's in this file
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/2] libdl: fix pointer-width problems with _dl_tls_symaddr() calls.
On Tuesday 01 November 2011 18:51:02 William Pitcock wrote: > Casting a pointer to Elf32_Addr type will discard 32 bits from the > pointer address. Using unsigned long ensures that a pointer is 64-bit > safe. > > --- a/ldso/libdl/libdl.c > +++ b/ldso/libdl/libdl.c > > ret = _dl_tls_symaddr ((struct link_map *)sym_ref.tpnt, > ret = _dl_tls_symaddr ((struct link_map *)sym_ref.tpnt, > - (Elf32_Addr) ret); > + (unsigned long) ret); i don't think this works. the _dl_tls_symaddr() func still takes an Elf32_Addr argument, so it still gets implicitly cast from unsigned long to Elf32_Addr. so if this is going to be fixed, you'd want to use ElfW(Addr) in both places as suggested by Carmelo. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: LD_LIBRARY_PATH issue
On Wednesday 02 November 2011 06:12:55 Mahanteshwari Hiremath wrote: > i am using buildroot. whenever I am using uclibc compiler to run an > application, during which i am exporting LD_LIBRARY_PATH in command line > for running that application. after this export if itry to use any of the > commands like ls or ldd or clear or printenv (many more), none of these > are giving proper output rather giving a message this isn't a bug; LD_LIBRARY_PATH affects the active programs. set the var for the one app you want to run only rather than exporting for all. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[RFC/PATCH] buildsys: cache build flags in vars
Running `make clean` atm takes like 20 seconds because every subdir re-evaluates all the toolchain flags. Add some helpers to automate the process of setting up variables to cache the result of tests, as well as the checking of an already set flag. Now `make clean` takes like 2 seconds on my system. Signed-off-by: Mike Frysinger --- Makerules |6 +- Rules.mak | 178 + ldso/ldso/Makefile.in |4 +- test/Rules.mak|3 +- 4 files changed, 128 insertions(+), 63 deletions(-) diff --git a/Makerules b/Makerules index 110ba39..6954b94 100644 --- a/Makerules +++ b/Makerules @@ -308,7 +308,7 @@ define link.so @$(disp_ld) $(Q)$(CC) $(LDFLAGS-$(notdir $@)) $(LDFLAGS-y-$(@F)) \ -Wl,-soname=$(notdir $@).$(2) \ - $(NOSTDLIB_CFLAGS) -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ + $(CFLAG_-nostdlib) -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ -Wl,--whole-archive $(firstword $^) -Wl,--no-whole-archive \ $(LIBS-$(notdir $@)) $(LIBGCC) $(END_FILE-$(notdir $@)) $(Q)$(LN) -sf $(1) $@.$(2) @@ -333,7 +333,7 @@ LINK_FLAT_CRTS := $(top_builddir)lib/Scrt1.o $(top_builddir)lib/crti.o \ define link-flat.so $(Q)$(RM) $(1) $@ @$(disp_ld) - $(Q)$(CC) $(LDFLAGS-$(notdir $@)) $(NOSTDLIB_CFLAGS) -o $(1) \ + $(Q)$(CC) $(LDFLAGS-$(notdir $@)) $(CFLAG_-nostdlib) -o $(1) \ -Wl,-elf2flt -Wl,-shared-lib-id,$(2) $(top_builddir)lib/Scrt1.o \ $(top_builddir)/lib/crti.o -Wl,--whole-archive $(firstword $^) \ $(LIBGCC) -Wl,--no-whole-archive $(LIBS-$(notdir $@)) $(LIBGCC) \ @@ -345,7 +345,7 @@ define linkm.so $(do_strip) @$(disp_ld) $(Q)$(CC) $(LDFLAGS-$(notdir $@)) -Wl,-soname=$(notdir $@).$(2) \ - $(NOSTDLIB_CFLAGS) -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ + $(CFLAG_-nostdlib) -o $(dir $@)$(1) $(START_FILE-$(notdir $@)) \ $^ \ $(LIBS-$(notdir $@)) $(LIBGCC) $(END_FILE-$(notdir $@)) $(Q)$(LN) -sf $(1) $@.$(2) diff --git a/Rules.mak b/Rules.mak index c419174..4dafa22 100644 --- a/Rules.mak +++ b/Rules.mak @@ -173,6 +173,48 @@ check_ld=$(shell \ if $(LD) $(1) -o /dev/null -b binary /dev/null > /dev/null 2>&1; \ then echo "$(1)"; fi) +# Use variable indirection here so that we can have variable +# names with fun chars in them like equal signs +define check-tool-var +_v = $(2)_$(3) +ifndef $$(_v) +$$(_v) := $$(call $(1),$(subst %, ,$(3))) +export $$(_v) +endif +endef + +# Usage: check-gcc-var, +# Check the C compiler to see if it supports . +# Export the variable CFLAG_ if it does. +define check-gcc-var +$(call check-tool-var,check_gcc,CFLAG,$(1)) +endef +# Usage: check-as-var, +# Check the assembler to see if it supports . Export the +# variable ASFLAG_ if it does (for invoking the assembler), +# as well CFLAG_-Wa (for invoking the compiler driver). +define check-as-var +$(call check-tool-var,check_as,ASFLAG,$(1)) +export CFLAG_-Wa$(1) = $(if $$(ASFLAG_$(1)),-Wa$(comma)$$(ASFLAG_$(1))) +endef +# Usage: check-ld-var, +# Check the linker to see if it supports . Export the +# variable LDFLAG_ if it does (for invoking the linker), +# as well CFLAG_-Wl (for invoking the compiler driver). +define check-ld-var +$(call check-tool-var,check_ld,LDFLAG,$(1)) +export CFLAG_-Wl$(1) = $(if $$(LDFLAG_$(1)),-Wl$(comma)$$(LDFLAG_$(1))) +endef +# Usage: cache-output-var,, +# Execute and cache the output in . +define cache-output-var +ifndef $(1) +$(1) := $$(shell $(2)) +export $(1) +endif +endef + + ARFLAGS:=cr @@ -180,24 +222,37 @@ ARFLAGS:=cr OPTIMIZATION:= # Use '-Os' optimization if available, else use -O2, allow Config to override -OPTIMIZATION+=$(call check_gcc,-Os,-O2) +$(eval $(call check-gcc-var,-Os)) +ifneq ($(CFLAG_-Os),) +OPTIMIZATION += $(CFLAG_-Os) +else +$(eval $(call check-gcc-var,-O2)) +OPTIMIZATION += $(CFLAG_-O2) +endif # Use the gcc 3.4 -funit-at-a-time optimization when available -OPTIMIZATION+=$(call check_gcc,-funit-at-a-time,) +$(eval $(call check-gcc-var,-funit-at-a-time)) +OPTIMIZATION += $(CFLAG_-funit-at-a-time) # shrinks code by about 0.1% -OPTIMIZATION+=$(call check_gcc,-fmerge-all-constants) -OPTIMIZATION+=$(call check_gcc,-fstrict-aliasing) +$(eval $(call check-gcc-var,-fmerge-all-constants)) +$(eval $(call check-gcc-var,-fstrict-aliasing)) +OPTIMIZATION += $(CFLAG_-fmerge-all-constants) $(CFLAG_-fstrict-aliasing) -GCC_MAJOR_VER?=$(shell $(CC) -dumpversion | cut -d . -f 1) -#GCC_MINOR_VER?=$(shell $(CC) -dumpversion | cut -d . -f 2) +$(eval $(call cache-output-var,GCC_VER,$(CC) -dumpversion)) +GCC_VER := $(subst ., ,$(GCC_VER)) +GCC_MAJOR_VER ?= $(word 1,$(GCC_VER)) +#GCC_MINOR_VER ?= $(word 2,$(GCC_VER)) ifeq ($(GCC_MAJOR_VER),4) # shrinks code, results are from 4.0.2 # 0.36% -OPTIMIZATION+=$(call che
prelink breaks fdpic support in a bunch of places
there seems to be a bunch of changes that the associated changelog does not
seem to cover. so i don't know if they were changed on purpose, by accident,
etc...
> commit a33796043bdef5345bc00a528c942f91a87af8e9
> ldso: Add runtime prelink support
>
> _dl_load_elf_shared_library(int secure,...)
> ...
> - DL_LOADADDR_TYPE lib_loadaddr;
> + DL_LOADADDR_TYPE lib_loadaddr = 0;
why is this necessary ? nothing else in this func changed. you can't assign
directly to a variable of type DL_LOADADDR_TYPE.
> int _dl_fixup(struct dyn_elf *rpnt, struct r_scope_elem *scope, int now_flag)
> ...
> - elf_machine_relative(tpnt->loadaddr, reloc_addr, relative_count);
> + if (tpnt->loadaddr
> +#ifdef __LDSO_PRELINK_SUPPORT__
> + || (!tpnt->dynamic_info[DT_GNU_PRELINKED_IDX])
> +#endif
> + )
> + elf_machine_relative(tpnt->loadaddr, reloc_addr,
> relative_count);
why is tpn->loadaddr now being checked ?
> DL_START(unsigned long args)
> ...
> - elf_machine_relative(load_addr, rel_addr, relative_count);
> + if (load_addr
> +#ifdef __LDSO_PRELINK_SUPPORT__
> + || !tpnt->dynamic_info[DT_GNU_PRELINKED_IDX]
> +#endif
> + )
> + elf_machine_relative(load_addr, rel_addr, relative_count);
why is load_addr now being checked ?
> commit 94cc6edb78a12655c0602a246fa1cbdc8c6d0ad9
> ldso: Rework global scope handling and symbol lookup mechanism
>
> DL_START(unsigned long args)
> ...
> - DL_BOOT_COMPUTE_DYN(dpnt, got, load_addr);
> + DL_BOOT_COMPUTE_DYN(dpnt, got, (DL_LOADADDR_TYPE)header);
why was that cast added and changed from load_addr to header ?
> commit 637e2b2440f69e22932edd71bd2f0b1210dc32ea
> ldso: Add implementation of ld.so standalone execution
>
> DL_START(unsigned long args)
> ...
> - _dl_elf_main = (int (*)(int, char **, char **))
> - auxvt[AT_ENTRY].a_un.a_val;
> - _dl_get_ready_to_run(tpnt, load_addr, auxvt, envp, argv
> - DL_GET_READY_TO_RUN_EXTRA_ARGS);
> + _dl_elf_main = (int (*)(int, char **, char **))
> + _dl_get_ready_to_run(tpnt, (DL_LOADADDR_TYPE) header, auxvt,
> envp,
> +argv, DL_GET_READY_TO_RUN_EXTRA_ARGS);
why was load_addr changed to header and the cast added ?
> commit b9766aa08c90b6718d5497d6a6cf9e6f737e5141
> ldso: Fix loadaddr and mappaddr when prelink support is enabled.
>
> add_ldso(struct elf_resolve *tpnt,...)
> ...
> + tpnt->mapaddr = load_addr;
mapaddr is of type ElfW(Addr) but load_addr is of type DL_LOADADDR_TYPE. you
cannot assign one to the other.
> _dl_load_elf_shared_library(int secure, ...)
> ...
> tryaddr = (piclib == 2 ? 0
> : (char *) (ppnt->p_vaddr & PAGE_ALIGN)
> - + (piclib ? libaddr : 0));
> + + (piclib ? libaddr : lib_loadaddr));
you can't read the value of lib_loadaddr directly, so this change is broken.
there were more in the original patch, but it seems a change since (by Bernd?)
fixed the others.
> - /* For a non-PIC library, the addresses are all absolute */
> - if (piclib) {
> + /*
> +* The dynamic_addr must be take into acount lib_loadaddr value, to note
> +* it is zero when the SO has been mapped to the elf's physical addr
> +*/
> + if (lib_loadaddr) {
> dynamic_addr = (unsigned long) DL_RELOC_ADDR(lib_loadaddr,
> dynamic_addr);
> }
we have piclib because you can't read lib_loadaddr directly (it's of type
DL_LOADADDR_TYPE), so this is broken
> - tpnt->ppnt = (ElfW(Phdr) *) DL_RELOC_ADDR(tpnt->loadaddr,
> epnt->e_phoff);
> + tpnt->ppnt = (ElfW(Phdr) *) DL_RELOC_ADDR(tpnt->mapaddr, epnt->e_phoff);
we needed this to be the loadaddr, not the mapaddr ... they aren't the same
type, so they aren't directly interchangeable
-mike
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: abort() missing return-address => useless core file
On Sunday 27 November 2011 11:09:55 Joseph S. Myers wrote: > On Sun, 27 Nov 2011, Grant Edwards wrote: > > Gcc has the same problem with abort() on ARM. See this thread: > It was fixed by: > > 2009-11-23 Paul Brook > > * config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Add special > case for noreturn functions. > (arm_compute_save_reg_mask): Remove special noreturn handling. > > http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01234.html thanks. this is why i'm insistent on finding the real source of the problem and getting it fixed there rather than blindly patching code. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v2 2/2] Make link-local addresses resolvable via running avahi-daemon
On Monday 28 November 2011 10:22:42 Nikolaus Voss wrote:
> --- a/extra/Configs/Config.in
> +++ b/extra/Configs/Config.in
>
> +config UCLIBC_HAS_AVAHI_RES
> + default y
this should not default to "on" ;)
> + depends on UCLIBC_HAS_SOCKET
i think this should be:
depends on UCLIBC_HAS_IPV4 || UCLIBC_HAS_IPV6
> --- /dev/null
> +++ b/libc/inet/avahi.c
>
> +static FILE* avahi_open_socket(void)
static FILE *avahi_open_..
> + int fd = -1;
not really needed to set to -1 since the first thing you do is assign it
> + if ((fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0)) < 0)
let's get away from inlining assignments in "if" statements:
fd = socket(...);
if (fd < 0)
...
this applies to a bunch of places in this patch ...
> +#ifndef __ASSUME_SOCK_CLOEXEC
> + fcntl_not_cancel(fd, F_SETFD, FD_CLOEXEC);
> +#endif
i think you're missing the update to kernel-features.h ;)
> + sizeof(sa.sun_path)-1);
> + sa.sun_path[sizeof(sa.sun_path)-1] = 0;
space around that "-"
> + if (connect(fd, (struct sockaddr*) &sa, sizeof(sa)) < 0)
space before the "*"
> +fail:
> + if (fd >= 0)
> + close(fd);
add a different label to skip the close() and thus avoid the if check
> +static int avahi_ends_with(const char *name, const char* suffix) {
brace needs to be on the 2nd line
> + assert(name);
> + assert(suffix);
the C library should not assert() :). return an error.
> +int attribute_hidden __avahi_resolve_name(int af, const char* name, void*
the hidden attribute is in the header file which you've included, so you don't
need it here
> +finish:
> + if (f)
> + fclose(f);
use a diff label to return early to avoid the if check
> --- /dev/null
> +++ b/libc/inet/avahi.h
>
> +#ifndef _AVAHI_H_
> +#define _AVAHI_H_
might want to put UCLIBC in there just in case ...
> --- a/libc/inet/resolv.c
> +++ b/libc/inet/resolv.c
>
> + // is this a .local address?
no C++ comments. use /* comment */ style.
> + if (!__avahi_resolve_address(type, in, buf, buflen))
> + {
cuddle up that brace
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v2 1/2] gethostbyaddr_r: add space for alias pointers
On Monday 28 November 2011 11:25:49 Voss, Nikolaus wrote: > Nikolaus Voss wrote on 2011-11-28: > > alias = (char **)buf; > > > > + buf += sizeof(*addr_list) * 2; > > + buflen -= sizeof(*addr_list) * 2; > > this should be sizeof(alias) instead of sizeof(*addr_list) of course. i bet someone has filed a bug on this before ;) -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: prelink breaks fdpic support in a bunch of places
On Monday 28 November 2011 07:18:50 Filippo ARCIDIACONO wrote: > Definitively it needs to review handling of DL_LOADDADDR_TYPE variables > To extend the prelink support also for fdpic archs. atm, i don't think anyone is running FDPIC on systems with virtual memory. if you don't have virtual memory, then prelink will never work since it, by design, tries to assume the default load address is the same across invocations which requires virtual memory. what's the next step ? do you plan on trying to fix these problems with the prelink code ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v2 2/2] Make link-local addresses resolvable via running avahi-daemon
On Tuesday 29 November 2011 04:16:25 Voss, Nikolaus wrote: > Mike Frysinger wrote on 2011-11-29: > > On Monday 28 November 2011 10:22:42 Nikolaus Voss wrote: > > > +#ifndef __ASSUME_SOCK_CLOEXEC > > > + fcntl_not_cancel(fd, F_SETFD, FD_CLOEXEC); > > > +#endif > > > > i think you're missing the update to kernel-features.h ;) > > Yes, I did ;-). Why is __ASSUME_SOCK_CLOEXEC commented out in > kernel-features.h (as opposed to glibc)? I guess there must > be a good reason for this? i think no one was using it, so it was left disabled -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v2 2/2] Make link-local addresses resolvable via running avahi-daemon
On Tuesday 29 November 2011 01:53:15 Bernhard Reutner-Fischer wrote: > On Nov 29, 2011 6:04 AM, "Mike Frysinger" wrote: > > On Monday 28 November 2011 10:22:42 Nikolaus Voss wrote: > > > --- a/extra/Configs/Config.in > > > +++ b/extra/Configs/Config.in > > > > > > +config UCLIBC_HAS_AVAHI_RES > > > + default y > > > > this should not default to "on" ;) > > > > > + depends on UCLIBC_HAS_SOCKET > > > > i think this should be: > >depends on UCLIBC_HAS_IPV4 || UCLIBC_HAS_IPV6 > > I think it should depend on HAS_RESOLVER. i thought that as well, except HAS_RESOLVER doesn't control the funcs Nikolaus is modifying (the gethostbyname/gethostbyaddr). those are controlled by the IPV4||IPV6 defines. hence my suggestion of using those knobs. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: prelink breaks fdpic support in a bunch of places
On Tuesday 29 November 2011 07:20:08 Carmelo AMOROSO wrote: > On 29/11/2011 6.07, Mike Frysinger wrote: > > On Monday 28 November 2011 07:18:50 Filippo ARCIDIACONO wrote: > >> Definitively it needs to review handling of DL_LOADDADDR_TYPE > >> variables To extend the prelink support also for fdpic archs. > > > > atm, i don't think anyone is running FDPIC on systems with virtual > > memory. if you don't have virtual memory, then prelink will never > > work since it, by design, tries to assume the default load address > > is the same across invocations which requires virtual memory. > > > > what's the next step ? do you plan on trying to fix these problems > > with the prelink code ? > > we are committed to review this code and post patches for testing/review. thanks. if there's any patches you want me to test, i'll give them a spin. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] sys/queue.h: update to eglibc version
On Friday 16 December 2011 05:06:25 Natanael Copa wrote: > On Fri, Dec 16, 2011 at 10:53 AM, Natanael Copa wrote: > > Xen needs SIMPLEQ_* queue types which was not provided from the old > > uclibc queue.h. > > > > Use same implementation as eglibc. > > Grabbed from: http://www.eglibc.org/svn/trunk/libc/misc/sys/queue.h > > Forgot signed-off. sorry. > > Will resend. > > (Is there some way to add always-signed-off to .git/config?) not directly. you could use an alias which always adds -s, but that sounds dangerous ... git config alias.ci 'commit -s' git ci -m 'foo' -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 1/3] libcrypt: make crypt() itself more modular
On Saturday 17 December 2011 05:40:51 William Pitcock wrote: > --- a/libcrypt/crypt.c > +++ b/libcrypt/crypt.c > > +#include why do you need this ? > +#define ARRAY_SIZE(v) (sizeof(v) / sizeof((v)[0])) NAK: this is in include/libc-internal.h now -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH 2/3] libcrypt: add support for SHA512-CRYPT password hashing
On Saturday 17 December 2011 05:54:35 William Pitcock wrote: > --- a/extra/Configs/Config.in > +++ b/extra/Configs/Config.in > > +config UCLIBC_HAS_SHA512_CRYPT_IMPL > + bool "libcrypt SHA512 support" > + depends on UCLIBC_HAS_CRYPT_IMPL > + default y i'm not sure about defaulting to "y" (same for the sha256) ... not sure if anyone else has an opinion on this ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v4 1/3] libcrypt: make crypt() itself more modular
all three look fine to me Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH v4 1/3] libcrypt: make crypt() itself more modular
On Tuesday 20 December 2011 02:18:17 William Pitcock wrote: > On Mon, Dec 19, 2011 at 1:30 PM, Bernhard Reutner-Fischer wrote: > > Would be perfect with a func impl, most likely. > > I agree that the macro approach is suboptimal for both type-safety > reasons and expansion issues, however, Ulrich's implementation uses an > inline function which is unsafe, and the macro version of the code > would need some reworking to work as a standalone function. having it be a macro or a static inline would largely get you the same result. it'd have to be a static non-inline func, and leave it up to gcc to calculate when to inline and when to make func calls. > This also > raises the question of what to do with the function -- should we just > make an internal file for libcrypt for utility functions or just have > them as static inlined functions inside the code? it depends on what the func does. if it's only useful to libcrypt, then it should stay in libcrypt as a hidden func. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libubacktrace: do not try to wrap _Unwind_GetIP with function pointer
On Fri, Dec 30, 2011 at 15:45, Abdoulaye Walsimou Gaye wrote: > Trying to wrap _Unwind_GetIP with function pointer makes libubacktrace > not working for ARM, as it is defined as a preprocessor macro like this > in gcc-4.6.2: > #define _Unwind_GetIP(context) \ > (_Unwind_GetGR (context, 15) & ~(_Unwind_Word)1) this change however breaks the whole point -- to not link against libgcc_s.so directly -mike ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ERRATUM][PATCH] Fix _dl_ldsopath when no slash in INTERP path
On Thursday 22 December 2011 19:19:01 Ignacy Gawędzki wrote: > When the INTERP program header contains a simple name with no slash, don't > crash trying to dereference a NULL pointer, but rather set _dl_ldsopath to > ".". what is your actual use case ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: getpass fgets check
On Friday 23 December 2011 08:45:38 Joakim Tjernlund wrote: > > From: Denys Vlasenko > > On Tue, Dec 20, 2011 at 8:43 AM, Daniel Wainwright wrote: > > > I believe there is a simple error in getpass.c, line 80: > > > > > > static char buf[PWD_BUFFER_SIZE]; > > > > I propose the following patch (sorry, it's attached, not inline). > > > > * fixes bogus fgets error check > > * fixes bogus strlen() < 0 check > > * switches off buffering regardless of tcgetattr() success > > * prints newline even on error or if there was no '\n' on input > > * uses sizeof(buf) instead of PWD_BUFFER_SIZE > > +if (!fgets (buf, sizeof(buf)-1, in)) > > Should probably be sizeof(buf) instead of sizeof(buf)-1 as per earlier > mail. any response Denys ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [ERRATUM][PATCH] Fix _dl_ldsopath when no slash in INTERP path
On Sunday 01 January 2012 03:57:37 Ignacy Gawędzki wrote: > On Sat, Dec 31, 2011 at 06:12:00PM -0500, thus spake Mike Frysinger: > > On Thursday 22 December 2011 19:19:01 Ignacy Gawędzki wrote: > > > When the INTERP program header contains a simple name with no slash, > > > don't crash trying to dereference a NULL pointer, but rather set > > > _dl_ldsopath to ".". > > > > what is your actual use case ? > > I'm testing a dynamic loader. So I have a binary compiled with > -Wl,-Iloader.so and have a symlink called loader.so in the current > directory pointing to the actual loader I want to use. When the symlink > points to uClibc's loader, the program crashes. your proposed fix was more complicated than necessary. i've checked in some simpler code. please test and verify (but it seems to work for me). -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [git commit] libubacktrace: use -funwind-tables rather than -fexecptions
On Tuesday 03 January 2012 11:34:40 Carmelo AMOROSO wrote: > On 01/01/2012 0.10, Mike Frysinger wrote: > > On Thursday 22 December 2011 13:19:22 Carmelo AMOROSO wrote: > >> On 22/12/2011 15.30, Carmelo Amoroso wrote: > >>> For backtrace to work is enough to use -funwind-tables instead > >>> of -fexceptions. > >> > >> Indeed, I'm wondering if -fasynchrous-unwind-tables should be > >> used rather then funwind-tables. On my arh SH4 the generated code > >> is exactly the same. I'm not expert of DWARF, neither gcc > >> documentation regarding the differences between -fexceptions, > >> -funwind-tables or -fasynchronous-unwind-tables helped me so > >> much. > >> > >> someone else has clearer idea ? > > > > for backtrace, we just want unwind-tables, so using that over > > -fexceptions is good (since we don't have to handle exceptions in > > this code). as for the async vs non-async unwind-tables, i don't > > know the answer to that. > > I've reported here below the extract from gcc manual. Reading it > again, it seems to me that using -fasynchronous-unwind-tables is the > best as it's purpose is actually to create the dwarf2 information, in > the other two cases (-fexceptions or -funwind-tables) it seems to be a > side effect. glibc seems to prefer -fasynchronous-unwind-tables, so that's probably good for us too we need -fexceptions if the funcs themselves need to handle exceptions. but if we only want other things to be able to build a backtrace across the call, then -fasynchronous-unwind-tables should be sufficient. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: make system() block SIGCHLD
On Friday 13 January 2012 22:09:04 Rich Felker wrote: > In particular, in a multi-threaded program also from that POSIX page: * The system() function need not be thread-safe. makes me wonder if we shouldn't just gut the pthread locking from the NPTL version that was straight copied from glibc -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: make system() block SIGCHLD
On Wednesday 11 January 2012 12:37:31 Richard Braun wrote: > When built with an old thread implementation (or for a sparc target), > the implementation of the system() function doesn't conform to its > specification. Namely, it resets the SIGCHLD handler to its default > instead of blocking the signal, which may result in "lost" signals > if a custom handler was installed. Replace this by appropriate calls > to sigprocmask(). if you unify the error paths with goto's, do you get smaller code size ? -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity
On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote: > Test clean can be invoked with -j to exploits parallelism. why don't you use `make -j` then ? i don't think -j munging belongs in any Makefile here. > Verbosity mechanism aligned to main libc one. this is probably OK, but i feel like we should work on merging the two frameworks instead of expanding. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity
On Saturday 14 January 2012 19:31:16 Mike Frysinger wrote: > On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote: > > Test clean can be invoked with -j to exploits parallelism. > > why don't you use `make -j` then ? i don't think -j munging belongs in any > Makefile here. also, you might be interested in the commit i just pushed which brings `make clean` down from ~20 seconds to ~2 seconds. the underlying issue wasn't really lack of parallelism in the make system. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] ldso: use ELF_xxx()/ElfW() helpers
They expand into the same code, but using the ELF_xxx()/ElfW() macros
makes it much easier to spot similarities between code bases.
Signed-off-by: Mike Frysinger
---
ldso/ldso/arm/dl-startup.h|2 +-
ldso/ldso/arm/elfinterp.c | 28 ++--
ldso/ldso/avr32/dl-startup.h |4 +-
ldso/ldso/avr32/elfinterp.c | 28 ++--
ldso/ldso/bfin/dl-startup.h |2 +-
ldso/ldso/bfin/elfinterp.c|2 +-
ldso/ldso/c6x/dl-startup.h|2 +-
ldso/ldso/c6x/elfinterp.c | 22
ldso/ldso/cris/dl-startup.h |2 +-
ldso/ldso/cris/elfinterp.c| 30 +++---
ldso/ldso/frv/dl-startup.h|2 +-
ldso/ldso/frv/elfinterp.c | 32
ldso/ldso/i386/dl-startup.h |2 +-
ldso/ldso/i386/elfinterp.c| 28 ++--
ldso/ldso/m68k/dl-startup.h |2 +-
ldso/ldso/microblaze/dl-startup.h |2 +-
ldso/ldso/mips/elfinterp.c| 10 +++---
ldso/ldso/powerpc/dl-startup.h|4 +-
ldso/ldso/powerpc/elfinterp.c | 50 ++--
ldso/ldso/sh/dl-startup.h |2 +-
ldso/ldso/sh/elfinterp.c | 28 ++--
ldso/ldso/sh64/dl-startup.h |2 +-
ldso/ldso/sh64/dl-sysdep.h|2 +-
ldso/ldso/sh64/elfinterp.c| 30 +++---
ldso/ldso/xtensa/elfinterp.c | 48 +-
25 files changed, 183 insertions(+), 183 deletions(-)
diff --git a/ldso/ldso/arm/dl-startup.h b/ldso/ldso/arm/dl-startup.h
index 2dfdaff..f7d6052 100644
--- a/ldso/ldso/arm/dl-startup.h
+++ b/ldso/ldso/arm/dl-startup.h
@@ -141,7 +141,7 @@ static __always_inline
void PERFORM_BOOTSTRAP_RELOC(ELF_RELOC *rpnt, unsigned long *reloc_addr,
unsigned long symbol_addr, unsigned long load_addr, Elf32_Sym *symtab)
{
- switch (ELF32_R_TYPE(rpnt->r_info)) {
+ switch (ELF_R_TYPE(rpnt->r_info)) {
case R_ARM_NONE:
break;
case R_ARM_ABS32:
diff --git a/ldso/ldso/arm/elfinterp.c b/ldso/ldso/arm/elfinterp.c
index cde055d..b6dfae2 100644
--- a/ldso/ldso/arm/elfinterp.c
+++ b/ldso/ldso/arm/elfinterp.c
@@ -47,7 +47,7 @@ unsigned long _dl_linux_resolver(struct elf_resolve *tpnt,
int reloc_entry)
ELF_RELOC *this_reloc;
char *strtab;
char *symname;
- Elf32_Sym *symtab;
+ ElfW(Sym) *symtab;
ELF_RELOC *rel_addr;
int symtab_index;
unsigned long new_addr;
@@ -57,9 +57,9 @@ unsigned long _dl_linux_resolver(struct elf_resolve *tpnt,
int reloc_entry)
rel_addr = (ELF_RELOC *) tpnt->dynamic_info[DT_JMPREL];
this_reloc = rel_addr + reloc_entry;
- symtab_index = ELF32_R_SYM(this_reloc->r_info);
+ symtab_index = ELF_R_SYM(this_reloc->r_info);
- symtab = (Elf32_Sym *) tpnt->dynamic_info[DT_SYMTAB];
+ symtab = (ElfW(Sym) *) tpnt->dynamic_info[DT_SYMTAB];
strtab = (char *) tpnt->dynamic_info[DT_STRTAB];
symname = strtab + symtab[symtab_index].st_name;
@@ -102,12 +102,12 @@ static int
_dl_parse(struct elf_resolve *tpnt, struct r_scope_elem *scope,
unsigned long rel_addr, unsigned long rel_size,
int (*reloc_fnc) (struct elf_resolve *tpnt, struct r_scope_elem
*scope,
- ELF_RELOC *rpnt, Elf32_Sym *symtab, char *strtab))
+ ELF_RELOC *rpnt, ElfW(Sym) *symtab, char *strtab))
{
int i;
char *strtab;
int goof = 0;
- Elf32_Sym *symtab;
+ ElfW(Sym) *symtab;
ELF_RELOC *rpnt;
int symtab_index;
@@ -115,13 +115,13 @@ _dl_parse(struct elf_resolve *tpnt, struct r_scope_elem
*scope,
rpnt = (ELF_RELOC *) rel_addr;
rel_size = rel_size / sizeof(ELF_RELOC);
- symtab = (Elf32_Sym *) tpnt->dynamic_info[DT_SYMTAB];
+ symtab = (ElfW(Sym) *) tpnt->dynamic_info[DT_SYMTAB];
strtab = (char *) tpnt->dynamic_info[DT_STRTAB];
for (i = 0; i < rel_size; i++, rpnt++) {
int res;
- symtab_index = ELF32_R_SYM(rpnt->r_info);
+ symtab_index = ELF_R_SYM(rpnt->r_info);
debug_sym(symtab,strtab,symtab_index);
debug_reloc(symtab,strtab,rpnt);
@@ -137,7 +137,7 @@ _dl_parse(struct elf_resolve *tpnt, struct r_scope_elem
*scope,
if (unlikely(res <0))
{
- int reloc_type = ELF32_R_TYPE(rpnt->r_info);
+ int reloc_type = ELF_R_TYPE(rpnt->r_info);
#if defined (__SUPPORT_LD_DEBUG__)
_dl_dprintf(2, "can't handle reloc type %s\n ",
_dl_reltypes(reloc_type));
#else
@@ -182,7 +182,7 @@ fix_bad_pc24 (unsigned long *const reloc_addr, unsigned
long value)
static int
_dl_do_reloc (struct elf_resol
Re: [PATCH] libc: make system() block SIGCHLD
On Saturday 14 January 2012 07:39:11 Richard Braun wrote: > On Sat, Jan 14, 2012 at 06:33:55AM -0500, Mike Frysinger wrote: > > if you unify the error paths with goto's, do you get smaller code size ? > > Probably. I tried to follow the style of other code pieces I've read, > which is why I avoided using gotos in the first place. we prefer small wherever possible :) orig patch: 502 0 0 502 1f6 libc/stdlib/system.os goto version: 432 0 0 432 1b0 libc/stdlib/system.oS -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: make system() block SIGCHLD
On Saturday 14 January 2012 08:21:27 Richard Braun wrote: > On Sat, Jan 14, 2012 at 02:03:45PM +0100, Richard Braun wrote: > > + if (sigprocmask(SIG_SETMASK, &omask, NULL) != 0) > > + ret_val = -1; > > If you consider there is no need to check the return value of > sigprocmask() (which should only fail if parameters are invalid AIUI), > feel free to adjust that part. i am inclined in dropping these checks since there's no realistic way they could fail (where something else wasn't broken already). let's see if anyone else has an opinion ... before your patch (x86_64): 417 0 0 417 1a1 libc/stdlib/system.os current goto one: 432 0 0 432 1b0 libc/stdlib/system.os no error checking: 412 0 0 412 19c libc/stdlib/system.os not only did you fix standards compliance, but you managed to shrink it at the same time. good on you! -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity
On Sunday 15 January 2012 06:40:13 Bernhard Reutner-Fischer wrote:
> On Sat, Jan 14, 2012 at 07:33:50PM -0500, Mike Frysinger wrote:
> >On Saturday 14 January 2012 19:31:16 Mike Frysinger wrote:
> >> On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote:
> >> > Test clean can be invoked with -j to exploits parallelism.
> >>
> >> why don't you use `make -j` then ? i don't think -j munging belongs in
> >> any Makefile here.
> >
> >also, you might be interested in the commit i just pushed which brings
> >`make clean` down from ~20 seconds to ~2 seconds. the underlying issue
> >wasn't really lack of parallelism in the make system.
>
> The real issue is that clean-targets (and perhaps config targets, too)
> should not trip evaluation of {C,LD,CPP}FLAGS in the first place.
> i.e. something like
>
> ifneq ($(filter $(clean_targets),$(MAKECMDGOALS)),)
> OPTIMIZATION:=
> [whole flag fiddling block here]
> endif
true ... and now that much of the flag evaluation has been centralized, we can
do that in the core code :)
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] ldso: use ELF_xxx()/ElfW() helpers
On Sunday 15 January 2012 10:02:07 Rich Felker wrote: > On Sat, Jan 14, 2012 at 07:34:22PM -0500, Mike Frysinger wrote: > > They expand into the same code, but using the ELF_xxx()/ElfW() macros > > makes it much easier to spot similarities between code bases. > > It would of course be much simpler to use size_t, uint32_t, etc. as > appropriate. no it wouldn't. it would require people having to look up the backing types all the time in the spec which gets tedious (not to mention buggy) real fast. it also isn't possible when talking about things like Elf32_xxx structs (such as Elf32_Shdr or Elf32_Ehdr). > really ridiculous how much code is considered arch-specific in the > glibc and uclibc dynamic linkers. work is constantly on going to shrink them. if you're interested in helping, then post patches or *specific suggestions*, otherwise don't bother complaining since it really isn't helpful. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
[PATCH] buildsys: skip compiler flag checking for clean targets
As suggested by Bernhard, there is no point in evaluating the compiler's flag availability when cleaning, so skip things in that case. If there are variables that change targets based on the flags, then things are already broken and need fixing independently. Signed-off-by: Mike Frysinger --- Rules.mak |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Rules.mak b/Rules.mak index 2909d1b..032193e 100644 --- a/Rules.mak +++ b/Rules.mak @@ -176,11 +176,13 @@ check_ld=$(shell \ # Use variable indirection here so that we can have variable # names with fun chars in them like equal signs define check-tool-var +ifeq ($(filter clean CLEAN_%,$(MAKECMDGOALS)),) _v = $(2)_$(3) ifndef $$(_v) $$(_v) := $$(call $(1),$(subst %, ,$(3))) export $$(_v) endif +endif endef # Usage: check-gcc-var, -- 1.7.8.3 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: skip compiler flag checking for clean targets
On Sunday 15 January 2012 13:11:58 Mike Frysinger wrote: > As suggested by Bernhard, there is no point in evaluating the compiler's > flag availability when cleaning, so skip things in that case. If there > are variables that change targets based on the flags, then things are > already broken and need fixing independently. this improves my `make clean` time from ~2.4s to ~1.5s. i should be able shave some more off that by fixing up the include_clean target. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] buildsys: skip compiler flag checking for clean targets
On Sunday 15 January 2012 13:23:54 Mike Frysinger wrote: > On Sunday 15 January 2012 13:11:58 Mike Frysinger wrote: > > As suggested by Bernhard, there is no point in evaluating the compiler's > > flag availability when cleaning, so skip things in that case. If there > > are variables that change targets based on the flags, then things are > > already broken and need fixing independently. > > this improves my `make clean` time from ~2.4s to ~1.5s. i should be able > shave some more off that by fixing up the include_clean target. ok, that's been committed. the biggest slowdown now is just the recursive makes (mostly in test/). -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: make system() block SIGCHLD
On Sunday 15 January 2012 14:36:55 Richard Braun wrote: > On Sun, Jan 15, 2012 at 10:04:58AM -0500, Rich Felker wrote: > > Your report is wrong. system is REQUIRED by POSIX to change the signal > > disposition for SIGCHLD, not just to block the signal. It should > > change it to SIG_IGN, not SIG_DFL, but for practical purposes these > > are the same or similar. > > I didn't notice that anywhere. Could you indicate where this behaviour > is specified exactly ? http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html The system() function shall ignore the SIGINT and SIGQUIT signals, and shall block the SIGCHLD signal, while waiting for the command to terminate > > The code you sent the patch for is buggy, > > however, since it uses signal() rather than sigaction() and thus > > cannot correctly restore the signal disposition if it was installed > > with sigaction(). > > I agree the use of signal() immediately disturbed me, but I didn't read > its implementation. Maybe it does the job. In any case, we could use the > occasion to fix that as well and replace signal() with sigaction() in > the same patch. Rich is referring to the extended aspects of signal handling that sigaction() enables over signal() such as sa_sigaction and sa_flags. signal() will save/restore the handler just fine, but otherwise this function does subtly break a few things ... if you're up for fixing the code beyond what you've already done, that'd be cool :) -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH] libc: make system() block SIGCHLD
On Sunday 15 January 2012 14:50:24 Richard Braun wrote: > On Sun, Jan 15, 2012 at 08:36:55PM +0100, Richard Braun wrote: > > I agree the use of signal() immediately disturbed me, but I didn't read > > its implementation. Maybe it does the job. In any case, we could use the > > occasion to fix that as well and replace signal() with sigaction() in > > the same patch. > > In addition, I wonder if the code in the parent immediately following > vfork(), which forces SIGINT and SIGQUIT to SIG_IGN once more, is really > useful. AIUI, this system call should have no effect on the parent > signal dispositions. i think we can go ahead and rely on the real world at this point and say that the vfork() call did not screw with our signal() setup. i.e. go ahead and delete those two lines. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
