| Age | Commit message (Collapse) | Author |
|---|
|
Make sure we use the new jmpbuf-*.h headers
While there, adapt the offset on microblaze and the _JMPBUF_UNWINDS macro on bfin,
it seems, these were changed in the meantime.
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
|
|
Most ports have the same exact mman bit defines, so let's unify things
like the linux kernel has with the asm-generic efforts.
A few ports are left behind as they are non-trivial to merge -- the arch
maintainers can tackle it if they care.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Drop the "#ifndef O_CLOEXEC" cruft, enable O_CLOEXEC in most fcntl.h
headers, and import __ASSUME_O_CLOEXEC from glibc.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Fill out the stat structure so that the nanosecond resolution support is
always available. There is a small code size increase for a few ports
(three additional assignments in xstatconv), but otherwise everything
should remain the same.
While we're here, punt __old_kernel_stat from the few headers that still
define it as it is unused in uClibc and causes compile errors after these
nanosecond changes.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Make sure each arch has the same complete list to make comparing between
them easier.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
Tested successfully on i386..
|
|
|
|
|
|
- synch F_LINUX_SPECIFIC_BASE related fcntls for all arches
|
|
a problem where the linker was trying to use the wrong symbol name for the
init function.
Define SYMBOL_PREFIX as _ in Rules.mak for h8300, bfin, i960,
microblaze, and v850. Add -D__UCLIBC_UNDERSCORES__ in CFLAGS for targets
which define SYMBOL_PREFIX as _. Remove defines and undefs from
uClibc_arch_features.h of each target.
Add $(SYMBOL_PREFIX) to __uClibc_init when passed by ld option -init.
|
|
doing double negatives
|
|
|
|
applications stop using _syscall#() and use syscall() instead. Cleanup
internal handling of syscall includes to use the correct header file.
|
|
minor include file issues
|
|
the kernel's get_unmapped_area() behaviour. Ideally this should be more tightly
packed based off of the L1 dcache shape, once we're able to handle it through
the auxiliary vector.
|
|
|
|
|
|
|
|
|
|
specific header file to make porting/updates a lot easier
|
|
|
|
make sure we are only included by setjmp.h and pthread.h, and fix casting of address/jumpbugf in _JMPBUF_UNWINDS
|
|
'__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
|
|
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.
|
|
Here's a patch that implements the beginnings of a rudimentary sh64 port. So
far, this only works static, as I haven't done any of the ldso work yet. I've
also not touched the libpthread stuff yet either, so that's also disabled for
now.
This port was based off of some work that Sean McGoogan at SuperH did for his
initial port, but the this patch doesn't carry over too much from there
(basically the libc/sysdeps/linux/sh64/Makefile (or rather, parts of it),
the setjmp/longjmp stuff (which I had to rewrite portions of it to work with
the new toolchains), etc.).
However, for static, everything appears to work correcly, at least in a hello
world type application.
|
