Subject: Re: Preparing for another release.... - msg#00294

Previous Message by Date: click to view message preview

Re: TinyX/x86 compiles ok (was 0.9.15 and TinyX)

> I tried compiling the lot on my laptop and there it worked like a charm > (being a P3 600 Intel), but on the system I do most of my compiling sits an AMD > Thunderbirg 1.1 GHz with slackware 8.1 (ie GCC 2.95.2). > > After some trying last night I realized it segfaulted on some other > compilations with the wrapper for uClibc. How about forcing -march=i386 ?? 1.1 GHz ? You must be able to do 2 dozens of TinyX compile per day ! Lucky you... ;) Christian ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Next Message by Date: click to view message preview

Re: Attempting to port pthreads to the ColdFire (was: RE: Status of POSIX Thread Support in uClibc)

Hi, David Chan schrieb: > So, from examining the errors and source: > > /* Spinlock implementation; required. */ > PT_EI int > testandset (int *spinlock) > { > char ret; > > __asm__ __volatile__("tas %1; sne %0" > : "=dm"(ret), "=m"(*spinlock) > : "m"(*spinlock) > : "cc"); > > return ret; > } > > Error: invalid instruction for this architecture; > needs 68000 or higher -- statement `tas (%a0)' ignored > > - The tas instruction was eliminated from all ColdFire cores except for > v4 cores. This 'test and set' routine is intended to guarantee an atomic > read, modify, set behavior. This statement is intended to compare the > operand (%a0) to zero and set the CC flags as necessary (N, Z), and then > set the most significant bit of the byte to 1. This is supposed to be > performed without interruption. Theoretically, we could replace this > statement with a series of tst and andi instructions. But doesn't this > lose the no-interruption behavior we want from the tas instruction? The BSET command (Test a Bit and Set) could be used instead? >From the ColdFire Family Programmer's Reference Manual: ~(<bit number> of destination) -> CCR[Z]; 1 -> <bit number> of destination Regards Frieder

Previous Message by Thread: click to view message preview

Re: Preparing for another release....

On Mon, 26 Aug 2002, Erik Andersen wrote: > On Mon Aug 26, 2002 at 02:55:34PM -0700, David Schleef wrote: > > Is it still the case that changing options in the Config will > > cause binary incompatibilities? I have no problem with this > > by itself, but if there's going to be a "standard" ABI, it > > would be nice to have the exact specifications of this > > documented somewhere. (With prodding, I can help with this.) > > Yes, changing the config can cause binary incompatibilities. > There really isn't too much of a standard, since (thus far) > uClibc has not ever been geared towards maintaining binary > compatibility. We are probably close now to the point where such > a thing may become worthwhile. But I don't want to be boxed into > that quite yet. > > Within a couple of months we should be ready for a 1.0.0 release, > at which point the 1.0.x series will be guaranteed to retain > binary compatibility. One thing to start thinking about now is building explicit symbol export lists. That is, list every symbol you *intend* to export from the library. Although this is somewhat useful in the static link case, it can be quite useful for shared library users. o You can run a partial link before building an executable, looking for symbols in the "unintentionally exported" list. (Static, dynamic links) o You can examine "nm --dynamic" on executables. (Dynamic only.) o You can use the symbol versioning mechanisms to enforce the list at both build and runtime. (Dynamic only, I think.) o Given the above, people adding new functions and globals must take explicit action to gain access to them. Useful as a "did you mean to do this" mechanism. (Dynamic only.) o You can build libc4-style statically-linked, dynamically-loaded jumptable libraries. OK, most people don't want to go back to those bad old days, but on some architectures, notably embedded MIPS, there are huge performance advantages. (Weirdos only.) Jay

Next Message by Thread: click to view message preview

ctype.h bug

There appears to be a small bug in ctype.h of 0.9.14 and 0.9.12. When HAS_LOCALE is false, ctype.h defines tolower(), toupper() to the macros __C_tolower and __C_toupper. The macro expansion can be a bit of a problem for example: -------------------------------- #include <ctype.h> main() { char buf[4] = {"test"}; int idx = 2; printf("idx = %d\n", idx); toupper((unsigned char) buf[--idx]); printf("idx = %d\n", idx); } --------------------------------- The macro toupper() expands to (((sizeof((unsigned char) buf[--idx]) == sizeof(char)) ? (((unsigned char)(((unsigned char) buf[--idx]) - 'a')) < 26) : (((unsigned int)(((unsigned char) buf[--idx]) - 'a')) < 26)) ? (((unsigned char) buf[--idx]) ^ 0x20) : ((unsigned char) buf[--idx])); This causes --idx to be called twice. Incidentally, when <ctype.h> is not included the macro expansion does not take place and the toupper() function stub works as expected. Would it be possible to either remove the macros from ctype.h or to include inline functions (like glibc) instead. Thanks. Diff for ctype.h included --------------------------------- --- ctype.h.original 2002-08-25 21:41:33.000000000 -0400 +++ ctype.h 2002-08-25 21:41:46.000000000 -0400 @@ -114,8 +114,10 @@ #define ispunct(c) __C_ispunct(c) #define isupper(c) __C_isupper(c) +#if 0 #define tolower(c) __C_tolower(c) #define toupper(c) __C_toupper(c) +#endif #endif /* __UCLIBC_HAS_LOCALE__ */