From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dje.gcc@gmail.com>
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [IPv6:2a00:1450:4864:20::32f])
 by sourceware.org (Postfix) with ESMTPS id A5A6538930E1
 for <gcc@gcc.gnu.org>; Mon, 11 May 2020 14:36:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A5A6538930E1
Received: by mail-wm1-x32f.google.com with SMTP id u16so19538431wmc.5
 for <gcc@gcc.gnu.org>; Mon, 11 May 2020 07:36:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=+k1wQzf0YtF1qUgbFAWTxTRTGn99hgNX8by1pOXW7A0=;
 b=gBbC+wAhvoNwi/iIZFYZ8IWTmCSPA5UjqDCZpD4Te0H6dETznAul2NZ7SEwvnEFmuG
 24a0PDmGQetr5N+hotPQd5k1wlMSIT/82LZCTLU974OX1I5YFZ5wmzL2PLikU6NMGj9L
 O7pyFcIhnE9Ym+l0HrWms3my4NjK2+T4tkVuWGB25FCxwBA5Z3La9XusQCDYTFjiypPI
 dzwjJvZKB8HnRgd8TUKdqpkJ3PxcvLDYRC6gsplMDGGeRLv4xlg2eLQn6O5OG6LrTYMP
 04xgQx7ZPzTGZqzImPmeydDwrolqpu3UczXb3/pJcpsZNtTM2EevDyZmKbWFVhFRrRYh
 Avng==
X-Gm-Message-State: AGi0PuZrpm6fPOIp2hkiXtt4SbhiHZ2+p5xD5gkSzwyX6BWdcuuBNqcB
 K+OrfEMqP5RCNg1Wqe2i+7KJ/H3v1iw54ZdP0vY=
X-Google-Smtp-Source: APiQypKqR2txBByPeexo/6PKp0QE8WgGt2wc9bRRRaKiSpGA9rBEo9tv/7f/00rNxbqjVipVqnwShZavCeOleuIqeyU=
X-Received: by 2002:a1c:9604:: with SMTP id y4mr30039222wmd.153.1589207803670; 
 Mon, 11 May 2020 07:36:43 -0700 (PDT)
MIME-Version: 1.0
References: <0bbdaab7-c083-e14e-6227-27713dab9657@users.sourceforge.net>
 <874ksmg3fb.fsf@oldenburg2.str.redhat.com>
In-Reply-To: <874ksmg3fb.fsf@oldenburg2.str.redhat.com>
From: David Edelsohn <dje.gcc@gmail.com>
Date: Mon, 11 May 2020 10:36:32 -0400
Message-ID: <CAGWvnynP2gji-XBVY9=LHWR_5wTp6eXGQsxCRSLU9pzCJM8LZA@mail.gmail.com>
Subject: Re: performance of exception handling
To: Florian Weimer <fweimer@redhat.com>
Cc: Thomas Neumann via Gcc <gcc@gcc.gnu.org>,
 Thomas Neumann <tneumann@users.sourceforge.net>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 14:36:52 -0000

On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:

> My current preferred solution is something that moves the entire code
> that locates the relevant FDE table into glibc.  This is all the code in
> _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base
> call.  And the callback mechanism would be gone, so _Unwind_Find_FDE
> would call __dl_ehframe_find (see below) and then the reamining
> processing in _Unwind_IteratePhdrCallback.

Not all GCC/G++ targets are GNU/Linux and use GLIBC.  A duplicate
implementation in GLIBC creates its own set of advantages and
disadvantages.

Thanks, David