| Age | Commit message (Collapse) | Author |
|---|
|
see http://uclibc.org/lists/uclibc/2005-May/011667.html for details.
Not tested by me but I am sure Peter will :)
The toolchain needs to be rebuilt.
|
|
syscalls. This won't work on 2.2 kernels(I think).
|
|
To actually use it, one must define _DL_DO_FINI_IN_LIBC globally.
That will also break ABI for apps linked with previous version of crtX.S.
They must be relinked with this version to work again.
|
|
|
|
|
|
|
|
as the flags for all calls to 'as'
|
|
|
|
stack frame. This will make backtracing possible.
|
|
The attached patch generalizes the use of PIE (all archs are brought in
sync that use/mention it: x86/ppc/frv) and makes use of it building the
target utils.
Tested on x86, ppc should be tested, frv uses -fPIE at one location, but
at another place -fpie, I don't know which is correct (could be both) and
misses the target addition in Config.in.
The test for ppc (requires the earlier sent crt-correction patch to work
correctly):
enable UCLIBC_PIE_SUPPORT, build uClibc and utils, check:
file ./utils/ldd, it should show shared object (instead of executable)
|
|
|
|
Requested by Peter Mazinger. Testing wanted.
|
|
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
|
|
Some utilities, such as valgrind, have a legitimate reason to know the address
of the current brk. Since we know such utils will peek under our skirt, we
might as well give them what they expect and not use a gratuitously different
symbol name.
-Erik
|
|
have it. It is used by the boehm gc, amoung other things.
|
|
|
|
'__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
|
|
Here are some simple fixes for things that broke for PPC with
the recent syscall cleanup. I am not sure they are correct but
they seem pretty trivial.
|
|
-Erik
|
|
The macro to do some floating point checks in libc/sysdeps/linux/powerpc/setjmp.S is incorrect.
The following should fix it.
Same applies to uClibc/libc/sysdeps/linux/powerpc/__longjmp.S
Hope there aren't other files I've missed :)
|
|
The macro to do some floating point checks in libc/sysdeps/linux/powerpc/setjmp.S is incorrect.
The following should fix it.
|
|
being cleaned up.
|
|
used to generate the crti.S and crtn.S files. Since we don't use that
anymore, keeping the workaround makes no sense.
Furthermore, in most cases, SAFECFLAGS was not picking up all the
needed flags, causing crti.o and crtn.o to not be built PIC.
Which is very bad. Removing SAFECFLAGS and using CFLAGS fixes
that as well.
|
|
broke a couple of days ago. :-(
|
|
|
|
|
|
ln.patch:
* Define $(LN) as ln in Rules.mak.
* Change all occurrences of ln into $(LN).
* Change all constructs like (cd path && ln -sf foo/file file)
into $(LN) -sf foo/file path/file. The latter construct is
already used in a number of places so it should not be
an additional compatibility problem.
|
|
rm.patch:
* Define $(RM) as rm -f in Rules.mak and test/Rules.mak
(this is the same definition as gmake uses by default).
* Change all occurrences of rm and rm -f into $(RM).
|
|
Current uClibc contains only one fpu_control.h and it is i386 version.
This is a patch to use platform specific fpu_control.h. All new files
come from glibc 2.3.2. This patch is against 0.9.21 but also can be
applied to CVS as is.
|
|
|
|
on i386, at least, so seems like a good thing.
|
|
match the kernel type exactly.
|
|
common ipc.h header and struct definitions.
-Erik
|
|
one which now uses the kernel structs
-Erik
|
|
I've tried several times to compile uClibc with soft-float
(both gcc-3.2.2 toolchain and wrapper), but applications
compiled with uClibc always failed with "Invalid instruction".
So I ended up disabling floating point at all and this works well.
I also has no problem with glibc from Monta Vista, which is
compiled with soft-float. My processor is PowerPC 405GP.
Maybe the problem is in FP() macro definition in
libc/sysdeps/linux/powerpc/setjmp.S and
libc/sysdeps/linux/powerpc/__longjmp.S
#ifdef __UCLIBC_HAS_FLOATS__
#define FP(x...) x
#else
#define FP(x...)
#endif
which should be defined as
if defined __UCLIBC_HAS_FLOATS__ && ! defined __UCLIBC_HAS_SOFT_FLOAT__
#define FP(x...) x
#else
#define FP(x...)
#endif
|
|
it compiles properly with gcc 3.3.
-Erik
|
|
should instead have been testing for '#ifdef __PIC__'. This resulted in
NON-PIC code getting mixed into the shared library. Oops!!!
-Erik
|
|
|
|
broken. Use fork instead, per glibc behavior.
|
|
|
|
|
|
|
|
some other minor warnings.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
-Erik
|
