| Age | Commit message (Collapse) | Author |
|---|
|
call, and dont bother with 64bit versions on 64bit hosts as the regular one works fine (should fix the setrlimit ltp tests)
|
|
|
|
|
|
|
|
specific header file to make porting/updates a lot easier
|
|
on big endian mips the code is compiled as little-endian and the wrong half of
the 64-bit point value is examined to check for NaN, etc. This bug also broke
fpclassify(), isfinite(), isnormal(), isinf(), finite(), and signbit().
|
|
|
|
variable holding the register value
|
|
make sure we are only included by setjmp.h and pthread.h, and fix casting of address/jumpbugf in _JMPBUF_UNWINDS
|
|
|
|
|
|
|
|
'include/atomic.h' to add in new atomic operations for use by NPTL. There are multiple files for PowerPC and Sparc for 'atomic.h'. I will let those architecture maintainers choose the correct file. The files come from glibc in 'sysdeps/ARCH/bits'.
|
|
The old sh system call interface used 0x00 - 0x0f for the trapa value
(number of arguments), whereas the new ABI uses the 0x10 - 0x1f range.
For some reason we were using an off-by-1 trapa immediate which ended up
trashing r1 in the _syscall6() case, so we fix it up..
|
|
|
|
size and performance penalty to profiling applications this way, as well as
Heisenberg effects, where the act of measuring changes what is measured.
There are better tools for doing profiling, such as OProfile, that do not
require gcc to instrument the application code.
-Erik
|
|
|
|
'__kernel_old_dev_t'. And of course there is no good way to know
which is in use except checking linux/version.h. Grumble.
This is rather lame, but for now, define __kernel_old_dev_t to be
the same as __kernel_dev_t. This will want to be revisited soon.
-Erik
|
|
on i386, at least, so seems like a good thing.
|
|
fix a couple of gcc 3.3 compiler warnings in gmon.c
|
|
for gmon profiling support for the SuperH target.
|
|
|
|
type of 'struct stat' and 'struct stat64' so they use consistant types.
This change is the result of a bug I found while trying to use GNU tar. The
problem was caused by our using kernel types within struct stat and trying to
directly compare these values with standard types. Trying an 'if (a < b)' when
'a' is an 'unsigned long' and 'b' is an 'int' leads to very different results
then when comparing entities of the same type (i.e. time_t values)....
Grumble. Nasty stuff, but I'm glad I got this out of the way now.
As a result of this fix, uClibc 0.9.17 will not be binary compatible with
earlier releases. I have always warned people this can and will happen.
-Erik
|
|
|
|
|
|
Definitions taken from 2.4 kernel sources for each of the platforms.
|
|
guard names used by the kernel's asm/posix_types.h to eliminate
gratuitous conflicts and let our file win over the very-likely-
to-be-broken kernel header file.
-Erik
|
|
__USE_FILE_OFFSET64 handling.
-Erik
|
|
header, which is not directly usable for many architectures.
-Erik
|
|
specific bits/kernel_stat.h file.
-Erik
|
|
|
|
Edie C. Dost has some concerns about the perl script used to general crti.o and
crtn.o and added their own versions. These versions will win since they are
built last,
|
|
Prepare to kill the UNIFIED_SYSCALL option and instead have it be
a per arch thing that is either enabled or not for that arch.
-Erik
|
|
and to better support each arch. This is a really big patch...
-Erik
|
|
-Erik
|
|
(at least in theory) of working.
-Erik
|
|
and creating several *64 problems, particualrly when client apps
used -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64. All better now.
-Erik
|
|
* reduce the sigset types to 32 bits (I've mentioned this before)
I think I saw this change go in for another platform anyway ;-)
* Do not use _IO_FILE as it clashes with the C++ libraries which know
too much about how glibc workds :-(
* Do not use _G_va_list for the same reason.
* remove the CTORS/DTORS from crt0.S for ARM as the compiler provided
crtbegin.o and crtend.o have these (and only these) already in them and
you get multiple defined errs :-(
|
|
it and that I could see needed it.
Should be pretty low impact as these are only defined when using C++.
|
|
|
|
|
|
|
|
so there is no reason to allocate 4k. Change working of execvep.c
per patch from Matthias Kilian <kili@outback.escape.de> so that there
is not a fixed 127 byte buffer. Too easy to overflow...
-Erik
|
|
|
|
and Personal Systems. Thanks!
-Erik
|
