Always defined __SEH__ when build from trunk
Hi!
When I try to build gcc from trunk with mingw-w64 I successfully build
only 64bit with seh exceptions. Other builds stop on error
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:238:1:
warning: no previous prototype for '__gcc_personality_seh0'
[-Wmissing-prototypes]
__gcc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame,
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: In
function '__gcc_personality_seh0':
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:242:14:
error: '__gcc_personality_imp' undeclared (first use in this function)
ms_disp, __gcc_personality_imp);
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:242:14:
note: each undeclared identifier is reported only once for each
function it appears in
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: At top level:
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:94:33:
warning: '__gcc_personality_sj0' defined but not used
[-Wunused-function]
#define PERSONALITY_FUNCTION__gcc_personality_sj0
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:120:1:
note: in expansion of macro 'PERSONALITY_FUNCTION'
PERSONALITY_FUNCTION (int version,
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: In
function '__gcc_personality_seh0':
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:243:1:
warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[4]: *** [unwind-c.o] Error 1
make[4]: *** Waiting for unfinished jobs
I find that __SEH__ defined in gcc/config/i386/cygming.h as
.
#undef TARGET_SEH
#define TARGET_SEH (TARGET_64BIT_MS_ABI && flag_unwind_tables)
#define TARGET_OS_CPP_BUILTINS() \
do \
{ \
if (!TARGET_64BIT) \
builtin_define ("_X86_=1"); \
if (TARGET_SEH) \
builtin_define ("__SEH__");
.
As I think __SEH__ is always defined that leads to error.
Re: Always defined __SEH__ when build from trunk
Hi, the cause for this is that SEH exceptions are only present for x64 64-bit target. There is no such support for 32-bit (mainly caused by patent issues). Therefore if you want to build multilib for mingw, then please switch back to SjLj-exception mechanism. Regards, Kai
Re: Always defined __SEH__ when build from trunk
My configure line is: $ /temp/mingw-sources/gcc-trunk/gcc/configure --cache-file=./config.cache --prefix=/temp/x32-trunk-snapshot-posix-sjlj-rev1/prefix --with-sysroot=/temp/x32-trunk-snapshot-posix-sjlj-rev1/prefix --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-cloog-backend=isl --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-ppl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-tune=generic --with-host-libstdcxx=-static -lstdc++ --with-libiconv --with-gmp=/temp/mingw-prereq/i686-w64-mingw32-static --with-mpfr=/temp/mingw-prereq/i686-w64-mingw32-static --with-mpc=/temp/mingw-prereq/i686-w64-mingw32-static --with-ppl=/temp/mingw-prereq/i686-w64-mingw32-static --with-cloog=/temp/mingw-prereq/i686-w64-mingw32-static --with-pkgversion=Built by MinGW-builds project --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ --enable-languages=c,c++,fortran,lto --program-transform-name=s,y,y, --disable-option-checking --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --srcdir=../../../../mingw-sources/gcc-trunk/gcc If you need I can send you full logs 2012/11/22 Kai Tietz : > Hi, > > the cause for this is that SEH exceptions are only present for x64 > 64-bit target. There is no such support for 32-bit (mainly caused by > patent issues). Therefore if you want to build multilib for mingw, > then please switch back to SjLj-exception mechanism. > > Regards, > Kai
Re: -fPIC -fPIE
On 21/11/12 22:47, Ian Lance Taylor wrote: On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini wrote: On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor wrote: The main advantage is that you can compile a program with CFLAGS="-O2 -g -fPIE", and libtool's adding of -fPIC for shared libraries will work reliably. If -fPIE can still override -fPIC, the result depends on whether -fPIC comes before or after CFLAGS. ...which is exactly how all our other options work. The last one wins. Why should these be different? Most other options are not added by the build system automatically with the presumption that they always override the default. I don't think that GCC can predict what various different build systems are going to do. Using -fPIE in CFLAGS for libtool seems like a very specific use case It's actually a very common use case for distributions that want to harden some binaries. Well, OK. I could actually give you the reverse argument--I ran into this working with Google's internal build system, where it was a problem--but it doesn't really matter. My view is this: we have a simple rule for options that is very easy to understand. We should only deviate from that rule for exceptional reasons. The fact that libtool acts a certain way is not an exceptional reason; libtool can change behaviour easily enough, and that change will be backward compatible. Note that even before my patch, gcc -fpic -fpie was equivalent to -fpie. What changed is that previously gcc -fpie -fpic was also equivalent to -fpie. So if you were adding -fpie to CFLAGS, and libtool was not aware of that, the result was that when libtool expected -fpic it was actually getting -fpie. I don't see how that could be correct anyhow. Ian I guess I've always seen these flags as controlling a pair of bits: 1st bit -- controls how addressing is done 2nd bit -- controls pre-emption rules -fpie only sets the first bit (but has no effect on the second) -fpic sets both bits. And there are no options to clear any of the bits. If you're going to treat them as a part of a 3-state enumeration (standard, pic, pie) of compilation modes, then you're missing an option -- namely one to restore the state to standard (not pic or pie). R.
Re: Always defined __SEH__ when build from trunk
2012/11/22 Kai Tietz: > Hi, > > the cause for this is that SEH exceptions are only present for x64 > 64-bit target. There is no such support for 32-bit (mainly caused by > patent issues). Therefore if you want to build multilib for mingw, > then please switch back to SjLj-exception mechanism. I once asked a similar question, but didn't understand, whether sjlj use will be available for 4.8? -- Regards, niXman ___ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: Always defined __SEH__ when build from trunk
2012/11/22 niXman: > I once asked a similar question, but didn't understand, whether sjlj > use will be available for 4.8? Because I a few months can not build trunk with sjlj successfully. I wrote about this in the gcc-help mailing list, I think twice. -- Regards, niXman ___ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: -fPIC -fPIE
Richard Earnshaw writes: > -- namely one to restore the state to standard (not pic or pie). -fno-pic -fno-pie Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Always defined __SEH__ when build from trunk
2012/11/22 niXman : > 2012/11/22 niXman: >> I once asked a similar question, but didn't understand, whether sjlj >> use will be available for 4.8? > > Because I a few months can not build trunk with sjlj successfully. > I wrote about this in the gcc-help mailing list, I think twice. Well, __SEH__ is defined for x64 in any case. There is no way to have for x64 no SEH-support - at least not in a way it would work in a general way, as SEH is part of the ABI of x64. Question is here why boostrap fails for multilib 32-bit, if SJLJ is demanded. I am about to setup a build for testing this. Regards, Kai
Re: Always defined __SEH__ when build from trunk
2012/11/22 Kai Tietz: > Well, __SEH__ is defined for x64 in any case. There is no way to have > for x64 no SEH-support - at least not in a way it would work in a > general way, as SEH is part of the ABI of x64. I.e. SJLJ can't be used for 4.8(and later)-x86_64? > I am about to setup a build for testing this. Thanks in advance. -- Regards, niXman ___ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: Always defined __SEH__ when build from trunk
With 64bit multilib toolchain is the same situation as with 32bit multilib toolchain
Re: Always defined __SEH__ when build from trunk
2012/11/22 niXman : > 2012/11/22 Kai Tietz: >> Well, __SEH__ is defined for x64 in any case. There is no way to have >> for x64 no SEH-support - at least not in a way it would work in a >> general way, as SEH is part of the ABI of x64. > I.e. SJLJ can't be used for 4.8(and later)-x86_64? > >> I am about to setup a build for testing this. > Thanks in advance. > > > -- > Regards, > niXman So, I think I found the issue about SEH and SJLJ ... it is reasoned by the fact that __SEH__ is used in libgcc's unwinder, but it didn't checked if SJLJ should be used. The following patch should solve this issue. Could you give it a try? Regards, Kai Index: unwind-c.c === --- unwind-c.c (Revision 193669) +++ unwind-c.c (Arbeitskopie) @@ -109,7 +109,7 @@ struct _Unwind_Exception * ue_header, struct _Unwind_Context * context) #else -#ifdef __SEH__ +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) static #endif _Unwind_Reason_Code @@ -233,7 +233,7 @@ return _URC_INSTALL_CONTEXT; } -#ifdef __SEH__ +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) EXCEPTION_DISPOSITION __gcc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame, PCONTEXT ms_orig_context, PDISPATCHER_CONTEXT ms_disp) Index: unwind-generic.h === --- unwind-generic.h(Revision 193669) +++ unwind-generic.h(Arbeitskopie) @@ -28,7 +28,7 @@ #ifndef _UNWIND_H #define _UNWIND_H -#ifdef __SEH__ +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) /* Only for _GCC_specific_handler. */ #include #endif @@ -275,7 +275,7 @@ # error "What type shall we use for _sleb128_t?" #endif -#ifdef __SEH__ +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) /* Handles the mapping from SEH to GCC interfaces. */ EXCEPTION_DISPOSITION _GCC_specific_handler (PEXCEPTION_RECORD, void *, PCONTEXT, PDISPATCHER_CONTEXT, Index: unwind-seh.c === --- unwind-seh.c(Revision 193669) +++ unwind-seh.c(Arbeitskopie) @@ -28,7 +28,7 @@ #include "tm.h" #include "unwind.h" -#ifdef __SEH__ +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) /* At the moment everything is written for x64, but in theory this could also be used for i386, arm, mips and other extant embedded Windows. */ @@ -480,4 +480,4 @@ return _URC_END_OF_STACK; #endif } -#endif /* __SEH__ */ +#endif /* __SEH__ && !defined (__USING_SJLJ_EXCEPTIONS__) */
Re: Always defined __SEH__ when build from trunk
Ok I try it now. 2012/11/22 Kai Tietz : > 2012/11/22 niXman : >> 2012/11/22 Kai Tietz: >>> Well, __SEH__ is defined for x64 in any case. There is no way to have >>> for x64 no SEH-support - at least not in a way it would work in a >>> general way, as SEH is part of the ABI of x64. >> I.e. SJLJ can't be used for 4.8(and later)-x86_64? >> >>> I am about to setup a build for testing this. >> Thanks in advance. >> >> >> -- >> Regards, >> niXman > > So, I think I found the issue about SEH and SJLJ ... it is reasoned by > the fact that __SEH__ is used in libgcc's unwinder, but it didn't > checked if SJLJ should be used. > The following patch should solve this issue. Could you give it a try? > > Regards, > Kai > > Index: unwind-c.c > === > --- unwind-c.c (Revision 193669) > +++ unwind-c.c (Arbeitskopie) > @@ -109,7 +109,7 @@ > struct _Unwind_Exception * ue_header, > struct _Unwind_Context * context) > #else > -#ifdef __SEH__ > +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > static > #endif > _Unwind_Reason_Code > @@ -233,7 +233,7 @@ >return _URC_INSTALL_CONTEXT; > } > > -#ifdef __SEH__ > +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > EXCEPTION_DISPOSITION > __gcc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame, > PCONTEXT ms_orig_context, PDISPATCHER_CONTEXT ms_disp) > Index: unwind-generic.h > === > --- unwind-generic.h(Revision 193669) > +++ unwind-generic.h(Arbeitskopie) > @@ -28,7 +28,7 @@ > #ifndef _UNWIND_H > #define _UNWIND_H > > -#ifdef __SEH__ > +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > /* Only for _GCC_specific_handler. */ > #include > #endif > @@ -275,7 +275,7 @@ > # error "What type shall we use for _sleb128_t?" > #endif > > -#ifdef __SEH__ > +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > /* Handles the mapping from SEH to GCC interfaces. */ > EXCEPTION_DISPOSITION _GCC_specific_handler (PEXCEPTION_RECORD, void *, > PCONTEXT, PDISPATCHER_CONTEXT, > Index: unwind-seh.c > === > --- unwind-seh.c(Revision 193669) > +++ unwind-seh.c(Arbeitskopie) > @@ -28,7 +28,7 @@ > #include "tm.h" > #include "unwind.h" > > -#ifdef __SEH__ > +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) > > /* At the moment everything is written for x64, but in theory this could > also be used for i386, arm, mips and other extant embedded Windows. */ > @@ -480,4 +480,4 @@ >return _URC_END_OF_STACK; > #endif > } > -#endif /* __SEH__ */ > +#endif /* __SEH__ && !defined (__USING_SJLJ_EXCEPTIONS__) */
Hash table iterators.
I have found that tree-flow.h implements iteration over htab_t, while there is no current facility to do that with hash_table. Unfortunately, the specific form does not match the standard C++ approach to iterators. We have several choices. (1) Ignore the problem and leave all such tables as htab_t. (2) Write new hash_table iteration functions to match the form of the existing GCC macro/function approach. (3) Write new hash_table iteration functions to match the form used by the C++ standard. This approach would entail modifying the loops. Diego and I have a preference for (3). What do you prefer? -- Lawrence Crowl
Re: Hash table iterators.
On Thu, Nov 22, 2012 at 12:18 PM, Lawrence Crowl wrote: > I have found that tree-flow.h implements iteration over htab_t, > while there is no current facility to do that with hash_table. > Unfortunately, the specific form does not match the standard C++ > approach to iterators. We have several choices. > > (1) Ignore the problem and leave all such tables as htab_t. > > (2) Write new hash_table iteration functions to match the form of > the existing GCC macro/function approach. > > (3) Write new hash_table iteration functions to match the form used > by the C++ standard. This approach would entail modifying the loops. > > Diego and I have a preference for (3). What do you prefer? We have to look for the long term shape of the source code. From that perspective, the choice is simple: (3). -- Gaby
Re: RFC - Alternatives to gengtype
On 11/18/2012 07:06 PM, NightStrike wrote: What's wrong with std::shared_ptr? The pointer needs two words, and the per-object overhead for the reference counts etc. is four words, if I'm counting correctly. (Other forms of reference counting have less overhead, of course, but you were asking about std::shared_ptr.) -- Florian Weimer / Red Hat Product Security Team
Re: RFC - Alternatives to gengtype
On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
> On 11/18/2012 07:06 PM, NightStrike wrote:
>
> >What's wrong with std::shared_ptr?
>
> The pointer needs two words, and the per-object overhead for the
> reference counts etc. is four words, if I'm counting correctly.
>
> (Other forms of reference counting have less overhead, of course,
> but you were asking about std::shared_ptr.)
Actually, this observation may favor a real garbage collector. Marking GC as
simple as ggc+gengtype usually have one (or a few) mark bits, so can consume
only a few bits (or perhaps a byte in some mark array) per object. Copying GC
could avoid consuming any more storage per object. Of course useless object may
stay in memory for a while -until the GC deletes them or reuse their memory-
but that observation is also true with traditional C++ "GC" techniques like
shared_ptr An object may be freed later than what should be possible.
And some GC techniques are quite friendly with L1 or L2 caches on the processor
chip.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
