| Age | Commit message (Collapse) | Author |
|---|
|
match glibc's quotient truncation behavior.
|
|
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.
|
|
|
|
|
|
Requested by Peter Mazinger. Testing wanted.
|
|
- adjust licensing terms of sources for crt*.o
- change the stat ABI to speed it up, matching changes in the kernel
- assorted bug-fixes, improvements and updates in the FR-V port
etc.
|
|
this was sent earlier in a different form:
http://www.uclibc.org/lists/uclibc/2004-January/008136.html
find attached a smaller version ... perhaps adding a fprintf to stderr before
calling abort would be nice like in the glibc patch, but whatever
glibc has since adopted a similar fix for their malloc (third hunk, line 1970)
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c.diff?r1=1.121&r2=1.122&cvsroot=glibc&f=h
-mike
|
|
i sent this earlier but perhaps people missed it the first time around :)
http://www.uclibc.org/lists/uclibc/2004-August/009544.html
basically if you try to #include <sys/ucontext.h> on arm it'll fail because
ucontext.h utilizes typedefs found in bits/sigcontext.h ... i386 already has
this fix in uClibc
find attached a trivial patch to fix this
-mike
|
|
Below is a patch to make the pread and pwrite calls work on the SH
architecture. I've only tested this on the SH4 with a 2.4.24 kernel - a
fairly recent kernel is required as the problem is partially fixed in
the kernel itself. For more information (in relation to glibc, but the
problem is the same) see the thread at
http://sourceforge.net/mailarchive/message.php?msg_id=2375908
Someone should really test this on the SH2/3...
|
|
|
|
more sane than 'gcc -pg' and seems much easier to support.
-Erik
|
|
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
|
|
-Erik
|
|
I will always test before I commit.
I will always test before I commit.
-Erik
|
|
dtors via atexit(), atexit may need to call realloc with __pagesize
still set to 0. ugh.
-Erik
|
|
is not quite there...
|
|
_dl_pagesize variable in ldso, so avoid aliasing.
-Erik
|
|
checking on 127.0.0.1 is still valid w/o resolv.conf
-Erik
|
|
|
|
return the length and the actual dns packet as received, rather than
making stuff up.
-Erik
|
|
-Erik
|
|
the comment, newer kernels appended "64" to __NR_pread and __NR_pwrite.
|
|
instruction errors. Disable it for now.
|
|
> the gethostbyname_r() call itself is not segfaulting, but the memory
> returned in the h_aliases array seems to be wrong ...
was playing around with the source today and eventually the obvious answer hit
me ... while read_etc_hosts_r() generatings an array of strings fo h_aliases
and populates it, the dns path does not :)
find attached a patch that'll actually generate the h_aliases list in the
normal dns code path ... i used the etc_hosts_r() code as a template for some
of it ...
note that this is just a simple fix ... it fills the alias list with just the
hostname gethostbyname_r was passed ... the proper fix i think would be to
parse the dns packet down in __dns_lookup() and pass the info back via the
resolv_answer struct ...
but this fix is better than the current state of things ... that is, h_aliases
currently is never initailized in the dns code path :)
|
|
|
|
|
|
not the hard coded value of 4096.
|
|
|
|
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
|
|
others.
|
|
running on uClinux, which at runtime uses the FLAT file format.
|
|
are being used
|
|
-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
|
|
|
|
actually match reality. In particular, _SC_GETPW_R_SIZE_MAX and
_SC_GETGR_R_SIZE_MAX were causing us problems with programs such
as libglib, since they were always returning -1, which is a bit
smaller than the actual passwd and group max buffer sizes.
-Erik
|
|
instead, but we are not such a system and should not propagate such things.
|
|
Only use MAP_SHARED when mmu-less.
|
|
This is a patch for uClibc/libc/sysdeps/linux/mips/sys/procfs.h pulled
from glibc CVS.
This fixes gdb with threaded application (with glibc environment).
Although debugging threaded programs seems not working on uClibc/mips
yet, this patch will be required when it becomes working.
This patch can be applied to any version of uClibc (including current
CVS).
|
|
|
|
Rather than copy more code back into the bridge-utilities, how about applying this
change to uClibc? I hate when packages get cluttered for workarounds for other
incompatibilities.
The problem is that SIOCGIFCONF only lists interfaces that have IP addresses, so it
doesn't find the other interfaces that are being used for bridging. It could be fixed
in the kernel to return all interfaces, but then something else might break; and still
it mean a kernel update for the 2.4 users.
The whole use of ifindex in the bridge API is a bad idea. But we probably have to live
with it for compatibility.
Patch against uClibc 0.9.26
|
|
Strlen was counting the last 3 bytes incorrectly for big endian arm.
|
|
with s/i686.get_pc_thunk.bx/get_pc_thunk_bx/g to make gcc 3.4 happy.
|
|
|
|
the real thing.
|
|
|
|
|
