[PATCH][MIPS] Do not save variables in hi or lo across system calls
The kernel does not save these registers across system calls. GCC 4.4 has gotten more agressive about using them for temporary variables, so this shows up as intermittent crashes if you use a recent compiler. Signed-off-by: Daniel Jacobowitz d...@codesourcery.com diff --git a/libc/sysdeps/linux/mips/bits/syscalls.h b/libc/sysdeps/linux/mips/bits/syscalls.h index 3639913..28b0f91 100644 --- a/libc/sysdeps/linux/mips/bits/syscalls.h +++ b/libc/sysdeps/linux/mips/bits/syscalls.h @@ -261,7 +261,7 @@ }) #define __SYSCALL_CLOBBERS $1, $3, $8, $9, $10, $11, $12, $13, \ - $14, $15, $24, $25, memory + $14, $15, $24, $25, hi, lo, memory #else /* N32 || N64 */ @@ -318,7 +318,7 @@ }) #define __SYSCALL_CLOBBERS $1, $3, $10, $11, $12, $13, \ - $14, $15, $24, $25, memory + $14, $15, $24, $25, hi, lo, memory #endif -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc: include
On Tue, Jan 13, 2009 at 12:26:32PM +0100, Denys Vlasenko wrote: * We want users to be able to use -funsigned-char or -fsigned-char when they build their programs against uclibc, and still have their programs working correctly. So test them. The architecture defaults, in general, are the choice which is more efficient on each architecture. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: GCC's exception unwind info and uClibc
On Sat, Dec 27, 2008 at 08:43:09PM -0800, Michael Deutschmann wrote: On Sat, 27 Dec 2008, I wrote: So it looks like this case needs to be refined, not to reject uClibc, but to make sure the platform is indeed ELF, which is no longer implied by __GLIBC__. I looked a little more closely and it seems things are a bit wierd. The code in question is already wrapped within an #if defined(OBJECT_FORMAT_ELF) block. Are you sure that is the relevant check? ELF object files are used on arm-uclinux and m68k-uclinux; they're just translated into bFLT for executables. But it's the lack of ELF at runtime that causes a problem. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: svn commit: trunk/uClibc/libc/inet
On Fri, Jun 06, 2008 at 04:27:25PM +0200, Denys Vlasenko wrote:
Possibly. I tried
FILE * __open_etc_hosts(void) attribute_hidden { ...
- that didn't work at all. So I decided to just take advantage
of the fact that we already have extern decl with attribute_hidden
at the beginning of this file.
In hindsight, maybe it wants this?!
FILE * __open_etc_hosts attribute_hidden (void) { ...
No, I believe it's this:
attribute_hidden FILE * __open_etc_hosts (void) { ...
--
Daniel Jacobowitz
CodeSourcery
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: RFC: multilib support for uClibc
On Tue, Jan 22, 2008 at 01:37:35PM +0100, Bernd Schmidt wrote: For the Blackfin, we need to compile several versions of uClibc and install them in such a way that the cross compilers will find them. To do this, we've come up with the following patch (combined from multiple contributions by Jie Zhang, Mike Frysinger and myself). Essentially, this adds two additional path components to the install directories, $(SUFFIX) and $(MULTILIB), which correspond to gcc's sysroot suffix and multilib directory. For historical reasons, this patch adds MULTILIB as a uClibc config option, and leaves SUFFIX to be passed as an argument to make. I can either keep this or make both/neither config options. Any coments on this patch? Objections? Would anyone mind testing this on a system other than bfin? FWIW, we've been using a multilibbed uClibc for some time now; I do not believe we have any local uClibc patches for that purpose. All we do is adjust PREFIX when installing. We don't have any lib/$(MULTILIB) directories; it was much simpler to put each into its own sysroot and it works nicely at runtime too. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: RFC: multilib support for uClibc
On Wed, Jan 23, 2008 at 12:07:05AM +0100, Bernd Schmidt wrote: Daniel Jacobowitz wrote: We don't have any lib/$(MULTILIB) directories; it was much simpler to put each into its own sysroot and it works nicely at runtime too. Okay.. what kind of multilibs do you have, and what's your directory structure? All kinds, but organized with a flat SYSROOT_SUFFIX hierarchy inside the uclibc set. For instance: libc/usr libc/softfp/usr libc/uclibc/usr libc/uclibc/softfp/usr Then there's another few which are siblings to softfp. It doesn't have to be flat, either, as long as you use SYSROOT_SUFFIX to locate things. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 03:58:00PM +, Will Newton wrote: Agreed, my question is whether or not adding the underscore is the correct thing to do even if your architecture prepends an underscore to symbol names? Is there a particular reason why this was done for Blackfin, to make a particular app work? I am trying to find out what the correct behaviour of dlsym is, for example does it behave like this on other Unixes that have leading underscores on symbols. There are pretty much no Unixes that do this; a few embedded Linux ports are the only exceptions I've ever encountered. If you have underscores, dlsym had better know about it, or cross-platform code will break. Consider dlsym (libc_handle, printf); every caller should not need to know about _printf. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 04:17:02PM +, Will Newton wrote: On Jan 8, 2008 4:06 PM, Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 03:58:00PM +, Will Newton wrote: Agreed, my question is whether or not adding the underscore is the correct thing to do even if your architecture prepends an underscore to symbol names? Is there a particular reason why this was done for Blackfin, to make a particular app work? I am trying to find out what the correct behaviour of dlsym is, for example does it behave like this on other Unixes that have leading underscores on symbols. There are pretty much no Unixes that do this; a few embedded Linux ports are the only exceptions I've ever encountered. I think I got the impression from the Levine Linkers and Loaders book (my copy of which seems to have vanished) that prepending an underscore to symbol names was common practice. Perhaps it was an a.out thing, that's rather before my time though... Not on modern Unixes, anyway. Some *-elf targets do, and more *-coff and *-aout targets. As I understand it, the only reasons are habit and to accomodate an assembler syntax which makes symbol names ambiguous with something else (e.g. register names). If it's a habit, expect everyone to have the habit; if it's to accomodate the assembler, expect everyone to accomodate the assembler. So there shouldn't be any symbols without the underscore. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Prepending underscores to symbol names in dlsym() (commit 20613)
On Tue, Jan 08, 2008 at 11:54:29AM -0500, Mike Frysinger wrote: the Blackfin reason was backwards compatibility with existing propriety toolchains (and we didnt have input for those toolchains at their time of creation). at this point, we've screwed ourselves into an ABI corner, so there probably wont be a way to get ourselves out. unless another Blackfin comes along that is not opcode compatible ... and we feel like shouldering the development burden. That's what I meant by habit :-) -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Sun, Jan 06, 2008 at 01:35:53AM -0500, Mike Frysinger wrote: On Wednesday 19 December 2007, Daniel Jacobowitz wrote: --- libc/inet/resolv.c (revision 189757) +++ libc/inet/resolv.c (local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + considering buflen gets checked constantly before being utilized, i dont think we need an additional check to see if it could possibly store a pointer. we just need to make sure the adjustment alone doesnt cause size_t underflow. That's exactly what I just did, except for the spelling of the alignment; sizeof(size_t) is sufficient on all Linux platforms for everything that gethostbyname_r puts in the buffer. i think this should be sufficient: /* Make sure the incoming char * buffer is aligned enough to * handle our random structures. This define is the same as we * use for malloc alignment (which has same requirements). */ i = (size_t)buf __alignof__(double __attribute_aligned__ (sizeof(size_t))); if (buflen i) return ERANGE; buf += i; buflen += i; - Why sizeof(size_t)? What does that have to do with anything, if you're already using __alignof__? - (size_t) buf 8 is not what you're trying to calculate, you need a -1. - buflen -= i, not plus -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Mon, Jan 07, 2008 at 06:29:43PM +0300, Alexander Voropay wrote: It seems, GCC 3.4.6 preprocessor supports ## concatenations incorrectly. I've took ENTRY definition from the sysdeps.h of the ia64/sysdeps.h It works. name##: is incorrect. ## is supposed to be used between parts of a single pp-token; : is a token all by itself. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Mon, Jan 07, 2008 at 11:39:39AM -0500, Mike Frysinger wrote: i misunderstood the purpose of the second assignment. i'll put together a test case and commit a fix ... Thank you! - buflen -= i, not plus i pointed this typo out already ... Sorry, stray list filters. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: mipsel memcpy gcc3.4.6
On Mon, Jan 07, 2008 at 12:00:20PM -0500, Mike Frysinger wrote: The current versions of GCC do exactly what the standard say they ought to: gq.c:2:1: error: pasting name and : does not give a valid preprocessing token what are you defining as current ? the current release (4.2.2) certainly accepts it as does a large majority of compiler versions (going by the fact that this is the first such bug report after using this code for quite a while): $ cat test.S #define foo(name) name##: foo(f) $ gcc -c test.S $ gcc --version gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0) Sorry, I forgot that it depends what language you're compiling. It's accepted for assembly, but not for C. There's special cases for # (stringify) too. I don't know why. -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Alignment fixups for gethostbyname_r
On Fri, Dec 21, 2007 at 09:12:52PM +0100, Bernhard Fischer wrote: This sounds OK to me. Please install it along a testcase if you tested it and found it to be good on all platforms in most common configurations with no regressions. I don't have write access. I tested ARM with no regressions, but that's all I'm set up to test unless someone has a lot of handy test scripts I don't know about... -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Alignment fixups for gethostbyname_r
MontaVista noticed that when their kernels were configured to trap on unaligned access gethostbyname_r could mysteriously crash. I tracked this down to an unaligned buffer being passed to gethostbyname_r from some other part of uClibc (afraid I don't remember where from any more). We have to pad the beginning of the buffer to a pointer alignment before we store pointers in it. Is this patch OK? -- Daniel Jacobowitz CodeSourcery --- libc/inet/resolv.c (revision 189757) +++ libc/inet/resolv.c (local) @@ -1534,6 +1534,15 @@ int attribute_hidden __read_etc_hosts_r( char *cp, **alias; int aliases, i, ret = HOST_NOT_FOUND; + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + if (buflen sizeof(char *)*(ALIAS_DIM)) return ERANGE; alias = (char **)buf; @@ -2030,6 +2039,16 @@ int gethostbyname_r(const char * name, DPRINTF(Nothing found in /etc/hosts\n); *h_errnop = NETDB_INTERNAL; + + /* Align to at least the size of a char * so we can put + pointers in it. */ + i = (unsigned long) buf % sizeof(char *); + i = (sizeof(char *) - i) % sizeof(char *); + if (buflen i) + return ERANGE; + buf+=i; + buflen-=i; + if (buflen sizeof(*in)) return ERANGE; in = (struct in_addr*)buf; ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: What is XMALLOC and how it compares with malloc?
On Thu, May 03, 2007 at 04:04:36PM -0600, Kevin Day wrote: rdesktop.c:/* malloc; exit if out of memory */ rdesktop.c:void *xmalloc(int size) My next assumption is that xmalloc is some sort of gcc's internal implementation of malloc Your assumption is completely wrong. This seems to make more sense than the my gcc assumption above, so I feel safest to assume that it is calling Xorg's malloc implementation for some reason. Which seems to explain why it is called xmalloc for Xorg Malloc.. This one too. As David already said, it's a common name for a common purpose. rdesktop has its own. Can we please stop speculating without evidence, now? -- Daniel Jacobowitz CodeSourcery ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
