From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7223 invoked by alias); 29 Sep 2002 22:41:59 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 7207 invoked from network); 29 Sep 2002 22:41:59 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.160.54.138) by sources.redhat.com with SMTP; 29 Sep 2002 22:41:59 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 29507357E; Sun, 29 Sep 2002 15:35:58 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id g8TMZx420266; Sun, 29 Sep 2002 15:35:59 -0700 Date: Sun, 29 Sep 2002 15:41:00 -0000 Message-Id: <200209292235.g8TMZx420266@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: GNU libc hackers Subject: ld.so needs __errno_location PLT entry? X-windows: ignorance is our most important resource. X-SW-Source: 2002-09/txt/msg00102.txt.bz2 Unless I am missing something, I think ld.so needs to have a PLT entry for __errno_location. This bites fatally on Hurd, where the implementations of read et al must come from libc.so and so the real errno must be found by ld.so's calls to see any values at all. On Linux with PLT reduction it never matters to communicate an errno value between libc and ld.so, so always getting ld.so's private errno cell is fine most of the time. But there is only one private cell, so ld.so's uses of it are not thread-safe. I am not positive off hand that every possible access to errno inside ld.so happens with _dl_load_lock held. If so, then it's ok. But that is certainly a subtlety that requires some comments somewhere.