| Age | Commit message (Collapse) | Author |
|---|
|
Port the generic optimized string funcs from glibc, with some tweaks
to cut their size a little. The main change is making memmove
call memcpy for forward copying to trim redundant code.
Make use of both the generic and arch-specific speed-optimized string
funcs configurable. Arch-specific take precedence over generic,
and generic takes precedence over basic size-optimized uClibc funcs.
|
|
|
|
|
|
|
|
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
|
|
|
|
Hi Erik,
I'm not sure why the NIOS support is not in uClibc -- perhaps the patch
was rejected or never submitted? In any case, I'm playing with some NIOS
stuff and created this patch against 0.9.26. The work was done by
Microtronix. I'm not sure who else contributed to it. It would be great
to have the NIOS support available in uClibc so developers don't have to
go searching for these bits.
Pete
|
|
|
|
|
|
about the best settings the AMD Elan and the VIA Nehemiah.
|
|
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
|
|
contributed by John Williams <jwilliams@itee.uq.edu.au>
|
|
|
|
|
|
appears to be wrong with their toolchain that is tickled
by LFS.
|
|
|
|
|
