- 25 2月, 2014 1 次提交
-
-
由 Szabolcs Nagy 提交于
Userspace emulated floating-point (gcc -msoft-float) is not compatible with the default mips abi (assumes an FPU or in kernel emulation of it). Soft vs hard float abi should not be mixed, __mips_soft_float is checked in musl's configure script and there is no runtime check. The -sf subarch does not save/restore floating-point registers in setjmp/longjmp and only provides dummy fenv implementation.
-
- 24 2月, 2014 1 次提交
-
-
由 Bobby Bingham 提交于
-
- 23 2月, 2014 2 次提交
-
-
由 rofl0r 提交于
-
由 rofl0r 提交于
x32 is the internal arch name, but glibc uses x86_64-x32. there doesn't exist a specific triple for x32 in gcc and binutils. you're supposed to build your compiler for x86_64 and configure it with multilib support for "mx32". however it turns out that using a triple of x86_64-x32 makes gcc and binutils pick up the right arch (they detect it as x86_64) and allows us to have a unique triple for cross-compiler toolchains.
-
- 28 8月, 2013 2 次提交
-
-
由 Rich Felker 提交于
I originally added this warning option based on a misunderstanding of how it works. it does not warn whenever the destination of the cast has stricter alignment; it only warns in cases where misaligned dereference could lead to a fault. thus, it's essentially a no-op for i386, which had me wrongly believing the code was clean for this warning level. on other archs, numerous diagnostic messages are produced, and all of them are false-positives, so it's better just not to use it.
-
由 Rich Felker 提交于
this will be needed for upcoming commits to the string/mem functions to correct their unannounced use of aliasing violations for word-at-a-time search, fill, and copy operations.
-
- 21 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
one place where semicolon (non-portable) was still used in place of separate -e options (copied over from an old version of this code), and use of a literal slash in the bracket expression for the final command, despite slash being used as the delimiter for the s command.
-
- 17 8月, 2013 2 次提交
-
-
由 Rich Felker 提交于
proper shell quoting and pretty-printing (avoiding ugly gratuitous quoting and bad quoting style) is included.
-
由 Rich Felker 提交于
it turns out that __SOFTFP__ does not indicate the ABI in use but rather that fpu instructions are not to be used at all. this is specified in ARM's documentation so I'm unclear on how I previously got the wrong idea. unfortunately, this resulted in the 0.9.12 release producing a dynamic linker with the wrong name. fortunately, there do not yet seem to be any public toolchain builds using the wrong name. the __ARM_PCS_VFP macro does not seem to be official from ARM, and in fact it was missing from the very earliest gcc versions (around 4.5.x) that added -mfloat-abi=hard. it would be possible on such versions to perform some ugly linker-based tests instead in hopes that the linker will reject ABI-mismatching object files, if there is demand for supporting such versions. I would probably prefer to document which versions are broken and warn users to manually add -D__ARM_PCS_VFP if using such a version. there's definitely an argument to be made that the fenv macros should be exposed even in -mfloat-abi=softfp mode. for now, I have chosen not to expose them in this case, since the math library will not necessarily have the capability to raise exceptions (it depends on the CFLAGS used to compile it), and since exceptions are officially excluded from the ARM EABI, which the plain "arm" arch aims to follow.
-
- 11 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
the default subarch is the one whose full name is just the base arch name, with no suffixes. normally, either the asm in the default subarch is suitable for all subarch variants, or separate asm is mandatory for each variant. however, in the case of asm which is purely for optimization purposes, it's possible to have asm that only works (or only performs well) on the default subarch, and not any othe the other variants. thus, I have added a mechanism to give a name to the default variant, for example "armel" for the default, little-endian arm. further such default-subarch names can be added in the future as needed.
-
- 03 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
check in configure to be polite (failing early if we're going to fail) and in vfprintf.c since that is the point at which a mismatching type would be extremely dangerous.
-
- 02 8月, 2013 1 次提交
-
-
由 Rich Felker 提交于
-
- 25 7月, 2013 1 次提交
-
-
由 Rich Felker 提交于
it's not clear that -O3 helps them, and gcc seems to have floating point optimization bugs that introduce additional failures when -O3 is used on some of these files.
-
- 23 7月, 2013 1 次提交
-
-
由 Rich Felker 提交于
the motivation for this patch is that the vast majority of libc is code that does not benefit at all from optimizations, but that certain components like string/memory operations can be major performance bottlenecks. at the same time, the old -falign-*=1 options are removed, since they were only beneficial for avoiding bloat when global -O3 was used, and in that case, they may have prevented some of the performance gains. to be the most useful, this patch will need further tuning. in particular, research is needed to determine which components should be built with -O3 by default, and it may be desirable to remove the hard-coded -O3 and instead allow more customization of the optimization level used for selected modules.
-
- 19 7月, 2013 2 次提交
-
-
由 Rich Felker 提交于
an empty program is not valid and would be reasonable grounds for the compiler to give an error, which would break these tests.
-
由 Rich Felker 提交于
-
- 12 12月, 2012 1 次提交
-
-
由 Rich Felker 提交于
-
- 19 11月, 2012 1 次提交
-
-
由 Rich Felker 提交于
-
- 14 11月, 2012 1 次提交
-
-
由 rofl0r 提交于
-
- 09 11月, 2012 1 次提交
-
-
由 Rich Felker 提交于
previously, empty string was treated as "use default". this is apparently not compatible with standard configure semantics where an empty prefix puts everything under /. the new logic should be a lot cleaner and not suffer from such issues.
-
- 27 10月, 2012 2 次提交
-
-
由 Rich Felker 提交于
-lpcc only works if -nostdlib is not passed, so it's useless. instead, use -print-file-name to look up the full pathname for libpcc.a, and check whether that succeeds before trying to link with the result. also, silence pcc's junk printed on stdout during tests.
-
由 Rich Felker 提交于
in old versions of pcc, the directory containing libpcc.a was not in the library path, and other options like -print-file-name may have been needed to locate it. however, -print-file-name itself seems to have been added around the same time that the directory was added to the search path, and moreover, I see no evidence that older versions of pcc are capable of building a working musl shared library. thus, it seems reasonable to just test whether -lpcc is accepted.
-
- 26 10月, 2012 1 次提交
-
-
由 Rich Felker 提交于
pcc wrongly passes any option beginning with -m to the linker, and will break at link time if these options were added to CFLAGS. testing linking lets us catch this at configure time and skip them.
-
- 19 10月, 2012 1 次提交
-
-
由 Rich Felker 提交于
this is necessary to allow $CC with arguments in it
-
- 03 10月, 2012 1 次提交
-
-
由 Rich Felker 提交于
for some reason this option is undocumented. not sure when it was added, so I'm using a configure test. gcc was already setting the mark correctly for C files, but assembler source files would need ugly .note boilerplate in every single file to achieve this without the option to the assembler. blame whoever thought it would be a good idea to make the stack executable by default rather than doing it the other way around...
-
- 29 9月, 2012 1 次提交
-
-
由 Rich Felker 提交于
based on initial work by rdp, with heavy modifications. some features including threads are untested because qemu app-level emulation seems to be broken and I do not have a proper system image for testing.
-
- 11 9月, 2012 1 次提交
-
-
由 Rich Felker 提交于
this should both fix the issue with ARM needing -lgcc_eh (although that's really a bug in the libgcc build process that's causing considerable bloat, which should be fixed) and make it easier to build musl using clang/llvm in place of gcc. unfortunately I don't know a good way to detect and support pcc's -lpcc since it's not in pcc's default library search path...
-
- 29 8月, 2012 1 次提交
-
-
由 Rich Felker 提交于
if needed for debugging, it will be output in the .debug_frame section instead, where it is not part of the loaded program and where the strip command is free to strip it.
-
- 26 8月, 2012 1 次提交
-
-
由 Rich Felker 提交于
based on the patches contributed by boris brezillon.
-
- 15 8月, 2012 1 次提交
-
-
由 Rich Felker 提交于
-
- 06 8月, 2012 2 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
- 13 7月, 2012 1 次提交
-
-
由 Rich Felker 提交于
-
- 11 7月, 2012 1 次提交
-
-
由 Rich Felker 提交于
basically, this version of the code was obtained by starting with rdp's work from his ellcc source tree, adapting it to musl's build system and coding style, auditing the bits headers for discrepencies with kernel definitions or glibc/LSB ABI or large file issues, fixing up incompatibility with the old binutils from aboriginal linux, and adding some new special cases to deal with the oddities of sigaction and pipe syscall interfaces on mips. at present, minimal test programs work, but some interfaces are broken or missing. threaded programs probably will not link.
-
- 04 7月, 2012 1 次提交
-
-
由 Rich Felker 提交于
this option is expensive and only used on old gcc's that lack -fexcess-precision=standed, but it's not needed on non-i386 archs where floating point does not have excess precision anyway. if musl ever supports m68k, i think it will need to be special-cased too. i'm not aware of any other archs with excess precision.
-
- 07 6月, 2012 5 次提交
-
-
由 Rich Felker 提交于
this issue affects the last gpl2 version of binutils, which some people are still using out of aversion to gpl3. musl requires -Bsymbolic-functions because it's the only way to make a libc.so that's able to operate prior to dynamic linking but that still behaves correctly with respect to global vars that may be moved to the main program via copy relocations.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
it's possible that the user has provided a compiler that does not have any libc to link to, so linking a main program is a bad idea. instead, generate an empty shared library with no dependencies.
-
由 Rich Felker 提交于
in theory we could support stack protector in the libc itself, and users wanting to experiment with such usage could add -fstack-protector to CFLAGS intentionally. but to avoid breakage in the default case, override broken distro-patched gcc that forces stack protector on.
-
由 Rich Felker 提交于
some broken distro-provided toolchains have modified gcc to produce only "gnu hash" dynamic hash table by default. as this is unsupported by musl, that results in a non-working libc.so. we detect and switch this on in configure rather than hard-coding it in the Makefile because it's not supported by old binutils versions, but that might not even be relevant since old binutils versions already fail from -Bsymbolic-functions being missing. at some point I may review whether this should just go in the Makefile...
-