| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds code to uClibc to support a new ABI designed for the
FR-V architecture, that enables text segments of executables and
shared libraries to be shared by multiple processes on an OS such as
uClinux, that can run on FR-V processors without an MMU.
Patches for binutils and GCC have just been posted in the
corresponding mailing lists. The binutils patch was approved,
but there's one additional patch pending review, that I posted
this week. An updated GCC patch will be posted to
gcc-patches@gcc.gnu.org as soon as I complete testing (I used a
known-good compiler to test the uClibc patch below).
Since the existing dynamic loader code didn't support independent
relocation of segments, it required changes that were somewhat
extensive. I've added a number of new machine-specific macros to try
to keep the platform and ABI-specific details outside the generic
code. I hope this is not a problem.
|
|
does, rather than depending on the kernel header files.
-Erik
|
|
stuff will see other than "delete".
|
|
|
|
items, we have to declare what endianness cpus are capable of supporting
and work using dependancies.
|
|
|
|
|
|
Hello Erik!
I have made some cosmetical changes to the files, removed the added
SCRT=-fPIC option from building the crt0.S file (but it is a requirement
to build them with -fPIC), and changed some comments. I have left the
ldso.c patch with PIE_SUPPORT ifdefs, but consider applying it w/o them
(see some earlier comment from PaX Team on this issue, as it is considered
a bug). To have it work correctly, you'll also need removing
COMPLETELY_PIC.
One thing is missing: PIE_SUPPORT should be usable only for i386 (for
now).
Also added the support for propolice protection (that works for me and
catches memcpy/strcpy attacks (but needs a special gcc version).
Thanks, Peter
|
|
|
|
Lea. It is about 2x faster than the old malloc-930716, and behave itself much
better -- it will properly release memory back to the system, and it uses a
combination of brk() for small allocations and mmap() for larger allocations.
-Erik
|
|
Here's the patch for the ldso bits for sh64. This is still in need of a bunch
of debugging, testing, etc. and is really only being submitted for general
completeness. This assumes that the previous patches I've submitted have
already been applied.
I plan on playing with this and buildroot some more later, as I'd definitely
like to see buildroot images for sh64.
|
|
This patch adds the libpthread backend bits for sh64. As noted previously,
we can't inline things like the testandset() in pt-machine.h as we need to
use a completely different ISA / CFLAGS in order for this to work.
As a result, this patch is somewhat of a RFC as well to see what people think
of the libpthread/linuxthreads/sysdeps Makefile approach, etc. The approach
I've taken currently has been to provide a sysdeps/Makefile with a note that
TARGET_ARCHs that want build rules can simply add themselves into the list of
matching architectures to add to the subdir rule for. This probably isn't
the cleanest solution, but it's quite transparent and works quite well.
|
|
256 is fine of course, but many applications use this value
and expect it to be larger.
|
|
Nothing overly interesting here, this renames Hitachi/Mitsubishi to Renesas
for the relevant platforms (in this case, h8, sh, and m32r). The same changes
have already been going on in gcc/binutils/gdb/glibc/etc.
|
|
|
|
currently supported)
|
|
|
|
are implemented in hardware or via kernel emulation doesn't matter to
the libc code.
|
|
|
|
Another little patch fix the configuration for the SH3 targets. The SH3 has
no FPU, but our ldso runs fine on a SH3 target. (I think the
ldso should also run on a SH2 target, so you might want to enable the ldso
for SH2 targets too. But I can't test it, since I have no such a system) :
|
|
Dear Erik,
We downloded uClibc lattest version from the CVS. Still there are some
minor problems with extra/Configs/Config.e1
You have actually set ARCH_HAS_C_SYMBOL_PREFIX to NO which is not
correct for our architecture. Please apply the patch that will fix the
problem.
Best Regards,
- George
P.S. Patch also removes some irritating comments we have added in the past.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
endian cris architecture.
|
|
|
|
on a per-arch basis, or left to the user to choose.
|
|
|
|
some defaults. So give it some empty defaults and let people
select their own options.
|
|
Hello!
The latest changes document ldd in RUNTIME_PREFIX/bin, but it is installed
in RUNTIME_PREFIX/usr/bin
Peter
|
|
|
|
90% of correct is simply not good enough. Some people will not be very happy
about the decision to kill the wrapper toolchain. Sorry, but a real toolchain
is the One True Way(tm).
-Erik
|
|
which should simplify enabling arbitrary architectures.
-Erik
|
|
|
|
Remove the ADD_LIBGCC_FUNCTIONS option and do things the right way.
Either we have a shared libgcc available, or the libgcc routines
aren't PIC and don't belong in the shared libc anyway.
|
|
The attached patch performs a clean up of
extra/gcc-uClibc/gcc-uClibc.c:
* Use NULL for pointers and '\0' for characters;
not the opposite...
* Fixed an (assumed) segv if --uclibc-cc was used.
* Skip the argument to -x so it isn't considered
to be a source file.
* Simplified the loop in xstrcat().
* A little white space clean up.
//Peter
|
|
prepend "__". Unfortunately, when we #undef things, we do not prepend the
"__". This results in collateral damage to unsuspecting applications as we
undefine random unrelated macros. Oops.
For example, when compiling xfree86, libGLcore.a defines MALLOC for its own usage.
But include/bits/uClibc_config.h then does an
#undef MALLOC
#define __MALLOC_930716__ 1
which inadvertantly trashes the define from libGLcore.... Ouch.
The autogenerated include/bits/uClibc_config.h should instead have
contained:
#undef __MALLOC__
#define __MALLOC_930716__ 1
This patch makes that happen.
|
|
|
|
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).
|
|
install.patch:
* Define $(INSTALL) as install in Rules.mak.
* Change all occurrences of install into $(INSTALL).
* Change all occurrences of mkdir -p into $(INSTALL) -d.
install -d is already used in a number of places so
this should not be an additional compatibility problem.
|
|
|
|
|
|
Hello,
Attached is a patch of some changes I made to the gcc wrapper to
get it to compile XFree CVS.
Basically it supports the use of '-' on the command line to read stdin
for gcc, as well as setting the file type back to none before adding the
last too .o files if the file type was set on the command line.
It is applied against uClibc-0.9.20
Regards,
nash
|
|
contributed by John Williams <jwilliams@itee.uq.edu.au>
|
|
The attached patch performs a clean up of
extra/gcc-uClibc/Makefile:
* Better dependencies to only rebuild what is necessary.
* Use $< and $@ where appropriate.
* Suppress warning messages from which about
commands that cannot be found.
//Peter
|
