Non-call-exceptions, unwinding and g++ optimization levels
Good day,
I'm working with exceptions thrown by a signal handler using
-fnon-call-exceptions flag with g++ for x86_64.
The problem I am facing is that the behavior of this mechanism is not
consistent if we change some optimization options, that is, the result
of a given program can be different. In order to make a comparison, I
ran this test several times, each with different optimizations
enabled.
Compilation either with -O0 or without any flags (just -fnon-call-exceptions):
Exception is caught at the "copy" function (the one which calls
std::copy). This is the expected behavior.
Compilation using -O1 -O2 or -O3 flag directly:
Exception is not being caught.
If both -fno-inline and -fno-ipa-pure-const are used, then the program
behaves as if -O0 is used. Thus, I tried to add
__attribute__((noinline)) to both "foo" and "copy" functions. It seems
that they were ignored because the problem doesn't dissapear when
-fno-inline is not used.
In my opinion, it seems that catch blocks are being optimized out or
that, because of the inlining, the generated code is not able to find
any catch blocks inside its scope.
I could reproduce this with g++ versions 4.7.3, 4.8.1 and the latest
in the public, read-only, git. The file used to test this is attached
to the message. Compile command used is:
g++ -fnon-call-exceptions [-fno-inline -fno-ipa-pure-const] -O{0,1,2,3}
Regards,
Jorge
#include
#include
#include
#include
#include
#include
#include
/*
* This program tries to check how exceptions unwind
* when they are thrown inside a signal handler
* (using -fnon-call-exceptions code generation flag)
*/
typedef void* ptr_t;
void copy( ptr_t from, ptr_t to, size_t size )
{
try {
char *beg = (char*)from;
char *end = (char*)from + size;
char *dst = (char*)to;
std::copy(beg, end, dst);
} catch (std::exception &e) {
std::cout << "Caught in copy function" << std::endl;
}
}
void taskErrorHandler ( int sig, siginfo_t* si, void *context )
{
throw std::runtime_error("I've found an error!");
}
void foo(int *from, int *to, size_t length)
{
try {
copy((ptr_t)from, (ptr_t)to, length);
} catch (std::exception &e) {
std::cout << "Caught in foo function" << std::endl;
}
}
int main() {
// Installs a signal handler for SIGSEGV signals
struct sigaction recovery_action;
recovery_action.sa_sigaction = &taskErrorHandler;
sigemptyset(&recovery_action.sa_mask);
recovery_action.sa_flags = SA_SIGINFO;
sigaction(SIGSEGV, &recovery_action, NULL);
size_t memsize = 4096;
int *from, *to;
// Allocates two portions of memory aligned to a memory page.
assert( posix_memalign( (ptr_t*) &from, 4096, memsize) == 0 );
assert( posix_memalign( (ptr_t*) &to, 4096, memsize) == 0 );
mprotect( from, memsize, PROT_NONE);// Block access to the source allocation
try {
foo(from, to, memsize);
} catch (std::exception &e) {
std::cout << "Caught in main function" << std::endl;
}
return 0;
}
Re: Non-call-exceptions, unwinding and g++ optimization levels
On Wed, Jan 21, 2015 at 12:13 PM, Jorge Bellón Castro
wrote:
> Good day,
> I'm working with exceptions thrown by a signal handler using
> -fnon-call-exceptions flag with g++ for x86_64.
>
> The problem I am facing is that the behavior of this mechanism is not
> consistent if we change some optimization options, that is, the result
> of a given program can be different. In order to make a comparison, I
> ran this test several times, each with different optimizations
> enabled.
>
> Compilation either with -O0 or without any flags (just -fnon-call-exceptions):
> Exception is caught at the "copy" function (the one which calls
> std::copy). This is the expected behavior.
>
> Compilation using -O1 -O2 or -O3 flag directly:
> Exception is not being caught.
>
> If both -fno-inline and -fno-ipa-pure-const are used, then the program
> behaves as if -O0 is used. Thus, I tried to add
> __attribute__((noinline)) to both "foo" and "copy" functions. It seems
> that they were ignored because the problem doesn't dissapear when
> -fno-inline is not used.
>
> In my opinion, it seems that catch blocks are being optimized out or
> that, because of the inlining, the generated code is not able to find
> any catch blocks inside its scope.
>
> I could reproduce this with g++ versions 4.7.3, 4.8.1 and the latest
> in the public, read-only, git. The file used to test this is attached
> to the message. Compile command used is:
>g++ -fnon-call-exceptions [-fno-inline -fno-ipa-pure-const] -O{0,1,2,3}
Please open a bugreport.
Thanks,
Richard.
> Regards,
> Jorge
gcc-4.9-20150121 is now available
Snapshot gcc-4.9-20150121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150121/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 219975 You'll find: gcc-4.9-20150121.tar.bz2 Complete GCC MD5=306a53f0ff3b4ece5ae2b59316928a82 SHA1=8942804bee81ee468176d3f71a47b02d78d3328e Diffs from 4.9-20150114 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: [ping] Re: proper name of i386/x86-64/etc targets
On Tue, Jan 20, 2015 at 11:43 AM, H.J. Lu wrote: > On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore > wrote: >> On 01/20/2015 12:21 PM, H.J. Lu wrote: >>> >>> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore >>> wrote: Ummm, this seems like an inconsistent position. "32-bit x86" isn't even a new name; it's a restricting adjective "32-bit" on the existing name "x86". But "x86-32" isn't an existing real name for anything, as far as I can tell. >>> "x86-32" is mentioned in >>> >>> http://www.lyberty.com/tech/terms/x86_WHAT-IS_.html >>> http://superuser.com/questions/186503/is-x86-32-bit-or-64-bit >>> https://forums.digitalpoint.com/threads/what-does-x64-and-x86-mean.674631/ >> >> >> I wouldn't consider random blog or forum postings to be reliable sources. >> Can you cite manufacturer/vendor literature, technical reports, or news >> articles using that term? >> >> FWIW, when I'm reviewing BSPs and associated documentation for >> Mentor's own products, I always check the manufacturer's web site and verify >> that we use the name exactly as it appears in their own marketing literature >> and/or data sheets. Wikipedia's standards for naming are a little >> different they prefer to use the most common and familiar name for >> things. > > I checked with my colleagues at Intel. x86-32 is somtimes used to refer > 32-bit processors from Intel and AMD. > > When you can do # git log --grep="x86-32" in Linux kernel source tree, you will find out x86-32 is used to refer 32-bit x86. -- H.J.
