delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2019/12/19/09:21:01

X-Recipient: archive-cygwin AT delorie DOT com
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
=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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;
s=default; bh=V1g0/IoWHhD6xN1i7y1DAzff3NQ=; b=Ql2gNvlcVzoni3f78
bafyDOyadSv3y+5Px7GWIl5oI2ropxxUXCEfSKr2f5jvtiGmJ0NvgcgrtoZ1faPk
v9wN2Wo/Ub9qPLmCke6WVFL0s/urSyezNZlS/+/woUxAQ7NEyT9OzufUf4R3hPvH
EJ44lZE9meGEG5v0HpwaEj9s1M=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=study, H*UA:Outlook, H*x:Outlook, H*UA:Microsoft
X-HELO: mailout1.w1.samsung.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20191219141955euoutp01f74b99ce1da08d2f1f9d0106c4c67be4~hy5dlcf6c0807408074euoutp01p
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1576765195; bh=iJfMnh8klU4ORmmwmcrmiw7oeoCA9Kri61IapvGExgE=; h=From:To:In-Reply-To:Subject:Date:References:From; b=ievUAv08RmBWfJZcto2AjkM2CR7+LYnj39EBm75OmNDjWqA0k6pkaampRAPzUFUxL Ug8TXRpWDgUxw50Kt9q4V7M9IkFwM6FSrWsry3mjTn4gifQw+oc54D2yfSNlN4+jnx CyYBcsF4jG1xwGML4r0B3X8Wg+PgBz9zMAuZYg2s=
From: "Pavel Fedin" <p DOT fedin AT samsung DOT com>
To: <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>, <cygwin AT cygwin DOT 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
X-CMS-MailID: 20191219141955eucas1p229190a47d1eef92d2d2a69bc505fd1c5
X-Msg-Generator: CA
X-RootMTR: 20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858
X-EPHeader: CA
CMS-TYPE: 201P
X-CMS-RootMailID: 20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858
References: <CGME20191217093504eucas1p14cced4e1f9fcec50e44e9223d1761858 AT eucas1p1 DOT samsung DOT com> <000701d5b4bd$42c086f0$c84194d0$@samsung.com> <af3cb99f-f1cc-3bcc-9644-310c259eb222 AT SystematicSw DOT ab DOT ca> <a9a62b50-688c-5747-266a-e7bb8157adbb AT gmail DOT com> <b46cefcb-144b-50f8-1f79-d2879b4e4c25 AT SystematicSw DOT ab DOT ca> <016d01d5b5b5$47d6b8a0$d78429e0$@samsung.com> <9f6fe40a-2dda-211f-57bc-d8b05413db4a AT SystematicSw DOT ab DOT ca>
X-IsSubscribed: yes
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id xBJEKaNX004691

 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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019