x86-64 default memory models
Hi, There seems to be something missing in regards to default memory models in the C compiler. There are memory model switches for small, medium and large memory models, and there are switches for position independent code (pic and pie), but there is no way (that I can find) to build a cross-compiler that defaults to anything else than the small memory model. There is a special case for Windows-based platforms that changes to small memory model and pic, but other than that, the default seems to be small memory model and no pic. I imagine this supports the major platforms (Linux, Windows), so nobody thinks there is a need for other cases. Since it is not possible to build different parts of an application with different memory model switches, there is a need to build everything with the same switches, including libgcc and libc/newlib. It is no good to patch every project with these switches, as it adds unnecesary complexity to these projects as well. Therefore, there is a need to be able to build cross compilers that have other defaults for memory model than small. I posted a prosed solution for this eariler, but got no relevant responses for it, so here it is again: 1. Add a new macro to i386.h: diff -u -r -N gcc-4.8-20121202/gcc/config/i386/i386.h gcc-work/gcc/config/i386/i386.h --- gcc-4.8-20121202/gcc/config/i386/i386.h 2012-11-23 17:02:10.0 +0100 +++ gcc-work/gcc/config/i386/i386.h 2012-12-08 12:17:40.0 +0100 @@ -86,6 +86,8 @@ #define TARGET_LP64 TARGET_ABI_64 #define TARGET_X32 TARGET_ABI_X32 +#define TARGET_MEDIUM_PIC 0 + /* SSE4.1 defines round instructions */ #define OPTION_MASK_ISA_ROUND OPTION_MASK_ISA_SSE4_1 #define TARGET_ISA_ROUND ((ix86_isa_flags & OPTION_MASK_ISA_ROUND) != 0) 2. Add support for the macro in i386.c: diff -u -r -N gcc-4.8-20121202/gcc/config/i386/i386.c gcc-work/gcc/config/i386/i386.c --- gcc-4.8-20121202/gcc/config/i386/i386.c 2012-12-02 00:43:52.0 +0100 +++ gcc-work/gcc/config/i386/i386.c 2012-12-11 21:43:48.0 +0100 @@ -3235,6 +3235,8 @@ DLL, and is essentially just as efficient as direct addressing. */ if (TARGET_64BIT && DEFAULT_ABI == MS_ABI) ix86_cmodel = CM_SMALL_PIC, flag_pic = 1; + else if (TARGET_64BIT && TARGET_MEDIUM_PIC) +ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1; else if (TARGET_64BIT) ix86_cmodel = flag_pic ? CM_SMALL_PIC : CM_SMALL; else 3. Override the macro in an OS-defined file: +#undef TARGET_MEDIUM_PIC +#define TARGET_MEDIUM_PIC 1 Regards, Leif Ekblad
gcc-4.8-20121216 is now available
Snapshot gcc-4.8-20121216 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20121216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 194542 You'll find: gcc-4.8-20121216.tar.bz2 Complete GCC MD5=3d61ebcb61d670d057a2a934b63fc11a SHA1=aa995d7784a1a557dee72473186369eb9acd764d Diffs from 4.8-20121209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
Re: Chromium ISSUE with GCC 4.8
On Thu, 29 Nov 2012, Paolo Carlini wrote: >> FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC >> 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> i386 >> >> chromium-23.0.1271.64_1 compiled perfectly. >> >> But chromium-23.0.1271.91 fails: > Looks like you aren't building with current mainline and your tree doesn't > include the fix for PR55337. Yes, in fact also /proc/self/exe: No such file or directory indicates that the version of GCC you are using is of some GCC 4.8.0 vintage, alas a bit older and does not yet feature 2012-11-12 Ian Lance Taylor Rainer Orth Gerald Pfeifer * configure.ac: Check for getexecname. * fileline.c: #include . Define getexecname if not available. (fileline_initialize): Try to find the executable in a few different ways. * print.c (error_callback): Only print the filename if it came from the backtrace state. * configure, config.h.in: Rebuild. If you are using GCC built yourself from upstream sources, I recommend you upgrade to current SVN. If you are using the lang/gcc48 port in FreeBSD, on December 5th (which is a few days after your report), I updated that one to include the change above. Can you please try updating GCC and advise whether this fixes the issue? (If it does not, it's probably best to report a bug following the instructions at http://gcc.gnu.org/bugs as indicated in the error message you quoted to us.) Gerald
Arbeit
Hi! Das ist die Firma “Exchangemoney”. Wir haben Ihre E-Mail Adresse von der Arbeitsvermittlung erhalten. Wir entschuldigen uns fuer die ploetzliche Nachricht, aber wir brauchen dringend Mitarbeiter. Die Aufgabe unserer Mitarbeiter soll es sein, Geld- und Nicht-Geld-Einlagen von unserer Firma anzunehmen und diese zu unseren Kunden zu liefern. Wenn Sie etwas Freizeit haben, koennen wir zusammen gutes Geld verdienen. Aber zunaechst muessen wir etwas ueber Sie erfahren: 1. Ihr Alter; 2. Das Land und die Stadt, in der Sie leben; 3. Zur welcher Uhrzeit Sie mit uns arbeiten koennen (von … bis…). Mit diesen Informationen werden wir es entscheiden, ob Sie in unsere Firma reinpassen oder nicht. Klingt das gut? Wenn Sie also interessiert sind, antworten Sie uns bitte per E-Mail: exchangemoney.i...@yahoo.com Die meisten unserer Mitarbeiter sprechen nicht Deutschland. So schreiben Sie uns bitte in Englisch. Wenn Sie nicht wissen Englisch, nutzen Sie bitte Google Translator. Ok? Vielen Dank, Die Firma „Exchangemoney“
i386 port
Hi, I followed the directions on http://gcc.gnu.org/simtest-howto.html 1. ran into the problem that gcc failed the compiling with newlib -- it's a cross-compiler issue 2. patched with gcc-rtems patch 3. configured with ../combined/configure \ --target=i386-rtems \ --prefix=/home/stanr/Desktop/gcc-testing/install \ --with-gnu-as \ --with-gnu-ld \ --with-newlib \ --with-system-zlib \ --disable-nls \ --enable-version-specific-runtime-libs \ --disable-shared \ --disable-checking 4. ran make >> /dev/null 5. running make check-gcc >> results.txt After the results ran past the screen limit I cancelled it, and am running it again, this time to a file. Much to my surprise, the i386-rtems compiler passed some of the tests running on my i686 machine. I know the results will not be completely useful, because the build machine is a i686, but I'm trying to show a good faith effort. My next step will be to learn how to use qemu as an i386 simulator in the context of DejaGNU. After some searching I've found http://gcc.gnu.org/ml/gcc/2009-04/msg00759.html. Hopefully, I'll be able to figure out how to use qemu with DejaGNU. Again, thanks for all the help and support! From: Ralf Corsepius [ralf.corsep...@googlemail.com] Sent: Saturday, December 15, 2012 7:50 PM To: Joel Sherrill Cc: Robert Dewar; Ralf Corsepius; Richard Biener; Cynthia Rempel; gcc@gcc.gnu.org Subject: Re: Please don't deprecate i386 for GCC 4.8 On 12/15/2012 07:02 PM, Joel Sherrill wrote: > I did test i386-rtems in the past few months but it had a build breakage and > I filed a PR. That issue was resolved but at that point about 1/4 of the > rtems targets failed to compile. You likely are referring to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Yes, this bug is fixed, but a follow-up discussion[1] of this as resulted into what I had called "the known and yet unresolved soft-float/i386" issues earlier in this thread. Ralf [1] Start around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175#c9 Todate, I know there are at least 2 (possibly 3) bugs interacting, one (possibly 2) in GCC and one in newlib, which render the i386/softfloat multilib variant of i386-rtems GCC non-functional.
libtsan invalid use of ld-linux internals
Hi!
I've noticed libtsan can't be installed via rpm, due to invalid use of
dynamic linker's internals:
#ifdef __i386__
# define INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
#else
# define INTERNAL_FUNCTION
#endif
extern "C" void _dl_get_tls_static_info(size_t*, size_t*)
__attribute__((weak)) INTERNAL_FUNCTION;
static int InitTlsSize() {
typedef void (*get_tls_func)(size_t*, size_t*) INTERNAL_FUNCTION;
get_tls_func get_tls = &_dl_get_tls_static_info;
if (get_tls == 0) {
void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");
CHECK_EQ(sizeof(get_tls), sizeof(get_tls_static_info_ptr));
internal_memcpy(&get_tls, &get_tls_static_info_ptr,
sizeof(get_tls_static_info_ptr));
}
CHECK_NE(get_tls, 0);
size_t tls_size = 0;
size_t tls_align = 0;
get_tls(&tls_size, &tls_align);
return tls_size;
}
The
get_tls_func get_tls = &_dl_get_tls_static_info;
is what precludes libtsan installation, then libtsan.so refers to
_dl_get_tls_static_info@@GLIBC_PRIVATE
symbol and at least our rpm dependency stuff reject that, because nothing
outside of glibc should ever refer to symbols marked as GLIBC_PRIVATE.
Those are exported solely because they are used by other libraries that are
part of glibc (in this case libc.so.6).
If you need to get at the info it returns, please talk to
libc-al...@sourceware.org for help. The first line certainly must go, the
second alternative (dlsym) will not prevent installation, but may break
anytime, glibc doesn't guarantee anything about the ABI of the symbols, it
can be removed any time, can change parameters/return values without
warning.
Jakub
