From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 16E5220248 for ; Mon, 11 Mar 2019 16:53:54 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=KGHH u5hlfIrprb4bmUiGH+TpnR+yxOTK6I/0ebCKV2RIfj0mO+UOU7lJBKxtMDnNgS6F 8abFZxFOJYIRKo/zqS784tqvVQDpvFzs2I9ugTJPgKhuP3a1K2cuVzWT1S65PX5n vZvsoeLgnZIuzpszAW8lBZ7kjNNvoiT3I8WdkaE= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=LPWBTbUUj+ aov6m93IT7FQaUHf8=; b=w17bxlYaJylbs2bdcrStAtBi3TViVVOeeO9EG3umbx gFh53EkY96phcAy5qE4xxjUKefH8PpWlThQS3VBQg6vL8AKvkLLPrel/1wv7r3mO zOI1uK/9Z31MbjvpuuNZuhBT2z0uKssvOj8csnHcANcH1S6NweStAByxqRaAMmo1 4= Received: (qmail 121139 invoked by alias); 11 Mar 2019 16:53:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 121059 invoked by uid 89); 11 Mar 2019 16:53:28 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mailbackend.panix.com MIME-Version: 1.0 References: <871s3lgtvu.fsf@oldenburg2.str.redhat.com> <7ad76477-c936-5db4-91be-c304ea322299@redhat.com> <8736ntxwe5.fsf@oldenburg2.str.redhat.com> <4f7706a4-b914-0ba5-84f6-352703a54e82@redhat.com> In-Reply-To: <4f7706a4-b914-0ba5-84f6-352703a54e82@redhat.com> From: Zack Weinberg Date: Mon, 11 Mar 2019 12:53:11 -0400 Message-ID: Subject: Re: Removing longjmp error handling from the dynamic loader To: "Carlos O'Donell" Cc: Florian Weimer , GNU C Library Content-Type: text/plain; charset="UTF-8" On Mon, Mar 11, 2019 at 12:13 PM Carlos O'Donell wrote: > On 3/11/19 11:29 AM, Florian Weimer wrote: > > It requires moving the unwinder implementation from libgcc_s to libc, > > though. The last time we discussed this (related to unwinder > > performance issues and the dl_iterate_phdr interface), this idea was not > > well-received. > > It might still be the best technical choice. > I do not think we should discard this idea so easily. > Why wouldn't we pursue this option? I haven't thought about this much, but I don't like the idea of increasing the set of functions potentially executed during symbol resolution to the tune of the entire unwinder, because of the unusual constraints on code executed in that context (e.g. must not take locks, must protect itself from cancellation, must not touch the normal errno). I was already thinking about saying that I supported Florian's original proposal just because it would mean *reducing* that set by at least setjmp and longjmp. zw