DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:in-reply-to:subject:date:message-id
	:mime-version:content-transfer-encoding:content-type:references;
	 q=dns; s=default; b=tfNONxe9/jdiNUxR5/tcVEnD5Wzlwbc9kE220jSYM4w
	DULU/1PjK0v6myPP6hHUyHLyl7uHzvb1+eZhSyHw6mDVADt3I1IXPMbEYA2jdDBj
	tbZniYfaqF1uiHNZXaTjfzD8uT7RzGSIZsMf2ny8827eTk7TvuYtNwPcRXIcED7s
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: "Pavel Fedin" <p.fedin@samsung.com>
To: <Brian.Inglis@SystematicSw.ab.ca>, <cygwin@cygwin.com>
In-Reply-To:
Subject: RE: [BUG] try..catch does not work if compiled with clang 8.0
Date: Thu, 19 Dec 2019 17:19:54 +0300
Message-ID: <008d01d5b677$62ba07e0$282e17a0$@samsung.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <CGME20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858@eucas1p1.samsung.com>	<000701d5b4bd$42c086f0$c84194d0$@samsung.com>	<af3cb99f-f1cc-3bcc-9644-310c259eb222@SystematicSw.ab.ca>	<a9a62b50-688c-5747-266a-e7bb8157adbb@gmail.com>	<b46cefcb-144b-50f8-1f79-d2879b4e4c25@SystematicSw.ab.ca>	<016d01d5b5b5$47d6b8a0$d78429e0$@samsung.com>	<9f6fe40a-2dda-211f-57bc-d8b05413db4a@SystematicSw.ab.ca>
Content-Transfer-Encoding: 8bit

 Hello! I've done some more research on this particular bug.

> > > I have an impression that it has to do with the bug I previously reported
> > > (and someone here claimed he could reproduce it)
> >
> > Please provide a link to the Cygwin ML message; is it this, confirmed by Takashi
> > Yano:
> >
> > 	https://cygwin.com/ml/cygwin/2019-10/msg00038.html
> 
>  Yes, that one.

 So, first of all, _GCC_specific_handler() inside libgcc never returns anything but ExceptionContinueSearch . However it's clear from __cxa_throw() code that the control must go past RaiseException() in order to reach std::terminate(). Study of 32-bit version behavior with gdb confirms that indeed this is the expected control flow.
 So, i conclude that ExceptionContinueExecution should be issued somewhere else. Again, with gdb and grep i've figured out that exception::handle() inside cygwin1.dll is responsible for it. Here is where behavior significantly differs between 64 and 32-bit versions. With 32-bit version the exception handling ends here:
--- cut ---
#ifdef __i386__
  if (me.andreas)
    me.andreas->leave ();	/* Return from a "san" caught fault */
#endif
--- cut ---
 leave() never returns, the exception gets re-thrown a couple of times (every time ending up in this leave()), then RaiseException() eventually returns and std::terminate() is called.

 With x68-64 version it seems to go through switch (e->ExceptionCode) and return ExceptionContinueSearch from "default" case. There are no more handlers, so the process is terminated. ExceptionCode is 0x20474343 (" GCC" ?)
 Apparently there's something missing and/or not working regarding this "san Andreas" trick. I don't know what it is and have no time to research since i'm leaving for vacation till January.So won't be responsive for some time, sorry. Hopefully my study will give you some hints.


Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple