| Age | Commit message (Collapse) | Author |
|---|
|
gcc version checking in every pt-machine.h header ... while __extern_always_inline should work fine, i think what is intended is __extern_inline ... should double check later
|
|
|
|
|
|
(selectable by #defining SYSLOG_NAMES_CONST)
|
|
|
|
|
|
|
|
However, retesting on m68k showed up a problem that had appeared in
uClibc since the last time I tried. Specifically, revision 15785 did:
-#define HEAP_GRANULARITY (sizeof (HEAP_GRANULARITY_TYPE))
+#define HEAP_GRANULARITY (__alignof__ (HEAP_GRANULARITY_TYPE))
-#define MALLOC_ALIGNMENT (sizeof (double))
+#define MALLOC_ALIGNMENT (__alignof__ (double))
The problem is that
(a) MALLOC_HEADER_SIZE == MALLOC_ALIGNMENT
(b) the header contains a size value of type size_t
(c) sizeof (size_t) is 4 on m68k, but...
(d) __alignof__ (double) is only 2 (the largest alignment used on m68k)
So we only allocate 2 bytes for the 4-byte header, and the least
significant 2 bytes of the size are in the user's area rather than
the header. The patch below fixes that problem by redefining
MALLOC_HEADER_SIZE to:
MAX (MALLOC_ALIGNMENT, sizeof (size_t))
(but without the help of the MAX macro ;)). However, we really would
like to have word alignment on Coldfire. It makes a big performance
difference, and because we have to allocate a 4-byte header anyway,
what wastage there is will be confined to the end of the allocated block.
Any wastage will also be limited to 2 bytes per allocation compared to
the current alignment.
I've therefore used the __aligned__ type attribute to create a double
type that has at least sizeof (size_t) bytes of alignment. I've
introduced a new __attribute_aligned__ macro for this. It might seem
silly protecting against old or non-GNU compilers here, but the extra
alignment is only an optimisation, and having the macro is more in the
spirit of the other attribute code.
|
|
Only affects gcc <2.7 or non-gcc compilers that bailed earlier due to missing int64_t
|
|
applications stop using _syscall#() and use syscall() instead. Cleanup
internal handling of syscall includes to use the correct header file.
|
|
are NOT suitable for user-space. The libc ones are the ones that
application code must use. If a problem is found with the libc
ones, then the libc syscall macros should be fixed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
consider versioned stat/mknod in uClibc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sys/syscall.h uses the IS_IN_libc define before including any header that
includes libc-internal.h (where IS_IN_libc is defined). This patch makes
sys/syscall.h include features.h to get the IS_IN_libc define where
appropriate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
prototypes for functions disabled on mmu-less systems.
|
|
|
|
this one. MIPS is the only one defining SHMLBA differently.
|
|
Here is a small patch to add epoll support to uclibc.
The only thing I am not sure about is what needs to be done (if anything)
to make it work on 2.4/2.2 kernels (are the syscall numbers defined but
give errors when called or not?).
Tested on 2.6, though some other issues prevent more extensive testing at
the minute.
Mike Frysinger:
cleaned up patch and added checks to make sure that the syscall actually
exists, returning ENOSYS in cases where it doesn't.
|
|
using uClibc. mincore() and the ones for Extended Attributes setxattr(), lsetxattr(), fsetxattr(), getxattr(), lgetxattr(), fgetxattr(), listxattr(), llistxattr(), flistxattr(), removexattr(), lremovexattr(), fremovexattr() which are optional.
|
|
adding cruft to include/sys/time.h. But also, there's no sense in
making changes like this until we decide how we're going to approach
the hidden symbol transition.
|
|
Hello!
Would the attached patch be acceptable (maybe instead of
__libc_gettimeofday using __gettimeofday)
We have some issues, see
http://bugs.gentoo.org/show_bug.cgi?id=65892
|
|
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
|
|
|
|
|
|
|
|
|
