From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103090 invoked by alias); 28 Mar 2018 01:39:41 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 102088 invoked by uid 89); 28 Mar 2018 01:39:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=slots, Audit X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 01:39:38 +0000 Received: by mail-wm0-f41.google.com with SMTP id r82so2132878wme.0 for ; Tue, 27 Mar 2018 18:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9a9AwHJFMngbwIwmaLZr2p2lCJOCq/jqZYMm0QIBmk8=; b=MypWoF4B3DVvikOmLGlnCr8Rmt0ImWYZ9MAoO/cz37W+Jofz20/YdXi0TqaP0dkh/6 t1LsiOT2TQT6R1LdbwXuhe86zrVITspLCADFjZRKgkFsCAh3AZ0hzWiA2GGYxGOY7xFw 7jqq9aBltgxxeXZvUc6//YpsfQ8QKJJXsMdLpsDYfO10IT8eu8q9Th3voQqZX0KqvD+u Mq/xLSW/yx43eAfeDx+SbtHXCuK2c6+Mu8pFeypoIii1Z2bhvcJi3Yte047vSDvcXONO izN9516oAeTNJ6ni5MEp+L3wXs/zT5HoR0tyCVI32uhl95A0kTNxXrkQQmWTydXMSGSo Ywpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9a9AwHJFMngbwIwmaLZr2p2lCJOCq/jqZYMm0QIBmk8=; b=D9rD3rQA7PVcRDoTHZb3ViuxGD7NGft3rQCDrnUkKHLZbhegUOMh2vFqfJvpaLXhXq STvAb67aAvpSM+SUNogym2V5vn2I2xe5qEdFuRZVSgK61NwuYRTWj8dqcgl8xwo9rEi5 HiBlcCupK8yIKS/G7iSbTraxiwsgDi6Hc3cDLXgz4zgflDeX2bNnKSmtNBVrfmL4gihx r2Bcn3NSFASQQrxWUVhj+s7NN02+AziQn4pUWfU3xEyJMVSdATdiBdC9OOWaLdMPdogV RNYqt0trAGK+7Q7I4TZibjqc1gZ4dLM2pFv2TpecaaGsEy1KvQJ28h+rPy7WKAXzhEZ7 aKFg== X-Gm-Message-State: AElRT7HmJL3/yII9FqL0zvxMPq+5yuIGNPQN+SuhWmLyMGci8iQB2OpV cW09e+/Jz7KhJVXIJWxqgaPPjbNOfy6OYyGbIds= X-Google-Smtp-Source: AIpwx49rBFfV7RWPTkuOKrff9YoDWv0AcRl12yIAZf+w+lsa3mQK/PLgHLWyRZvDMLDcUbdVoBn0qT92aMngZLr31Z0= X-Received: by 10.28.144.196 with SMTP id s187mr997732wmd.82.1522201175350; Tue, 27 Mar 2018 18:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.146 with HTTP; Tue, 27 Mar 2018 18:39:34 -0700 (PDT) In-Reply-To: References: <20180317133115.GA4681@gmail.com> <87370txhr1.fsf@mid.deneb.enyo.de> <3a203b82-1247-5538-4848-92c9227cc77e@redhat.com> <87po3wo589.fsf@mid.deneb.enyo.de> <76f5551d-e8dc-4915-e3d8-54a2305a5718@redhat.com> From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Audit external function called indirectly via GOT To: "H.J. Lu" Cc: Generic System V Application Binary Interface , Florian Weimer , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00028.txt.bz2 I haven't seen a response yet to the primary point I was trying to make: > My suggestion was that the GOT entry could be statically initialized > by the linker to point to the provisional PLT entry, rather than > forcing the dynamic loader to go through all this messy computation. > If auditing is not enabled, it would process the GLOB_DAT relocation > normally, and set the GOT entry to point to the actual function, > bypassing the provisional PLT and PLTGOT entries completely. If > auditing is enabled, it could simply ignore the GLOB_DAT relocation > (or, if the binary is PIE, it could process it as a RELATIVE > relocation), and the -fno-plt calls will end up jumping to the > provisional PLT entry. > > (This is already how we handle the PLTGOT entries: the linker > statically initializes the entries to point to part (b)* of the PLT > entry, while putting JUMP_SLOT relocations for those entries into the > JMPREL table.) > > I think if you do that, none of these extra dynamic table entries will > be needed, ... ... or this secondary point: > ... except for the IGNORE_JMPREL flag that indicates there are > no JMPREL slots other than those for the provisional PLT entries. How > useful is that flag? If the final program has even one external call > that was *not* compiled with -fno-plt, you won't be able to set it. > Would it be better to partition the JMPREL and PLT tables into > "regular" and "provisional" entries? That would take just a single new > DT_PROVISIONAL_JMPREL entry to tell the dynamic loader where the > JMPREL entries for the provisional PLT entries begin; it can ignore > everything past that point when auditing is turned off. -cary