From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115807 invoked by alias); 6 Nov 2019 18:37:43 -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 115792 invoked by uid 89); 6 Nov 2019 18:37:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Request, our X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2019 18:37:41 +0000 Received: by mail-ot1-f65.google.com with SMTP id m15so12956190otq.7 for ; Wed, 06 Nov 2019 10:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RRJCBIjH2ZOJeKVyCaQNpKOxulOLtt5rVunqtDA0CK4=; b=g9aXa9HT1l2X6v3roy5LxwN672p1mmrUaW91ZVmYJBcFq9qpkaOZJzRqAFeVDZsqdn yirVGuwhc7YjIABoZUeIZDSopQTRUvZUVOL0kGM1QQKXQ+SgYamExoBFa4L+VYu38C6M ddTmAm93SZpkojWSMm24xX1TvfxWXJvlp+sRQsizRyinBRcgc0z50n6T3X/STDuOaqUL pbJPfq3yz88WsG5e0mUlDR+fVIw7ym51638M7qGZ7PCh6Bh9UJoEQbNI0iN9iP2AZF80 j4z1Ed0EbeRdFtkLUrIiC9FLUGFmIVHrRM+RyGPni9YrS0n08yRwxk8UvQbmpbcmtam5 nNYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RRJCBIjH2ZOJeKVyCaQNpKOxulOLtt5rVunqtDA0CK4=; b=UTlJKQCPt/w+dNmiLgn0shBsGkiGYGJFG8dvXqApM7OTSACir7DgSRRJrf3pjLAstw adkT+VSpV3qUfkzls8zSUOBnYgm7SQO74+lvoGgWA5i+rMuHCQcBFdN9p3YvL6hDB96h beGliwtRPG3SQ8/5brc5KRZV0HGYHqsFF7T9RT2qVQLwNKtyZWrFDdOdPYSHiTZ5COVB zXgSMeimqBfjzP35/uUvoEI0bguNSnL25kx3SnbjxmD2pedQkXspvq+O3u/5+mp/zsjO XMcGS8hVN7zbnp/MruJATnee+NRMTcyHuGt3OBiEsG2FnRldnnmCD3JTEovDxElhfGfy lrOQ== X-Gm-Message-State: APjAAAV3rUrqKYj+AetfvBf25l+Tqlz8sIjO+vxJWhkzqeK37XIC+ZgP ggdovgi13bYxNIuAp/jgPM6eXn43QUnGUaC/hwII+264 X-Google-Smtp-Source: APXvYqw7T8yCmtMGe7V7qfuhl27Hzh7wLCsTWRtvWHZGSM/0gktUpgvOLEJg+hohKE8yeB7rNkCQy+8KHthqghCyr/Y= X-Received: by 2002:a05:6830:56f:: with SMTP id f15mr3045860otc.285.1573065459548; Wed, 06 Nov 2019 10:37:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: Request for a new relaxed relocation type for Basic Block Section jumps To: Sriraman Tallam Cc: Rahul Chaudhry via gnu-gabi , Han Shen , Rahman Lavaee , Rui Ueyama , Eli Friedman , Krzysztof Pszeniczny , Xinliang David Li , Cary Coutant Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00002.txt.bz2 On Wed, Nov 6, 2019 at 9:56 AM Sriraman Tallam wrote: > > Hello H.J., > > We are looking at supporting Basic Block Sections in the compiler (LL= VM for now) similar to function and data sections, please see our RFC here:= http://lists.llvm.org/pipermail/llvm-dev/2019-September/135393.html In or= der to support basic block sections, the compiler needs to generate uncondi= tional branches between basic blocks that would otherwise be a fall through= . Further, all inter-basic block branches have to use relocations to allow= the linker to arbitrarily reorder basic blocks. > > We relax these branches in the linker by eliminating fall throughs aft= er reordering the basic blocks. Using a separate relocation type for such = relocations would make it really easy to identify and relax these branches.= We are doing this by inspecting the opcode bytes of the relocation to chec= k if it is a branch and this is potentially prone to errors. How do we go a= bout adding a new relocation type for this? > So you need a new PC relative 32-bit signed relocation for jmp. Is this correct? Can it be simply treated as R_X86_64_PC32 and work correctly? Can it be used with jcc and call? --=20 H.J.