| Age | Commit message (Collapse) | Author |
|---|
|
|
|
disable strict-aliasing until someone gets the balls to clean this stuff up
|
|
|
|
|
|
__USE_FILE_OFFSET64 is defined. This was the case for all
architectures except those that use packed structures by default
(i.e., CRIS).
|
|
I have successfully made gethostbyname_r(), res_init(), and gethostid() fully
reentrant. In addition, I have added a NULL check to inet_aton(). This is
where SEG FAULTs were coming from when gethostbyname_r() was called.
|
|
|
|
|
|
Hi Erik,
Thanks for all your great work. I found a set of bugs in
resolv.c . Basically, there is code that looks like:
BIGLOCK;
__nameserversXX=__nameservers;
__nameserverXX=__nameserver;
BIGUNLOCK;
i = __dns_lookup(dname, type, __nameserversXX, __nameserverXX, &packet, &a);
which is a problem because the declarations are
int __nameservers;
char * __nameserver[MAX_SERVERS];
int __searchdomains;
char * __searchdomain[MAX_SEARCH];
so you can see that __nameserver is a pointer. Copying the
pointer to __nameserverXX doesn't protect the global variable
space. I have attached a patch and the new file. I hope you
will incorporate these bug fixes. I spent quite a bit of time
tracking them down.
Many thanks,
Ron
|
|
gethostbyname2_r tries to resolve an ipv6 address from /etc/hosts using
get_hosts_byname_r, but with AF_INET instead of the supplied address family.
This returns ipv4 addresses marked as ipv6 ones. Fix from nbd.
|
|
identical cc1 input for LFS enabled (compared to before r17652) but makes sure that we pickup the non-LFS if LFS is turned off (like r17652 did in this case).
|
|
Sounds like a typo, really
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
screw us up
|
|
The patch below tweaks the ARM nommu startup code so that doubleword stack
alignment is preserved. This is required on EABI targets.
|
|
__kernel_uid_t and __kernel_gid_t types to match actual kernel types
|
|
argument to utimes () if the second argument to utime () is NULL as the kernel will take care of getting/setting current time
|
|
|
|
is not defined.
|
|
|
|
|
|
|
|
|
|
This should fix it.
|
|
crt1.S so that __uClibc_main is called properly
|
|
Leave the now obsolete libc/misc/pthread dir in for now.
|
|
|
|
|
|
After our last update a new compilation breakage appeared when compiling
gcc:
/home/aurel/geex/geexbox/build.i386/toolchain/i386-pc-linux-uclibc/sysroot/usr/include/bits/uClibc_stdio.h:346: error: expected initializer before 'attribute_hidden'
Some investigations revealed that the following changeset is responsible
for this breakage:
http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/libc/sysdeps/linux/common/bits/uClibc_stdio.h?rev=16801&r1=16793&r2=16801&diff_format=h
Reverting just one hunk of this changeset fixed the problem us.
I'm not sure this is the right fix, but please see attached patch.
Look good to me.
|
|
config option --enable-secureplt. The assembler must also
supports R_PPC_REL16* relocations. gcc 4.1.1 and binutils 2.17
is known to do this.
|
|
svn on the nios2 platform, and updates the crt1/n/i.S files to get CTOR/DTOR-support to work.
|
|
Fixes undefined references to __fputc_unlocked when calling fputc().
|
|
When building an arm-uclinux toolchain withthreading disabled I get:
libc/stdio/getchar.c:26: error: 'getchar' aliased to undefined
symbol 'getchar_unlocked'
It looks like it's missing libc_hidden_def(getchar_unlocked). Patch below
fixes this.
|
|
|
|
fix compilation if PUTC_MACRO and/or GETC_MACRO is turned off
|
|
|
|
|
|
|
|
|
|
does not easily lend itself to becoming complete pthread cancelation
safe without first investing in some deep and serious thought...
The other malloc implementations are pthread cancelation safe, and
this one is mostly used for uClinux, where the lack is at least less
likely to be a common problem.
|
|
|
