obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
gcc 4.3.1
config/darwin.h:
#define ENABLE_EXECUTE_STACK\
extern void __enable_execute_stack (void *);\
void\
__enable_execute_stack (void *addr) \
{ \
extern int mprotect (void *, size_t, int); \
extern int getpagesize (void); \
static int size; \
static long mask;\
\
char *page, *end;\
\
if (size == 0) \
{ \
size = getpagesize();\
mask = ~((long) size - 1); \
} \
\
page = (char *) (((long) addr) & mask); \
end = (char *) long) (addr + (TARGET_64BIT ? 48 : 40))) & mask) +
size); \
\
/* 7 == PROT_READ | PROT_WRITE | PROT_EXEC */\
(void) mprotect (page, end - page, 7); \
}
contains obvious race condition.
between the storing of size and the storing of mask.
One thread might store size, making it not zero, and another thread
could then decide size is stored (it is), and that mask is stored (it isn't),
and go ahead and use the uninitialize zero value of mask.
easy fix: don't cache mask. Calling mprotect is going to expensive anyway.
Even getpagesize might be very cheap. Might not be worth caching.
like so (diff written by hand, and lots of extra whitespace
so mail programs maybe don't ruin the rest of the formating)
extern int getpagesize (void); \
static int size;\
< static long mask; \
> long mask; \
\
char *page, *end;\
\
if (size == 0) \
{ \
size = getpagesize();\
< mask = ~((long) size - 1); \
} \
> mask = ~((long) size - 1); \
Or maybe just make the compile-time constant.
same problem in netbsd.h
no problem in openbsd.h, sol2.h, osf.h -- no cache
no problem in freebsd.h, no use of page size
And yes, I know Apple doesn't even support this and that the whole
thing is maybe controversial, but that is independent.
The race condition shouldn't be there.
You might also fix it by checking if mask is zero, but that wouldn't suffice,
without a memory barrier and/or volatile -- to force mask to be stored after
size or such.
You don't really want volatile, or, if you do put in volatile, you want to have
locals
to cache the globals, to avoid unnecessary extra fetches.
(Yes, I'm micro optimizing and de-micro-optimzing, I realize.)
Really just not static caching mask and possibly not caching pagesize is a good
simple reliable efficient solution.
Caching the values in locals would be goodness imho though, like, again just
composed here, not compiled:
extern int mprotect (void *, size_t, int); \
extern int getpagesize (void); \
static size_t static_size;
\
size_t mask;\
size_t size; \
\
char *page, *end;\
mingwin getpagesize int vs. size_t
gcc 4.3.1, with minor patches build=host=i686-pc-cygwin target=i686-pc-mingw32 sys-root setup how I believe is appropriatev (well, er, um..maybe not, due to later problems, but I don't think that's the problem here; there indeed varying declarations of getpagesize) => /obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/./gcc/xgcc -B/obj/gcc.1/i686-pc-cygwin /i686-pc-mingw32/./gcc/ -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-ming w32/winsup/mingw -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/win sup/w32api/lib -isystem /src/gcc/winsup/mingw/include -isystem /src/gcc/winsup/w 32api/include -B/usr/local/i686-pc-mingw32/bin/ -B/usr/local/i686-pc-mingw32/lib / -isystem /usr/local/i686-pc-mingw32/include -isystem /usr/local/i686-pc-mingw3 2/sys-include -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/./ld -O2 -g -g -O2 -I/ src/gcc/gcc/../winsup/w32api/include -O2 -g -g -DIN_GCC -DCROSS_DIRECTORY_STRU CTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold- style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__G CC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/src/gcc/libgcc -I/src/gcc/libgcc/ . -I/src/gcc/libgcc/../gcc -I/src/gcc/libgcc/../include -DHAVE_CC_TLS -o _tramp oline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep -DL_trampoline -c /src/gcc /libgcc/../gcc/libgcc2.c \ /src/gcc/libgcc/../gcc/libgcc2.c:2052: error: conflicting types for 'getpagesize ' /usr/local/i686-pc-mingw32/sys-root/mingw/include/sys/unistd.h:75: error: previo us declaration of 'getpagesize' was here /src/gcc/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprot ect' make[2]: *** [_trampoline.o] Error 1 make[2]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mi ngw32/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32' make: *** [all] Error 2 The two protoypes are int getpagesize(void) size_t getpagesize(void) I can't prove to myself the function is even used, so I'll try #if 0 it. I do understand the point. Nested functions generate code on the stack. The stack might not be executable. Make the page with the trampoline executable via mprotect/VirtualProtect. I just don't see where __enable_execute_stack comes from for this target, other than a no-op. - Jay
Re: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
Sent from my iPhone
On Aug 27, 2008, at 0:27, Jay <[EMAIL PROTECTED]> wrote:
gcc 4.3.1
config/darwin.h:
#define
ENABLE_EXECUTE_STACK\
extern void __enable_execute_stack (void
*);\
void
\
__enable_execute_stack (void
*addr) \
{
\
extern int mprotect (void *, size_t,
int); \
extern int getpagesize (void); \
static int
size; \
static long
mask;\
\
char *page,
*end;\
\
if (size ==
0) \
{ \
size = getpagesize(); \
mask = ~((long) size - 1);
Or even better store size after the store to mask.
That is:
int tmp = getpagesize();
*(volatile*)&mask = ~((long)tmp - 1);
*(volatile*)&size = tmp;
Thanks,
Andrew Pinski
\
} \
\
page = (char *) (((long) addr) &
mask); \
end = (char *) long) (addr + (TARGET_64BIT ? 48 : 40))) &
mask) + size); \
\
/* 7 == PROT_READ | PROT_WRITE | PROT_EXEC
*/\
(void) mprotect (page, end - page,
7); \
}
contains obvious race condition.
between the storing of size and the storing of mask.
One thread might store size, making it not zero, and another thread
could then decide size is stored (it is), and that mask is stored
(it isn't),
and go ahead and use the uninitialize zero value of mask.
easy fix: don't cache mask. Calling mprotect is going to expensive
anyway.
Even getpagesize might be very cheap. Might not be worth caching.
like so (diff written by hand, and lots of extra whitespace
so mail programs maybe don't ruin the rest of the formating)
extern int getpagesize (void); \
static int
size;\
< static long
mask; \
long
mask; \
\
char *page,
*end;\
\
if (size ==
0) \
{ \
size = getpagesize(); \
< mask = ~((long) size -
1); \
} \
mask = ~((long) size -
1); \
Or maybe just make the compile-time constant.
same problem in netbsd.h
no problem in openbsd.h, sol2.h, osf.h -- no cache
no problem in freebsd.h, no use of page size
And yes, I know Apple doesn't even support this and that the whole
thing is maybe controversial, but that is independent.
The race condition shouldn't be there.
You might also fix it by checking if mask is zero, but that wouldn't
suffice,
without a memory barrier and/or volatile -- to force mask to be
stored after size or such.
You don't really want volatile, or, if you do put in volatile, you
want to have locals
to cache the globals, to avoid unnecessary extra fetches.
(Yes, I'm micro optimizing and de-micro-optimzing, I realize.)
Really just not static caching mask and possibly not caching
pagesize is a good simple reliable efficient solution.
Caching the values in locals would be goodness imho though, like,
again just composed here, not compiled:
extern int mprotect (void *, size_t,
int); \
extern int getpagesize (void);\
static size_t
static_size; \
size_t mask;\
size_t size; \
\
char *page,
*end;
"random" "Link tests are not allowed after GCC_NO_EXECUTABLES"
gcc 4.3.1 with small patches... (merged tree with binutils 2.18/gmp/mpfr, also slightly patched) build=i686-pc-cygwin host=i686-pc-cygwin target=i686-pc-mingw32 configure: /obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/libstdc++-v 3/../libgomp/omp.h not found checking for parallel mode support... no checking for extra compiler flags for building... checking for thread model used by GCC... win32 checking for atomic builtins... no checking for g++ that supports -ffunction-sections -fdata-sections... yes checking for sys/types.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for ld version... 21800 checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32' make: *** [all] Error 2 I hit this "Link tests are not allowed after GCC_NO_EXECUTABLES." for target=djgpp too, though in that case, I know I skipped their wrapper scripts which "preconfigure" some stuff via environment variables. I'll come back to this much later (days/weeks/months). I searched the web here some. It seems in general either: a merged gcc/newlib or gcc/glibc tree works well anything else, not to much, but sometimes e.g. I have built cygwin and solaris targets, with no libc source or maybe it depends on having a complete sysroot? Something seems to be off in general though for cross builds. ? This seems to be a FAQ with no answer. ? Like, there are too many link tests in configure? I'll try to just make install w/o completing make, so I get the compiler at least. I just need mingwin cc1 to make progress building cygwin1.dll with gcc 4.3.1. Could be my mingwin sys-root is bad. I have something kind of complicated in order to get this far, and I had to copy the cygwin winsup into the gcc tree, at least for w32api. Anyway, this is just a random report, like "cross building is a little too difficult". Perhaps the way to go is bootstrap with CC='gcc -mno-cygwin -V 3.4.4' since that has a full mingwin environment. - Jay
RE: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
Yeah that's probably ok. Volatile is enough to force the ordering? I still like just not caching mask. Is "volatile*" legal or just pseudo? Some platforms cache neither. Are some platforms getpagesize slow and others fast? Or it's just "random evolution"? If it's just "random", and nobody knows getpagesize to be slow, I'd say just never cache either. - Jay > > [snip snip snip] > > Or even better store size after the store to mask. > That is: > int tmp = getpagesize(); > *(volatile*)&mask = ~((long)tmp - 1); > *(volatile*)&size = tmp; > > Thanks, > Andrew Pinski
configure CFLAGS="-V 1.2.3" vs. -o
configure CFLAGS='-V 3.4.4' doesn't work because: configure:3291: i686-pc-cygwin-gcc -o conftest.exe -V 3.4.4 -mno-cygwin -g co nftest.c >&5 i686-pc-cygwin-gcc: '-V' must come at the start of the command line configure:3294: $? = 1 configure:3312: error: cannot compute suffix of executables: cannot compile and link Maybe an autoconf bug. Unless gcc could loosen up its command line parsing. I'll try CC instead of CFLAGS. - Jay
Re: configure CFLAGS="-V 1.2.3" vs. -o
Jay <[EMAIL PROTECTED]> writes: > configure CFLAGS='-V 3.4.4' doesn't work because: > > > configure:3291: i686-pc-cygwin-gcc -o conftest.exe -V 3.4.4 -mno-cygwin -g > co > nftest.c >&5 > i686-pc-cygwin-gcc: '-V' must come at the start of the command line > configure:3294: $? = 1 > configure:3312: error: cannot compute suffix of executables: cannot compile > and > link > > > Maybe an autoconf bug. No. CFLAGS is expected to be able to appear anywhere on the compiler command line (among the other flags). You can't include position-dependent flags. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Peter Dimov wrote: The problem, from the point of view of a library such as boost::shared_ptr, is that there is no way to distinguish between user A, who just types g++ foo.cpp and expects to get a program that works well on a typical machine, and user B, who types g++ -march=i386 foo.cpp, with the explicit intent to run the result on a 386. Maybe "no way" is a tad too strong: now we have |__GCC_HAVE_SYNC_COMPARE_AND_SWAP_? and more could be added... Paolo. |
RE: Repeat messages (was Re: broken svn commit logs and how to fix them)
NightStrike wrote on 27 August 2008 02:17: > On 8/26/08, David Daney wrote: >> Paul Koning wrote: >>> I'm seeing messages on this list repeating over and over (several >>> minutes apart, maybe as much as 15 minutes or so). I'm not sure if >>> the are just messages from Manuel or also from others. >>> Is it just me? It seems to be specific to this list... >>> >>> >> >> It seems that all the repeats are generated by gmail.com. You will note >> that NightStrike's messages are repeated as well. >> >> David Daney >> > > Really? I don't see that in the archives. I didn't check the archives, but it's absolutely gmail that's repeating. I checked the headers: - Manu's first post: Received: by rv-out-0708.google.com with SMTP id c5so1795974rvf.56 for ; Tue, 26 Aug 2008 07:47:57 -0700 (PDT) Received: by 10.141.198.9 with SMTP id a9mr2896281rvq.108.1219762077837; Tue, 26 Aug 2008 07:47:57 -0700 (PDT) - Manu's second post: Received: by rv-out-0708.google.com with SMTP id c5so1817870rvf.56 for ; Tue, 26 Aug 2008 08:56:07 -0700 (PDT) Received: by 10.141.198.9 with SMTP id a9mr2896281rvq.108.1219762077837; Tue, 26 Aug 2008 07:47:57 -0700 (PDT) - Manu's third post: Received: by rv-out-0708.google.com with SMTP id c5so1865394rvf.56 for ; Tue, 26 Aug 2008 11:14:27 -0700 (PDT) Received: by 10.141.198.9 with SMTP id a9mr2896281rvq.108.1219762077837; Tue, 26 Aug 2008 07:47:57 -0700 (PDT) - Manu's fourth post: Received: by rv-out-0708.google.com with SMTP id c5so1886123rvf.56 for ; Tue, 26 Aug 2008 12:16:29 -0700 (PDT) Received: by 10.141.198.9 with SMTP id a9mr2896281rvq.108.1219762077837; Tue, 26 Aug 2008 07:47:57 -0700 (PDT) As you see from the timestamps, 10.141.198.9 received the post only once, but is trying repeatedly to hand it off to the outward-facing system rv-out-0708.google.com. This system forwards it to the list successfully each time, but 10.141.198.9 doesn't realise that rv-out-0708 had accepted it, so it retried later, where the same thing happened again. Anyway, all seems to have quietened down today. cheers, DaveK -- Can't think of a witty .sigline today
RE: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
Jay wrote on 27 August 2008 09:55: > Yeah that's probably ok. > Volatile is enough to force the ordering? Absolutely; it's a defined part of the standard that all volatile side-effects must complete in-order. GCC will not move code past a volatile operation. > I still like just not caching mask. I think that's the best solution also. > Is "volatile*" legal or just pseudo? Legal. See the language in the standard about it being the qualification of the type of the lvalue through which you load or store that makes it a volatile operation. > Some platforms cache neither. > Are some platforms getpagesize slow and others fast? > Or it's just "random evolution"? > If it's just "random", and nobody knows getpagesize to be slow, > I'd say just never cache either. I have no idea if anyone's measured it or not, but if we only cache size, not mask, then it's completely robust and it's a trivial optimisation that can't hurt. I certainly can't see that a subtract-by-one-and-not operation would ever take so long as to be worth saving the time by caching the result. cheers, DaveK -- Can't think of a witty .sigline today
Re: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
Andrew Thomas Pinski wrote: On Aug 27, 2008, at 0:27, Jay <[EMAIL PROTECTED]> wrote: size = getpagesize(); \ mask = ~((long) size - 1); Or even better store size after the store to mask. That is: int tmp = getpagesize(); *(volatile*)&mask = ~((long)tmp - 1); *(volatile*)&size = tmp; Does this work on machines that support out-of-order execution? For example, shouldn't there be the equivalent of a powerpc eieio to ensure that the stores *happen* in order? I'm assuming, of course, that Darwin runs on different processor architectures.
Re: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
On Wed, Aug 27, 2008 at 02:45:25PM +0100, Dave Korn wrote: > Jay wrote on 27 August 2008 09:55: > > > Yeah that's probably ok. > > Volatile is enough to force the ordering? > > Absolutely; it's a defined part of the standard that all volatile > side-effects must complete in-order. GCC will not move code past a volatile > operation. It's still not sufficient without a memory barrier. -- Daniel Jacobowitz CodeSourcery
RE: obvious race condition in darwin/netbsd __enable_execute_stackdue to caching pagesize/mask
Daniel Jacobowitz wrote on 27 August 2008 16:15: > On Wed, Aug 27, 2008 at 02:45:25PM +0100, Dave Korn wrote: >> Jay wrote on 27 August 2008 09:55: >> >>> Yeah that's probably ok. >>> Volatile is enough to force the ordering? >> >> Absolutely; it's a defined part of the standard that all volatile >> side-effects must complete in-order. GCC will not move code past a >> volatile operation. > > It's still not sufficient without a memory barrier. Yes, you're right. Of course, if we just don't cache mask at all, the problem goes away. cheers, DaveK -- Can't think of a witty .sigline today
QUERY : ARM inline code in Thumb file?
hello:
one small question regarding use of ARM inline assembly code in a
C file that has been compiled for Thumb mode.
is it possible to use ARM assembly code from within a C file that
has been compiled for Thumb and Thumb interworking?
how this is done is described on this page:
http://www.devrs.com/gba/files/asmc.txt
i have a C file that has been compiled for Thumb mode. in it, i am
using ARM inline assembly code. apparently, GCC issues no error
message but forcibly converts the ARM code into Thumb code.
i think that GCC requires an entire file to be in either Thumb mode
or ARM mode, but i am not sure. is that true?
the C code that is compiled into Thumb is:
void function_f( void )
{
asm volatile
(
".align\n"
"__f_into_arm:\n\t"
".arm \n\t"
"mrs r0, cpsr \n\t"
"msr cpsr_c, r0\n\t"
"pop { r0 }\n"
"__f_from_arm:\n\t"
".thumb"
);
}
the C code is compiled with:
arm-elf-gcc -mlittle-endian -mcpu=arm7tdmi -march=armv4t\
-mthumb-interwork -mthumb -mno-tpcs-frame .
here is the generated code:
8194 :
8194: b580push{r7, lr}
8196: af02add r7, sp, #8
8198 <__f_into_arm>:
8198: lslsr0, r0, #0
819a: e10fb.n 83bc
819c: f000 e121 blx 4083e0 <_stack+0x3883e0>
81a0: 0001lslsr1, r0, #0
81a2: e8bd 46bd ldmia.w sp!, {r0, r2, r3, r4, r5, r7, r9, sl, lr}
81a4 <__f_from_arm>:
81a4: b08246bdstrlth r4, [r2], sp
81a8: bc01bc80stclt 12, cr11, [r1], {128}
81ac: 4700andeq r4, r0, r0, lsl #14
in the inline assembly code, if i do not use ".arm", i get compiler
errors.
is it possible to use ARM assembly code from within a C file that
has been compiled for Thumb and Thumb interworking?
Makefile
CC= arm-elf-gcc
TARGET_ARCH = -mlittle-endian -mcpu=arm7tdmi -march=armv4t
-mthumb-interwork
TARGET_ARCH += -mthumb -mno-tpcs-frame
all: test
arm-elf-objdump -S -D test > test.lst
clean:
rm -f test test.o function.o
test.c
---
void function_f( void )
{
asm volatile
(
".align\n"
"__f_into_arm:\n\t"
".arm \n\t"
"mrs r0, cpsr \n\t"
"msr cpsr_c, r0\n\t"
"pop { r0 }\n"
"__f_from_arm:\n\t"
".thumb"
);
}
int main( void )
{
function_f();
return 0;
}
--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-800-450-5419}
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, 22 Aug 2008, Richard Henderson wrote: > H.J. Lu wrote: > > Can we declare that Linux/ia32 generates i486 insn by default? > > We the gcc team? I'm not sure. For now I'll say no. > > We an individual linux distributor? Certainly. > In fact I would be surprised if i586 wasn't a > decent minimum these days. glibc has certainly required -march=i486 or greater for some time to build for IA32; it will fail to link for -march=i386 because of missing atomic operations. (And I hold that i686-* should mean -march=i686 default not -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, subject to --with-arch etc. in both cases.) For the C++ interfaces in question, atomic and threading interfaces of C++0x, and atomic and threading interfaces that may end up in C1x, I think there are several cases to consider: * Does the target support threads? If so, let's assume for now that GCC will always know about what sort of threads are in use at configure time. (In principle, generic bare-metal *-elf and *-eabi targets might allow someone to swap in their choice of RTOS threading library, not present when GCC is built, but I doubt that works well at present.) * Does the CPU support atomic operations? If not, are there OS-provided atomic operations that can be used as a fallback. Then some cases are clear: * If the CPU provides atomic operations, libstdc++ can use them, independent of what OS may be in use. * libstdc++ can only provide some threading interfaces if underlying OS threads are available. Now consider the case where no threads are available. The atomic interfaces still need to be atomic if they are meant to be async-signal-safe as well as thread-safe - are they? What about the exception interfaces in question that use atomic operations internally? Is atomicity needed for signal-safety here, or only for thread-safety? Perhaps an implementation of the standard interfaces should be provided even if it's not safe with signals in certain cases. The most troublesome case is where there are threads but no adequate atomic operations. (It's not clear to me that threads exist without *any* atomic operations, but there may be cases without *enough* atomic operations for libstdc++, e.g. ColdFire Linuxthreads using test-and-set with no compare-and-exchange operation available.) In such a case certain interfaces may not be providable in a thread-safe way without kernel help. In a way it might be good to provide the interfaces in single-threaded programs and somehow give a link failure if the interfaces are used in a program linked with -lpthread - but I don't know how to do that. One significant case is where atomic operations are available with kernel help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed patch to do the same for ARM GNU/Linux; both use kernel help in those implementations, and more targets may do this in future. (It's been proposed for HPPA. The ColdFire NPTL specification doesn't include exporting such helpers from libgcc but they could easily be exported from libc; the use of a vDSO may make exporting from libgcc harder.) The GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect for such cases, because it greps for __sync in a .s file and these targets will have such __sync_* references resolved in libgcc. So on GNU/Linux that configure test ought to be a link test. If someone cares about -march=i386 GNU/Linux, they should provide appropriate kernel helpers for atomic operations and make libgcc provide the relevant functions, calling the helpers for i386 and written in assembly for i486 and later (present for i486 and later only so the interfaces provided by libgcc don't depend on the target). One form of helpers would be emulation for the relevant instructions, in which case a single assembly implementation could be used. Similarly, any other case where there are threads but no native atomic operations can have helpers provided in libgcc or libc using kernel support, and the libstdc++ configure test can be made to allow for this case. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers <[EMAIL PROTECTED]> wrote: > On Fri, 22 Aug 2008, Richard Henderson wrote: > >> H.J. Lu wrote: >> > Can we declare that Linux/ia32 generates i486 insn by default? >> >> We the gcc team? I'm not sure. For now I'll say no. >> >> We an individual linux distributor? Certainly. >> In fact I would be surprised if i586 wasn't a >> decent minimum these days. > > glibc has certainly required -march=i486 or greater for some time to build > for IA32; it will fail to link for -march=i386 because of missing atomic Given that glibc requires -march=i486, I think Linux/ia32 should default to i486. > operations. (And I hold that i686-* should mean -march=i686 default not > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, > subject to --with-arch etc. in both cases.) > I think i[4-6]86-*-linux and x86_64-*-linux should default to i486 at minimum for 32bit. -- H.J.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Hi, One significant case is where atomic operations are available with kernel help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed patch to do the same for ARM GNU/Linux; both use kernel help in those implementations, and more targets may do this in future. (It's been proposed for HPPA. The ColdFire NPTL specification doesn't include exporting such helpers from libgcc but they could easily be exported from libc; the use of a vDSO may make exporting from libgcc harder.) The GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect for such cases, because it greps for __sync in a .s file and these targets will have such __sync_* references resolved in libgcc. So on GNU/Linux that configure test ought to be a link test. For this issue, do you think it would be Ok to the change the current open-coded test to the usual GCC_TRY_COMPILE_OR_LINK pattern? Thanks, Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini: Peter Dimov wrote: The problem, from the point of view of a library such as boost::shared_ptr, is that there is no way to distinguish between user A, who just types g++ foo.cpp and expects to get a program that works well on a typical machine, and user B, who types g++ -march=i386 foo.cpp, with the explicit intent to run the result on a 386. Maybe "no way" is a tad too strong: now we have |__GCC_HAVE_SYNC_COMPARE_AND_SWAP_? and more could be added... I may be missing something, but doesn't testing __i486__ give me the same information as __HAVE_CAS_x in this case? The problem is not that the library cannot distinguish between -m386 and -m486; the problem is that it cannot distinguish between explicit -m386 and implicit -m386. This is an issue because many users target i386 by accident and not by design simply because it is the default in many g++ installations. In practice, when one does: g++ foo.cpp g++ -m586 bar.cpp g++ foo.o bar.o it is reasonable to expect the end result to work on a 586 or better. But if a library header uses spinlocks on 386 and inlined __sync on 586, the code will fail in subtle ways, because the manipulation of some shared variables may no longer be atomic. The only solution today for the above situation is to ignore the lack of __i486__ and consistently use cmpxchg. This of course is not good for people who explicitly target i386. If g++ defaults to i486, the libraries can use the lack of __i486__ as a definite sign of the user explicitly targeting i386, in which case they can safely refrain from using cmpxchg/xadd without fear of breaking the above example.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers > > glibc has certainly required -march=i486 or greater for some time to build > > for IA32; it will fail to link for -march=i386 because of missing atomic On Wed, Aug 27, 2008 at 10:26:32AM -0700, H.J. Lu wrote: > Given that glibc requires -march=i486, I think Linux/ia32 should default > to i486. Agreed; defaulting to i386 just causes problems (with both glibc and Boost), so since i486 is effectively a requirement imposed by glibc, it might as well be the default. Embedded apps might use the Linux kernel and newlib or uClibc and work on an i386 equivalent, but it's not too much of a burden to ask the developer to give an -march flag in that case. On the embedded issue: does anyone know which *currently shipping* embedded x86-compatible processors are not i486-compatible? Joseph again: > > operations. (And I hold that i686-* should mean -march=i686 default not > > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, > > subject to --with-arch etc. in both cases.) I'm not keen on moving the default -march all the way to i686, as there are still enough old machines out there that this could cause inconvenience.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, 27 Aug 2008, Paolo Carlini wrote: > Hi, > > One significant case is where atomic operations are available with kernel > > help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed > > patch to do the same for ARM GNU/Linux; both use kernel help in those > > implementations, and more targets may do this in future. (It's been > > proposed for HPPA. The ColdFire NPTL specification doesn't include > > exporting such helpers from libgcc but they could easily be exported from > > libc; the use of a vDSO may make exporting from libgcc harder.) The > > GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect for > > such cases, because it greps for __sync in a .s file and these targets will > > have such __sync_* references resolved in libgcc. So on GNU/Linux that > > configure test ought to be a link test. > > > For this issue, do you think it would be Ok to the change the current > open-coded test to the usual GCC_TRY_COMPILE_OR_LINK pattern? The test will always compile, but sometimes the result will have references to the __sync_* functions in the output. Then, for certain targets where these functions are defined in a library, the result will link. (The only targets where these are defined in a library are targets where we can assume link tests are OK.) So a normal compile-or-link isn't what we want here; it's "link if you can do link tests, but otherwise check the .s file" or "link for *-*-linux* *-*-uclinux*, but otherwise check the .s file". -- Joseph S. Myers [EMAIL PROTECTED]
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, 27 Aug 2008, Joe Buck wrote: > Joseph again: > > > operations. (And I hold that i686-* should mean -march=i686 default not > > > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, > > > subject to --with-arch etc. in both cases.) > > I'm not keen on moving the default -march all the way to i686, as there > are still enough old machines out there that this could cause > inconvenience. Users of those systems should configure for i586-linux-gnu or i486-linux-gnu not i686-linux-gnu. config.guess should select such a target automatically in the case of a native build. (If you configure glibc for i686-linux-gnu, it will use assembly sources that require i686.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Joseph S. Myers wrote: The test will always compile, but sometimes the result will have references to the __sync_* functions in the output. Then, for certain targets where these functions are defined in a library, the result will link. (The only targets where these are defined in a library are targets where we can assume link tests are OK.) So a normal compile-or-link isn't what we want here; it's "link if you can do link tests, but otherwise check the .s file" or "link for *-*-linux* *-*-uclinux*, but otherwise check the .s file". I see, a sort of GCC_CHECK_S_OR_LINK ;) Thanks for the explanation, I didn't write that test. If you have a patch ready for it, consider it pre-approved, otherwise I may come to it but not very soon, I was not aware of the issue. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Joseph S. Myers wrote: > Users of those systems should configure for i586-linux-gnu or > i486-linux-gnu not i686-linux-gnu. config.guess should select such a > target automatically in the case of a native build. (If you configure > glibc for i686-linux-gnu, it will use assembly sources that require i686.) That seems entirely reasonable to me. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, Aug 27, 2008 at 05:55:19PM +, Joseph S. Myers wrote: > On Wed, 27 Aug 2008, Joe Buck wrote: > > > Joseph again: > > > > operations. (And I hold that i686-* should mean -march=i686 default not > > > > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, > > > > subject to --with-arch etc. in both cases.) > > > > I'm not keen on moving the default -march all the way to i686, as there > > are still enough old machines out there that this could cause > > inconvenience. > > Users of those systems should configure for i586-linux-gnu or > i486-linux-gnu not i686-linux-gnu. config.guess should select such a > target automatically in the case of a native build. (If you configure > glibc for i686-linux-gnu, it will use assembly sources that require i686.) I think we don't mean the same thing by "user". From gcc's perspective, what others would call a developer (someone who writes and compiles programs) we call a user. But far more people just run software than write it. Users of old Pentiums and the like are mostly non-programmers, who will download executables built by others, which will not run if their -march is i686. With i486, it's different, in that making the arch be 386 can be actively dangerous (you could get two different kinds of locking in a program that don't interoperate correctly).
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, Aug 27, 2008 at 11:02 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Joseph S. Myers wrote: > >> Users of those systems should configure for i586-linux-gnu or >> i486-linux-gnu not i686-linux-gnu. config.guess should select such a >> target automatically in the case of a native build. (If you configure >> glibc for i686-linux-gnu, it will use assembly sources that require i686.) > > That seems entirely reasonable to me. > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ... x86-64. Is someone working on such a patch? -- H.J.
RE: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
> "(volatile*) So this is using implied int then? Isn't that really considered to be avoided these days? Or perfectly ok in C? I know it is "legal", but I assume to be avoided as a matter of taste and C++ compat. Or you can really omit the type I think not. Might be a nice extension though. "Someone" please fix. I don't have write access. Seems agreed best fix is to not cache mask. Not cashing size seems goodness too but should probably first read getpagesize on the affected systems (including older versions), make sure it is just returning a constant, not making a syscall. I'm also not sure about "left casting". int i = 123; (*(char*)&i) = 0; Legal? Tangential and now moot I realize. I understand the point, it is a common construct, but I've long wondered if the standard allows it. I understand that: int i = 123; volatile char* p = (volatile char*) &i; *p = 0; is legal -- with a type, and not "left". btw, I think the cache is also badness in that writable globals should be minimized. In the interest of minimizing dirty pages, "dirtiable" pages, etc. (ie: if you have 4k + 4 bytes of writable globals, saving 4 bytes probably saves 4k.) It's also smaller code to not cache, of course. Thanks, - Jay > From: dave@ > [snip snip snip...]
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
"H.J. Lu" wrote: > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should > be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ... > x86-64. Is someone working on such a patch? IMHO making this Linux specific just replaces one confusing and arbitrary decision with another. Why should --target=i686-*-linux imply -march=686 when, say, --target=i686-*-freebsd or --target=i686-*-elf still implies -march=386? If you want to imply a default -march from the target specification (and I think that's a perfectly good thing to want to do) then it should apply to all x86 targets equally. If that's too radical of a change then just bumping the universal default to 486 seems like the next best thing -- at least that's consistent. Brian
Re: QUERY : ARM inline code in Thumb file?
On Wed, Aug 27, 2008 at 10:31:24PM +0530, Aaron P. D'Souza wrote: > i have a C file that has been compiled for Thumb mode. in it, i am > using ARM inline assembly code. apparently, GCC issues no error > message but forcibly converts the ARM code into Thumb code. It's just being disassembled wrong; try using a newer version of objdump. But if you want to change modes, you're going to need a 'bx pc'. > i think that GCC requires an entire file to be in either Thumb mode > or ARM mode, but i am not sure. is that true? It has to be effectively true. Leave the file in the same mode it was in when the asm was entered. -- Daniel Jacobowitz CodeSourcery
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Wed, 27 Aug 2008, Brian Dessent wrote: > "H.J. Lu" wrote: > > > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should > > be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ... > > x86-64. Is someone working on such a patch? > > IMHO making this Linux specific just replaces one confusing and > arbitrary decision with another. Why should --target=i686-*-linux imply > -march=686 when, say, --target=i686-*-freebsd or --target=i686-*-elf > still implies -march=386? If you want to imply a default -march from > the target specification (and I think that's a perfectly good thing to > want to do) then it should apply to all x86 targets equally. If that's My proposal is exactly that the target triplet should imply -march on x86 - just as it implies -mcpu on SPARC where -mcpu means -march rather than -mtune. -- Joseph S. Myers [EMAIL PROTECTED]
Re: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
On Wed, Aug 27, 2008 at 11:47 AM, Jay <[EMAIL PROTECTED]> wrote: > >> "(volatile*) > > So this is using implied int then? > Isn't that really considered to be avoided these days? Or perfectly ok in C? > I know it is "legal", but I assume to be avoided as a matter of taste and C++ > compat. > Or you can really omit the type I think not. Might be a nice extension > though. I was typing fast on my iphone :). yes it should have been the volatile type of size and mask. > (*(char*)&i) = 0; is legal as *rvalue is a lvalue. -- Pinski
PATCH: Set with_cpu/with_arch based on target
On Wed, Aug 27, 2008 at 12:36 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote: > On Wed, 27 Aug 2008, Brian Dessent wrote: > >> "H.J. Lu" wrote: >> >> > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch >> > should >> > be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ... >> > x86-64. Is someone working on such a patch? >> >> IMHO making this Linux specific just replaces one confusing and >> arbitrary decision with another. Why should --target=i686-*-linux imply >> -march=686 when, say, --target=i686-*-freebsd or --target=i686-*-elf >> still implies -march=386? If you want to imply a default -march from >> the target specification (and I think that's a perfectly good thing to >> want to do) then it should apply to all x86 targets equally. If that's > > My proposal is exactly that the target triplet should imply -march on x86 > - just as it implies -mcpu on SPARC where -mcpu means -march rather than > -mtune. > Here is a patch. Tested on Linux/ia32 and Linux/Intel64 with native targets. OK for trunk? Thanks. -- H.J. --- 2008-08-27 H.J. Lu <[EMAIL PROTECTED]> * config.gcc: Set arch/cpu for i[34567]86-*-*|x86_64-*-* targets. Set with_cpu/with_arch from arch/cpu. Allow x86-64 for with_cpu/with_arch. gcc-arch-1.patch Description: Binary data
J'ai simplement doubler mes ventes! (Quelle catastrophe!)
Bonjour, Oui je dis quel catastrophe! J'ai simplement doubler mes ventes en quelques mois au lieu de les tripler! Heureusement, que ce doublement de mes ventes s'est stabilisé et a même tendance à encore augmenter! Si vous êtes comme moi et que vous avez un site internet, une newsletter, un blog,vous vendez sur internet etc... vous devez utiliser un logiciel d'emailing performant pour au moins doubler vos ventes! http://url-ok.com/6648dd Tester gratuitement les avantages de ce logiciel, en vous renseignant à cette page: http://url-ok.com/6648dd Bien cordialement, Elom [EMAIL PROTECTED], http://url-ok.com/6648dd
GCC 4.3.2 Status Report (2008-08-27)
Status == The 4.3.2 release is now available from gcc.gnu.org and ftp.gnu.org (except for a random subset of files that ftp.gnu.org appears to have ignored for no reason evident to me). The announcement will be sent to gcc-announce once some time has been allowed for mirrors to be updated. The GCC 4.3 branch is now open for commits again under the usual release branch rules, with 4.3.3 expected around 27 October. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 122 + 6 P34 - 3 --- --- Total 126 + 3 Previous Report === http://gcc.gnu.org/ml/gcc/2008-08/msg00289.html The next report for the 4.3 branch will be sent by Richard. -- Joseph S. Myers [EMAIL PROTECTED]
gcc-4.2-20080827 is now available
Snapshot gcc-4.2-20080827 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080827/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 139677 You'll find: gcc-4.2-20080827.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080827.tar.bz2 C front end and core compiler gcc-ada-4.2-20080827.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080827.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080827.tar.bz2 C++ front end and runtime gcc-java-4.2-20080827.tar.bz2 Java front end and runtime gcc-objc-4.2-20080827.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080827.tar.bz2The GCC testsuite Diffs from 4.2-20080820 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC targets need updating for new register allocator
The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. All GCC targets need updating for the new allocator; targets that have not been updated when the old allocator is removed will no longer work and will be added to the deprecation list for GCC 4.4. (After that date target maintainers may remove their targets from the deprecation list as part of the patches updating them for the new allocator; any remaining unconverted targets will be removed from trunk after GCC 4.4 branches along with the other targets deprecated in 4.4.) Updating a target is a matter of adding an IRA_COVER_CLASSES definition. If you need advice about defining this macro for a target, please ask Vladimir Makarov, not me. It is of course possible that a target has become bit-rotten in other ways and so needs further fixes to build. Once GCC trunk is building for your target with IRA enabled (with all necessary changes having been committed to GCC trunk), please post test results for unmodified GCC trunk to gcc-testresults if at all possible to provide a record of the current state of that port, if test results for that port are not already being posted reasonably frequently. The following targets are currently unconverted: arc cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 m68k mcore mips mmix pa pdp11 score stormy16 v850 vax xtensa -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC targets need updating for new register allocator
Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. All GCC targets need updating for the new allocator; targets that have not been updated when the old allocator is removed will no longer work and will be added to the deprecation list for GCC 4.4. (After that date target maintainers may remove their targets from the deprecation list as part of the patches updating them for the new allocator; any remaining unconverted targets will be removed from trunk after GCC 4.4 branches along with the other targets deprecated in 4.4.) Updating a target is a matter of adding an IRA_COVER_CLASSES definition. If you need advice about defining this macro for a target, please ask Vladimir Makarov, not me. It is of course possible that a target has become bit-rotten in other ways and so needs further fixes to build. Once GCC trunk is building for your target with IRA enabled (with all necessary changes having been committed to GCC trunk), please post test results for unmodified GCC trunk to gcc-testresults if at all possible to provide a record of the current state of that port, if test results for that port are not already being posted reasonably frequently. The following targets are currently unconverted: arc cris crx fr30 frv h8300 iq2000 m32c m32r m68hc11 m68k mcore mips mmix pa pdp11 score stormy16 v850 vax xtensa I've already volunteered for the h8 and I'll also take the v850. I'll be starting them once I nail down this latent bug in the mn103 port. jeff
Re: GCC targets need updating for new register allocator
Joseph S. Myers wrote: The new Integrated Register Allocator is now in GCC trunk, and the old allocator is scheduled for removal on or shortly after 25 September. All GCC targets need updating for the new allocator; targets that have not been updated when the old allocator is removed will no longer work and will be added to the deprecation list for GCC 4.4. (After that date target maintainers may remove their targets from the deprecation list as part of the patches updating them for the new allocator; any remaining unconverted targets will be removed from trunk after GCC 4.4 branches along with the other targets deprecated in 4.4.) I have a patch for Xtensa but I'm still tracking down a problem related to the IRA code. I'm sure I'll get it sorted out soon.
