From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14280 invoked by alias); 8 Aug 2012 16:23:05 -0000 Received: (qmail 14270 invoked by uid 22791); 8 Aug 2012 16:23:02 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Aug 2012 16:22:49 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q78GMnES002684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 12:22:49 -0400 Received: from fche.csb (vpn-11-235.rdu.redhat.com [10.11.11.235]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q78GMmtX020832; Wed, 8 Aug 2012 12:22:48 -0400 Received: by fche.csb (Postfix, from userid 2569) id 02AD058130; Wed, 8 Aug 2012 12:22:47 -0400 (EDT) To: Fumiaki Isoya Cc: Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: The Extension to ELF References: <5021FB65.2010704@gmail.com> <502288B8.2090802@gmail.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 08 Aug 2012 16:23:00 -0000 In-Reply-To: <502288B8.2090802@gmail.com> (Fumiaki Isoya's message of "Thu, 09 Aug 2012 00:41:44 +0900") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg00085.txt.bz2 Fumiaki Isoya writes: >> It may interest you to know that, for an older Cygnus project (mep), >> we implemented a facility called computed/complex relocations, as an >> ELF extension. This is a way of encoding general symbol/arithmetic >> expressions to be evaluated at link time and substituted into the >> binary output. [...] > > Did you write some compiler language to evaluate that feature? No. Software for this particular was mainly coded in assembly, and the assembly language / instruction set were itself very configurable(!), so relocations had to be general. If this capability is useful for a higher-level language, a binding would have to be created, and the arch gas/binutils would have to start generating the info. > How is the idea of adopting it as the standard format of GNU Hurd? I have no opinion on this. Note though that these complex relocations are encoded within a standard ELF file (merely using separate relocation-type and symbol-type codes). There is no need for an OS/kernel to support it, since all the action takes place within the assembler and linker. - FChE