From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2043 Path: news.gmane.org!not-for-mail From: Brian Wang Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl for ARM Date: Wed, 3 Oct 2012 00:18:59 +0800 Message-ID: References: <20121002134843.GV254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf3071cf9a34ab5104cb15e116 X-Trace: ger.gmane.org 1349194761 32301 80.91.229.3 (2 Oct 2012 16:19:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Oct 2012 16:19:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2044-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 02 18:19:26 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TJ5Bl-00028T-M7 for gllmg-musl@plane.gmane.org; Tue, 02 Oct 2012 18:19:17 +0200 Original-Received: (qmail 9885 invoked by uid 550); 2 Oct 2012 16:19:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9877 invoked from network); 2 Oct 2012 16:19:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GlWyhK6wCFUj9K3H0x2YURXgNGXBPemnlTis7Rtq19s=; b=GrpWe+QWgivm4xSezx7+5NPInsi3f1ZmzNCcMPKN1rmBXt0pN3eEDXOqhw+VPHa/xh Xm1gw8IXuHHN6DvX/OyUzre/bGLH1eKB5KcJ0YAUUllzu8INnCX3RQep8hhSqU11tnfM NXOGmwWy+F5zK7RqgOGxdFBnU09B8i/HIRvhVKkRZQaWSRUpsN6o3LTXJHNtBtQSk4f0 wFsz0J2I2Wm2b98BXwjIEQpub8tUwYnlsOJWMT10sX2ccMkqV1HTOMgkkNY3nXlAIHve kDHa8oMeo9ev4EA+Bbb4jjyT9XxWHtndZ4DL4EM+beE0lwJT4CINgQhroQYZmoxutdOI hQpg== In-Reply-To: <20121002134843.GV254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2043 Archived-At: --20cf3071cf9a34ab5104cb15e116 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Oct 2, 2012 9:57 PM, "Rich Felker" wrote: > > On Tue, Oct 02, 2012 at 03:27:28PM +0800, Brian Wang wrote: > > Hello all, > > > > I am currently thinking of switching to musl from glibc for my target > > after some readings on musl. > > I would like some advice from musl experts: > > * Does it support gettext stuff? > > * Does it _boost_ the performance on a 400MHz arm926 device? Or it > > is just smaller? > > By _boost_, I mean if the user can actually feel the improvement > > in performance. > > In general, if an application's perceived performance varies heavily > depending on libc, the application is probably doing something wrong > or at least naive. I can think of some exceptions of course, but this > advice is just to say that libc is probably not a place to look for > significantly improving overall performance. If there are libc > bottlenecks, you could probably get a lot more performance out of > changing the application. > > The main exceptions I can think of are places where libc has the wrong > big-O: for example, O(n=C2=B2) qsort or O(nm) strstr, or backtracking > regex implementations, can make completely-sane programs run extremely > slow on a bad libc. Note that musl and glibc are almost always > equivalent in this area; uclibc and dietlibc and perhaps others have > some problems here. > > One area you can get vastly better performance with musl is > application startup overhead. Especially with static linking, but even > with dynamic linking if your only .so is libc, the startup time is > 2-5x faster than glibc, which really makes a difference to the runtime > of shell scripts (like configure) that invoke tons of external > programs. ok. that makes sense. the faster application startup time is one of the performance figure that i'm looking for. the applications on my device generally run quite smoothly once the are up thanks to the efl devrlopers :-) > > > I did try the musl cross project and successfully built a musl-based > > arm linux toolchain. > > My kernel (2.6.24) was built successfully (not tried it on my device yet). > > However, when building busybox, there are some header files clashes, > > resulting in conflicting types. > > An example of it: > > --------------------- > > In file included from > > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../= arm-linux-musleabi/include/linux/kd.h:3:0, > > from console-tools/kbd_mode.c:23: > > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../= arm-linux-musleabi/include/linux/types.h:12:26: > > error: conflicting types for =E2=80=98fd_set=E2=80=99 > > In file included from > > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../= arm-linux-musleabi/include/sys/time.h:9:0, > > from include/libbb.h:45, > > from console-tools/kbd_mode.c:22: > > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../= arm-linux-musleabi/include/sys/select.h:25:3: > > note: previous declaration of =E2=80=98fd_set=E2=80=99 was here > > --------------------- > > It looks like these kernel headers are not sanitized for compatibility > with userspace..? i built the musl toolchain with the musl cross project found on the musl community wiki. i did replace the 3.x kernel with my oldish 2.6.24. any pointers on how to sanitize kernel headers? i have not built toolchains myself since the days when prebuilt toolchains were readily available... thanks in advance. brian > > Rich --20cf3071cf9a34ab5104cb15e116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 2, 2012 9:57 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
>
> On Tue, Oct 02, 2012 at 03:27:28PM +0800, Brian Wang wrote:
> > Hello all,
> >
> > I am currently thinking of switching to musl from glibc for my ta= rget
> > after some readings on musl.
> > I would like some advice from musl experts:
> > =C2=A0 * Does it support gettext stuff?
> > =C2=A0 * Does it _boost_ the performance on a 400MHz arm926 devic= e? =C2=A0Or it
> > is just smaller?
> > =C2=A0 =C2=A0 By _boost_, I mean if the user can actually feel th= e improvement
> > in performance.
>
> In general, if an application's perceived performance varies heavi= ly
> depending on libc, the application is probably doing something wrong > or at least naive. I can think of some exceptions of course, but this<= br> > advice is just to say that libc is probably not a place to look for > significantly improving overall performance. If there are libc
> bottlenecks, you could probably get a lot more performance out of
> changing the application.
>
> The main exceptions I can think of are places where libc has the wrong=
> big-O: for example, O(n=C2=B2) qsort or O(nm) strstr, or backtracking<= br> > regex implementations, can make completely-sane programs run extremely=
> slow on a bad libc. Note that musl and glibc are almost always
> equivalent in this area; uclibc and dietlibc and perhaps others have > some problems here.
>
> One area you can get vastly better performance with musl is
> application startup overhead. Especially with static linking, but even=
> with dynamic linking if your only .so is libc, the startup time is
> 2-5x faster than glibc, which really makes a difference to the runtime=
> of shell scripts (like configure) that invoke tons of external
> programs.

