| Age | Commit message (Collapse) | Author |
|---|
|
Moved guard_setup to __uClibc_main.c, the only place where it is called.
Removed SIGKILL option, not usable with sigaction.
|
|
|
|
option to enable REENTRANT RPC
|
|
|
|
mainly to cut down on noise in the NIST/PCTS tests since older POSIX
behavior was to fclose() (and hence fflush()) all open streams.
|
|
|
|
|
|
look right
|
|
be able to run apps built with 0.9.27. This also renames
__uClibc_start_main to __uClibc_main.
This compat option should be removed some time after 0.9.28 is released.
Let me know if you don't like this change.
|
|
|
|
|
|
|
|
placing the NPTL code under the top-level 'libpthread' directory.
Nothing compiles or even works at this point, so do not enable this
option.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sometimes it is desirable to build ldconfig non-static.
|
|
for propolice/ssp
|
|
|
|
Add pie support for mips
|
|
Add UCLIBC_BUILD_NOEXECSTACK support.
|
|
Seperate out security features into a separate menu
|
|
rename UCLIBC_PROPOLICE to UCLIBC_HAS_SSP
|
|
rename UCLIBC_PIE_SUPPORT to UCLIBC_BUILD_PIE
|
|
|
|
|
|
using uClibc. mincore() and the ones for Extended Attributes setxattr(), lsetxattr(), fsetxattr(), getxattr(), lgetxattr(), fgetxattr(), listxattr(), llistxattr(), flistxattr(), removexattr(), lremovexattr(), fremovexattr() which are optional.
|
|
dl-cache.h and make use of it. Also disables the lib-path-redundancy check
for the case the cache is not used. Makes use of _PRELOAD_FILE_SUPPORT.
From Peter Mazinger.
|
|
|
|
After the addition of a configuration option for
enabling the support of /etc/ld.so.cache, I thought
it might be a good idea to add one for the support
of the /etc/ld.so.preload file too. So here it is.
While doing this, I also noticed that the dynamic
linker would hang indefinitely if either LD_PRELOAD
or /etc/ld.so.preload contained a library which was
already loaded, so I made a patch for that too.
And of course, I could not resist from doing a little
clean up of comments and indentation, so here is a
patch for that too.
|
|
Mazinger implements the changes suggested by me on the uclibc list.
On Tuesday 28 September 2004 02:24 pm, Erik Andersen wrote:
> What I think should be done is
>
> *) Someone that cares about USE_CACHE should fix that option
> up to be sure it works, and give it a proper config entry
> in extra/Configs/Config.in, and rename it to something
> more appropriate such as LDSO_CACHE_SUPPORT.
>
> *) When LDSO_CACHE_SUPPORT=n, UCLIBC_RUNTIME_PREFIX /usr/X11R6/lib
> should be included in the default library search path in
> dl-elf.c, ldd, and ldconfig.
>
> *) When LDSO_CACHE_SUPPORT=y, UCLIBC_RUNTIME_PREFIX /usr/X11R6/lib
> should be excluded from the default library search path in
> dl-elf.c, ldd, and ldconfig, and those wishing to include
> X11 stuff should add that into /etc/ld.so.conf and re-run
> ldconfig.
>
> *) At present, LDSO_CONF and LDSO_CACHE use the same names
> and same structure as glibc. This precludes
> LDSO_CACHE_SUPPORT being uses in any sane fashion on a
> dial glibc and uClibc system. Just as it was necessary
> for use to use a different name for 'libuClibc' rather
> than 'libc', and 'ld-uClibc.so.0' rather than
> 'ld-linux.so.2' it seems that these configuration files
> really ought to be given different names.
>
|
|
be used by the unsuspecting masses quite yet.
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
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
|
|
256 is fine of course, but many applications use this value
and expect it to be larger.
|
|
|
