From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56706 invoked by alias); 28 Mar 2018 04:11:35 -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 56694 invoked by uid 89); 28 Mar 2018 04:11:34 -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= 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-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 04:11:32 +0000 Received: by mail-wm0-f52.google.com with SMTP id p9so2277904wmc.3 for ; Tue, 27 Mar 2018 21:11:32 -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=dJFswuuQKwxG+4Ao4p11cyKngR293v7sgzLrAFtVrpY=; b=ucy9NIdZ10eesr+P++HdP5jkOnF83d9iGXjXdsYaQ21URGg+b06QKCpiHc9mBG+oRo u/CauPRhAWoQK+Zx3kFf9pKGhdtzQsvRdq+eHqcgWHKFyJq/CdSM3G1yQXPPVXQ8hA6R ImO/yrOJ5ji9dcYm7ir0KbJWMXlmaC2a0JlVNmbxfIo8ZXFcL48TxWm/pJH2LM/P20jJ 3E0nfZZ7lef+mWyXz1Dc2GBBOM+i4ajCuYLCI5OkzUOip+RLGCVtBKtXp7bzA0BNQ0yJ I+9NZ+JXWGzM07YVsjtCmyGR30VCQ0duo6CxeErggO+akLP2KV2D/q05hgzpOdn1aCJz 7WNA== 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=dJFswuuQKwxG+4Ao4p11cyKngR293v7sgzLrAFtVrpY=; b=QipGafjymI0J+Oa4aHqbzYra6I0rV0zKs10Sv2/V4C1DHlkHaW2CeVdc+oDQ7NupTH If+6Zkam8psKlxmCwjosNkMhOTkgbo+6Yvad/OijGZ5fVgfpQhBKW+jmT3xxFT/uRCGZ iImNlvvqlDEmbFXBmBEdiR6W9wH28Vj0XemXyGrD8AoJ2VuWBHXrPyWRdTSSbVVKV3PO 8lVM8wwNGOgViG3HdA93IempdgrHN3E5zLsameuBUQZQuyDV1NYiSSysHsjQKn8ocKIn DpgVcvKXN8SILFTCgv04x3jSuBtu8EADQ8nrrQLexdSZtGLSSMkm+LAWKvwyA2OjrHzx L7mg== X-Gm-Message-State: AElRT7FqFNF5fiaQYr0IRzDK80FRrx89G8DTGP9up7wqsJnWIL9PuJLP R6UHPiIr3KXAdKn0V6454vMGoM47qV65D04qwiA= X-Google-Smtp-Source: AIpwx48h5ytkj6HaufoenMXWhYc3ACfC3z7hOWnpDIuEPUWnyMEOEVtbOKZ2bC565ewPHZyYbt1gG4juftHImrIehGs= X-Received: by 10.28.9.68 with SMTP id 65mr1240692wmj.29.1522210290710; Tue, 27 Mar 2018 21:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.146 with HTTP; Tue, 27 Mar 2018 21:11:30 -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/msg00030.txt.bz2 >>> 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, ... > > Your scheme is very similar to mine. Both generate one GLOB_DAT > and one JUMP_SLOT relocation for the same function symbol. But > only one of them should be used at run-time. Your scheme may be > simpler when LD_AUDIT is used since you don't need to update GOT > slot. But you still need to decide if a GLOB_DAT relocation should be > skipped for LD_AUDIT. That's why I then suggested this: > I suppose you may also want to partition the GLOB_DAT relocations, so > that the dynamic loader can easily figure out which ones to ignore > when auditing is enabled. That would take another dynamic table entry. -cary