ok.=C2=A0 that makes sense.=C2=A0 the faster application startup time is= one of the performance figure that i'm looking for.

the applications on my device generally run quite smoothly once the are = up thanks to the efl devrlopers :-)

>
> > I did try the musl cross project and successfully built a musl-ba= sed
> > arm linux toolchain.
> > My kernel (2.6.24) was built successfully (not tried it on my dev= ice yet).
> > However, when building busybox, there are some header files clash= es,
> > resulting in conflicting types.
> > An example of it:
> > ---------------------
> > In file included from
> > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/..= /../../../arm-linux-musleabi/include/linux/kd.h:3:0,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fro= m console-tools/kbd_mode.c:23:
> > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/..= /../../../arm-linux-musleabi/include/linux/types.h:12:26:
> > error: conflicting types for =E2=80=98fd_set=E2=80=99
> > In file included from
> > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/..= /../../../arm-linux-musleabi/include/sys/time.h:9:0,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fro= m include/libbb.h:45,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fro= m console-tools/kbd_mode.c:22:
> > /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/..= /../../../arm-linux-musleabi/include/sys/select.h:25:3:
> > note: previous declaration of =E2=80=98fd_set=E2=80=99 was here > > ---------------------
>
> It looks like these kernel headers are not sanitized for compatibility=
> with userspace..?

i built the musl toolchain with the musl cross project found on the musl= community wiki.=C2=A0 i did replace the 3.x kernel with my oldish 2.6.24.= =C2=A0 any pointers on how to sanitize kernel headers?=C2=A0 i have not bui= lt toolchains myself since the days when prebuilt toolchains were readily a= vailable...

thanks in advance.

brian

>
> Rich

--20cf3071cf9a34ab5104cb15e116--