From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-110054-e=80x24.org@sourceware.org>
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.9 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,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL,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 19A671F619
	for <e@80x24.org>; Mon, 24 Feb 2020 20:10:24 +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:from:subject:to:cc:message-id:date
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=BOHIO79GhjSA2cJmIhIRYYrDf0x2QT/+EIgCR+IUbCOZy30/gOeOT
	gH+69XDW+Mj+v6x5aubiyG7Jr0hR6jLuojppGZ6VdRFzCp1EGY+2KnkLMDJwDFfA
	34/fcwl+/8CBNzi+7nGTsdIKeEedcrxhratruJ88GRFwNEJR1kg9cA=
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:subject:to:cc:message-id:date
	:mime-version:content-type:content-transfer-encoding; s=default;
	 bh=L1U0irnGrGq1BsatKrkkOBRVPyA=; b=H3cm0LfEF+sz1RuU2Q5ZH2OFcSeY
	OChl8o0df+bm9mYeks2whuujm6vifQQvSJ8XNHU3sT8/t0MJIkrm++IqzOy06byA
	YAe+F2j81qoByBf/9nD3EbxaaAmjwf5fC043CJfvMjKpBWh2Kk/T8izjC0mJQutV
	iJZWUZGSbItmMUY=
Received: (qmail 47529 invoked by alias); 24 Feb 2020 20:10:21 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Unsubscribe: <mailto:libc-alpha-unsubscribe-e=80x24.org@sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 47519 invoked by uid 89); 24 Feb 2020 20:10:20 -0000
Authentication-Results: sourceware.org; auth=none
X-HELO: mx0a-001b2d01.pphosted.com
From: Paul E Murphy <murphyp@linux.ibm.com>
Subject: long double redirects and dynamic loader behavior
To: GNU C Library <libc-alpha@sourceware.org>
Cc: carlos@redhat.com, Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Message-ID: <4602467a-2114-34d5-4f99-bf5ac4ef3d6d@linux.ibm.com>
Date: Mon, 24 Feb 2020 14:10:15 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Tulio mentioned that he and Carlos discussed this topic during Cauldron 
last year.

As far as I understand it, dlopen becomes problematic when loading code 
compiled against an unknown long double ABI.  My understanding is the 
gnu-attribute exists to help catch those cases at link time.  I am 
unsure how, or if it does anything to assist dynamically loaded libraries.

dlsym is more tricky.  The redirects obfuscate the naming of many common 
symbols.  I.e dlsym(...,"printf") might give you something which almost 
works, but is broken.

What is the current thinking regarding the behavior of these features 
when redirects are used?