<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
> Date: Tue, 4 Oct 2011 15:32:24 -0500<br><div>> From: rob@landley.net<br>> To: aboriginal@lists.landley.net; maillist-aboriginal@barfooze.de<br>> Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal)<br>> <br>> >>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only has a<br>> >>> C compiler (since musl doesnt support C++ yet)<br>> >>> the link time optimization newer gcc's (4.5+) support is quite nice as<br>> >>> it allows to strip off unneeded functions without putting each function<br>> >>> into an own object file.<br>> >> So you mean it's like the --function-sections and --gc-sections options<br>> >> I've been using since 2005?<br>> >><br>> > it's not the same, it seems lto can also abandon code inside functions<br>> > which is never invoked.<br>> <br>> Ok. Sounds like fun: better optimizer.<br><br>
gcc 4.6 is much more aggressive, it will for example automatically inline<br>
functions and then silently eliminate them based on use of local var addresses.<br>
oddly it silently removed the containing function also, and<br>
the structure reference and call to spinlock in the kernel.<br>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48623<br>
<br>> > fact is, the binaries are much smaller as with the dead code elimination<br>> > flags.<br>> > also in my tests stuff was partially 50% faster than with -O3 alone.<br>> > so it's actually a pretty neat feature.<br>> <br>> Sounds like you're compiling badly written code, but you work with what<br>> you've got...<br>> <br>> >>> gcc 3.4.6 builds fine with 128 mb and no swap at all...<br>> >>> also it is relatively slim (i have a statically built one here which<br>> >>> fits into a 6MB tarball...)<br>> >>> maybe it would be the best if someone would fork it and add the new<br>> >>> inline stuff...<br>> >>> that way it could still be used to build recent kernels.<br>> >> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen<br>> >> architectures, worked for me. What are you referring to?<br>> >><br>> > i was talking about gcc *3*.<br>> <br>> Ah, I missed that.<br>> <br>> There are arguments for supporting older toolchain versions, and<br>> arguments for supporting newer toolchain versions. Mostly I just want a<br>> working toolchain to bootstrap a target, and then you can natively build<br>> a new toolchain under that in things like lfs-bootstrap.hdc.<br>> <br>> > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB<br>> > RAM, a statical linked crosscompiler fits into a 6MB .xz file,<br>> > it's faster than gcc4, and has relatively good optimization, compared<br>> > to pcc or tcc.<br>> <br>> Compared to tcc Turbo C for DOS had relatively good optimization.<br><br>tcc the turbo C from dos or tcc the tiny c compiler which you appear<br>to be thinking of below (http://bellard.org/tcc).<br><br>> The interesting thing that newer gcc versions give you is support for<br>> more targets. For example, armv7 showed up in gcc 4.3, which is the big<br>> incentive to support the newer one. Support for the xylinx microblaze<br>> would also be nice, since qemu has that now. Alpha and m68k compilers<br>> that don't die so often with internal compiler errors while cross<br>> compiling stuff would also be cool, although I the native versions of<br>> those compilers might be more stable.<br>> <br>> > the build time on my 3ghz machine is 5 minutes compared to 45 minutes<br>> > for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone)<br>> > only thing missing is the gnu99 inline stuff. apart from that it<br>> > compiles 99% of the code out there.<br>> <br>> It is indeed cool. But if I recall it couldn't do simple dead code<br>> elimination on arm, meaning busybox had a build break trying to link<br>> code out of .c files it hadn't bothered to compile because it knew they<br>> wouldn't be used.<br>> <br>> >>> all other packages in sabotage linux build just fine with it.<br>> >>> since pcc is full of bugs and has nearly no optimization at all its not<br>> >>> gonna be a real option anytime soon...<br>> >>> and clang is in C++ itself...<br>> >> Yup. There are some people gluing sparse to llvm, but again: llvm is<br>> >> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo<br>> >> list a lot...<br>> >><br>> > never heard about tcg. i'll read up on that one.<br>> <br>> There's a README in qemu's tcg subdirectory. See also<br>> http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG<br>
<br>
Err, Rob this appears to be a archive on your machine...<br>http://landley.net/qemu/2008-01-29.html#Feb_1,_2008_-_TCG works<br>is tcg better?, tcc also by Bellard has i386,x86_64,arm,c67? architectures<br>I think, and so has code generators for the most common 3 cases.<br>or it just the remaining arches like ppc32,ppc64,sparc32,sparc64?,mips32,mips64<br>sh4 that is the concern. it also lacks gcc -Ml,d option for running the compiler<br>to find out what the code being compiled depends on, that was one of the things<br>linux kernel and busybox need gcc for :( that at least would not be too hard<br>to add but it seems sort of a waste to run the compiler to find out what files to<br>compile later...<br><br>> >>>>> on a sidenote, i really missed having a gdb around... wonder if its<br>> >>>>> possible to supply a binary in the future ?<br>> >>>> That's been on my todo list for a while, just hasn't been near the top.<br>> >>>> 6.6 was the last GPLv2 release, I can look into adding that to the<br>> >>>> cross compiler and the gdbserver binary to the static target binaries<br>> >>>> list...<br>> >>>><br>> >>> i guess a separate download such as strace would be even better.<br>> >> I'm working on it, but it's also a bit down my todo list...<br>> >><br>> >> Rob<br>> >><br>> ><br>> > i currently have an issue here with aboriginal:<br>> > a) fdisk -l says both (root and home) partitions don't have a valid<br>> > partition table. i wonder why?<br>> <br>> Because they don't. I created filesystem images and attached them to<br>> qemu virtual disks:<br>> <br>> /dev/hda - squashfs root filesystem (mounted on /)<br>> /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh)<br>> /dev/hdc - build control image (mounted on /mnt by native-build.sh)<br>> <br>> I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has<br>> its own block device, which can have a filesystem on it. (You can do<br>> this with real hardware too. Floppies were never partitioned. I have<br>> no idea why removable USB drives tend to be partitioned, I think it's<br>> windows brain damage.)<br>> <br>> Once upon a time I did create partitioned images:<br>> <br>> http://landley.net/code/mkhda.sh<br>> <br>> But it's extra work for no benefit, and it means you can't easily<br>> loopback mount them from the host.<br>> <br>> > b) after unpacking and configuring gmp-5.0.2, i have a symlink<br>> > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm"<br>> > the symlink target is a regular file, but the readlink syscall returns<br>> > ELOOP in errno.<br><br>
This symlink is not present before configure, the style of ../mpn/arm<br>
is slightly odd. I would expect ./arm/add_n.asm to be simpler,<br>
even the x86_64 version mpn/add_n.asm -> ../mpn/x86_64/aors_n.asm <br>
is strange, why a symlink to a arch file of a different name?...<br>
The going up and then down the mpn directory may be hitting some<br>
oddness, though local ref symlinks usually work just fine.<br>
The ELOOP indicating too many symlinks in path usually only occurs<br>
when a symlink loop is found...<br>
Was it being built as part of the Aboriginal scripts or was it being<br>
built by hand?<br>
It seems to be part of a arm build since it is symlinked there.<br>
<br>> If the readlink syscall was broken then ls -l wouldn't be able to<br>> display symlinks. What code is calling the readlink() syscall and<br>> getting confused? Did you run it under strace? (The static-build.hdc<br>> control image builds that, I put binaries up at<br>> http;//landley.net/aboriginal/downloads/binaries/extras you can just<br>> wget, chmod +x, and use if it helps. I can't link you to a specific one<br>> because I don't remember which target you're building for.)<br>> <br>> > that prevents GMP (prerequisite for gcc 4.5) from building.<br>> <br>> The lfs-bootstrap.hdc control image builds the gmp from Linux From<br>> Scratch 6.7 under 11 different targets. That's version 5.0.1 so<br>> possibly something changed between that and 5.0.2, but I don't<br>> understand how you're having a system call failure? (How do you know<br>> it's a system call failure? There's context you're not explaining...)<br>> <br>> > i can load the file into vi, both using the symlink and the link target.<br>> > musl's readdir is just a one liner around the kernel syscall.<br>> <br>> Use strace to see what arguments it's passing to the syscall.<br>> <br>> > i couldnt reproduce that behaviour with a manually created symlink<br>> > according to the above scheme.<br>> > but it is reproducible by untaring gmp again and restarting the build.<br>> > i suspect that's either a filesystem or kernel bug.<br>> <br>> So the symlink is created corrupted?<br>> <br>> What version are you using? (The 1.1 release is using the ext4 driver<br>> for both ext3 and ext2, and if you're untarring into /home under<br>> dev-environment.sh then it's using the /dev/hdb image which should be ext3.)<br>> <br>> The previous (1.0.3) release was using the separate ext2 and ext3<br>> drivers for the journaled and nonjournaled versions of the same<br>> filesystem, which was silly. I'm not using ext4 yet, but one unified<br>> driver for both of those is cool. Shame if it's buggy, but we can get<br>> it fixed if so...<br>> <br>> > any suggestions are welcome ;)<br>> <br>> More info, please.<br>> <br>> Rob<br>> _______________________________________________<br>> Aboriginal mailing list<br>> Aboriginal@lists.landley.net<br>> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net<br></div><br><br><div>> Date: Tue, 4 Oct 2011 15:32:24 -0500<br>> From: rob@landley.net<br>> To: aboriginal@lists.landley.net; maillist-aboriginal@barfooze.de<br>> Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal)<br>> <br>> >>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only has a<br>> >>> C compiler (since musl doesnt support C++ yet)<br>> >>> the link time optimization newer gcc's (4.5+) support is quite nice as<br>> >>> it allows to strip off unneeded functions without putting each function<br>> >>> into an own object file.<br>> >> So you mean it's like the --function-sections and --gc-sections options<br>> >> I've been using since 2005?<br>> >><br>> > it's not the same, it seems lto can also abandon code inside functions<br>> > which is never invoked.<br>> <br>> Ok. Sounds like fun: better optimizer.<br>> <br>> > fact is, the binaries are much smaller as with the dead code elimination<br>> > flags.<br>> > also in my tests stuff was partially 50% faster than with -O3 alone.<br>> > so it's actually a pretty neat feature.<br>> <br>> Sounds like you're compiling badly written code, but you work with what<br>> you've got...<br>> <br>> >>> gcc 3.4.6 builds fine with 128 mb and no swap at all...<br>> >>> also it is relatively slim (i have a statically built one here which<br>> >>> fits into a 6MB tarball...)<br>> >>> maybe it would be the best if someone would fork it and add the new<br>> >>> inline stuff...<br>> >>> that way it could still be used to build recent kernels.<br>> >> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen<br>> >> architectures, worked for me. What are you referring to?<br>> >><br>> > i was talking about gcc *3*.<br>> <br>> Ah, I missed that.<br>> <br>> There are arguments for supporting older toolchain versions, and<br>> arguments for supporting newer toolchain versions. Mostly I just want a<br>> working toolchain to bootstrap a target, and then you can natively build<br>> a new toolchain under that in things like lfs-bootstrap.hdc.<br>> <br>> > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB<br>> > RAM, a statical linked crosscompiler fits into a 6MB .xz file,<br>> > it's faster than gcc4, and has relatively good optimization, compared<br>> > to pcc or tcc.<br>> <br>> Compared to tcc Turbo C for DOS had relatively good optimization.<br>> <br>> The interesting thing that newer gcc versions give you is support for<br>> more targets. For example, armv7 showed up in gcc 4.3, which is the big<br>> incentive to support the newer one. Support for the xylinx microblaze<br>> would also be nice, since qemu has that now. Alpha and m68k compilers<br>> that don't die so often with internal compiler errors while cross<br>> compiling stuff would also be cool, although I the native versions of<br>> those compilers might be more stable.<br>> <br>> > the build time on my 3ghz machine is 5 minutes compared to 45 minutes<br>> > for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone)<br>> > only thing missing is the gnu99 inline stuff. apart from that it<br>> > compiles 99% of the code out there.<br>> <br>> It is indeed cool. But if I recall it couldn't do simple dead code<br>> elimination on arm, meaning busybox had a build break trying to link<br>> code out of .c files it hadn't bothered to compile because it knew they<br>> wouldn't be used.<br>> <br>> >>> all other packages in sabotage linux build just fine with it.<br>> >>> since pcc is full of bugs and has nearly no optimization at all its not<br>> >>> gonna be a real option anytime soon...<br>> >>> and clang is in C++ itself...<br>> >> Yup. There are some people gluing sparse to llvm, but again: llvm is<br>> >> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo<br>> >> list a lot...<br>> >><br>> > never heard about tcg. i'll read up on that one.<br>> <br>> There's a README in qemu's tcg subdirectory. See also<br>> http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG<br>> <br>> >>>>> on a sidenote, i really missed having a gdb around... wonder if its<br>> >>>>> possible to supply a binary in the future ?<br>> >>>> That's been on my todo list for a while, just hasn't been near the top.<br>> >>>> 6.6 was the last GPLv2 release, I can look into adding that to the<br>> >>>> cross compiler and the gdbserver binary to the static target binaries<br>> >>>> list...<br>> >>>><br>> >>> i guess a separate download such as strace would be even better.<br>> >> I'm working on it, but it's also a bit down my todo list...<br>> >><br>> >> Rob<br>> >><br>> ><br>> > i currently have an issue here with aboriginal:<br>> > a) fdisk -l says both (root and home) partitions don't have a valid<br>> > partition table. i wonder why?<br>> <br>> Because they don't. I created filesystem images and attached them to<br>> qemu virtual disks:<br>> <br>> /dev/hda - squashfs root filesystem (mounted on /)<br>> /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh)<br>> /dev/hdc - build control image (mounted on /mnt by native-build.sh)<br>> <br>> I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has<br>> its own block device, which can have a filesystem on it. (You can do<br>> this with real hardware too. Floppies were never partitioned. I have<br>> no idea why removable USB drives tend to be partitioned, I think it's<br>> windows brain damage.)<br>> <br>> Once upon a time I did create partitioned images:<br>> <br>> http://landley.net/code/mkhda.sh<br>> <br>> But it's extra work for no benefit, and it means you can't easily<br>> loopback mount them from the host.<br>> <br>> > b) after unpacking and configuring gmp-5.0.2, i have a symlink<br>> > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm"<br>> > the symlink target is a regular file, but the readlink syscall returns<br>> > ELOOP in errno.<br>> <br>> If the readlink syscall was broken then ls -l wouldn't be able to<br>> display symlinks. What code is calling the readlink() syscall and<br>> getting confused? Did you run it under strace? (The static-build.hdc<br>> control image builds that, I put binaries up at<br>> http;//landley.net/aboriginal/downloads/binaries/extras you can just<br>> wget, chmod +x, and use if it helps. I can't link you to a specific one<br>> because I don't remember which target you're building for.)<br>> <br>> > that prevents GMP (prerequisite for gcc 4.5) from building.<br>> <br>> The lfs-bootstrap.hdc control image builds the gmp from Linux From<br>> Scratch 6.7 under 11 different targets. That's version 5.0.1 so<br>> possibly something changed between that and 5.0.2, but I don't<br>> understand how you're having a system call failure? (How do you know<br>> it's a system call failure? There's context you're not explaining...)<br>> <br>> > i can load the file into vi, both using the symlink and the link target.<br>> > musl's readdir is just a one liner around the kernel syscall.<br>> <br>> Use strace to see what arguments it's passing to the syscall.<br>> <br>> > i couldnt reproduce that behaviour with a manually created symlink<br>> > according to the above scheme.<br>> > but it is reproducible by untaring gmp again and restarting the build.<br>> > i suspect that's either a filesystem or kernel bug.<br>> <br>> So the symlink is created corrupted?<br>> <br>> What version are you using? (The 1.1 release is using the ext4 driver<br>> for both ext3 and ext2, and if you're untarring into /home under<br>> dev-environment.sh then it's using the /dev/hdb image which should be ext3.)<br>> <br>> The previous (1.0.3) release was using the separate ext2 and ext3<br>> drivers for the journaled and nonjournaled versions of the same<br>> filesystem, which was silly. I'm not using ext4 yet, but one unified<br>> driver for both of those is cool. Shame if it's buggy, but we can get<br>> it fixed if so...<br>> <br>> > any suggestions are welcome ;)<br>> <br>> More info, please.<br>> <br>> Rob<br>> _______________________________________________<br>> Aboriginal mailing list<br>> Aboriginal@lists.landley.net<br>> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net<br></div> </div></body>
</html>