From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 45560385B835 for ; Thu, 9 Apr 2020 20:19:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 45560385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wr1-x435.google.com with SMTP id s8so13466184wrt.7 for ; Thu, 09 Apr 2020 13:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WxDsOSP9lgLnPPEeWqMrypmubFo/rFnULdLOZMrMXSQ=; b=C+XKbMySsXGYtO4OPZje1YRpz0WkzevaTzUA+3Vqpa8t7CnyFcD81Uphl1e66sjrA9 8ba0LAgRgafcF/cCcF5Ru5kDfeJEK2Ua6XNfj4QCkDu5qziyAoQUdwJNY2rBE6yL3dy9 f/1UAxlwniRxLZQnH72aehRsBmLVJJneufWaY/MdC6yeVbP0yL9xZ0X+K5kL8R2JJvTm g+cEsgZDtkUxu7IK6w7wphOLlJWhsy+uUtCe/2jDHXOEsYIgj/dW3preApoKJni29nDs iHTfuNSJxgYf6H3JrqFN+0uLl2GnT+na7xiNstNrkNgOtIw7efn4V0SY6ieL7wCJBCJK ZVdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=WxDsOSP9lgLnPPEeWqMrypmubFo/rFnULdLOZMrMXSQ=; b=taJnCeaJ91YodgU8pl8rJCYudgVlhG4T7lIAChVTb35tU4QN+FvxANZvlVrXDgKTBJ g1smkpuvGGh32KfVa6kpZBXDL6WHia5ollNOwQ3auhUptkcLiPWvgwDSxZ3DGrmA2r0Y PJv5cvndtGpYKUHU/E/e7OuC3Ey7kZJ6gfEIzkftTHHheYrtMxfl85Za7U1sLsKaoYEF EWV/JBKl4cTA87xX0JDnlCnt8b5euG8iMKqcXfiowFhIq9EgWjAM9cALvLnY6Ax06Xvr XDeK5wUq2z514DM1J4ek72KQCJfYIBDWvuVSTOc4H5w63ujHtayKhhHSH8hlZLX0jWt2 cuZg== X-Gm-Message-State: AGi0PuasppPWbNqEZlHV5VwzD7RkBKoliK/AeEUjgUMAzSgNi+DsJHwd IUCal1dCHpL/ubL/lWw/n9cNSMToyJU= X-Google-Smtp-Source: APiQypIidmLYHbRZNAgDoSvevSf0SJtsz4PnG+AWIG8ZD2pHAHQuw9nObpn1HcWtRsWn6OZtj2UXmQ== X-Received: by 2002:adf:b64f:: with SMTP id i15mr939281wre.351.1586463572369; Thu, 09 Apr 2020 13:19:32 -0700 (PDT) Received: from jozef-kubuntu ([2a01:4b00:87fd:900:48a7:dad8:7945:326f]) by smtp.gmail.com with ESMTPSA id s7sm16699707wrt.2.2020.04.09.13.19.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Apr 2020 13:19:32 -0700 (PDT) Date: Thu, 9 Apr 2020 21:19:30 +0100 From: Jozef Lawrynowicz To: "H.J. Lu" Cc: "binutils@sourceware.org" Subject: Re: What size-dependent parts of bfd/elfcode.h are undesirable? Message-ID: <20200409211930.30747145@jozef-kubuntu> In-Reply-To: References: <20200409192731.44c1f67c@jozef-kubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 20:19:34 -0000 On Thu, 9 Apr 2020 11:56:56 -0700 "H.J. Lu" wrote: > On Thu, Apr 9, 2020 at 11:28 AM Jozef Lawrynowicz > wrote: > > > > There is a comment at the top of bfd/elfcode.h: > > > > > (2) The code in this file is compiled twice, once in 32-bit mode and > > > once in 64-bit mode. More of it should be made size-independent > > > and moved into elf.c. > > > > > > > If I am adding a new ELF type which has 32 and 64-bit versions and has similar > > requirements to relocation entries, is it ok to copy much of the implementation > > required to support Elf_External_Rel for my new type? i.e. swap_{in,out} > > functions, size-independent mappings of external types > > (Elf_External_Rel -> Elf{32,64_External_Rel}) and field accessors > > (ELF_R_INFO -> Elf{32,64}_R_INFO). > > > > Is there a new recommended way to do something like this, or is the comment > > referring to some other parts of the size-dependent implementation? > > > > Thanks, > > Jozef > > Please take a look at elf_append_rel and elf_append_rela. The same > function is used for both 32bit and 64bit ELF. > > But they both rely on the size-dependent functions from elfcode.h to actually do the work. What I meant for my original question is that if I'm implementing a similar type to Elf{32,64}_Rel from scratch, should I just follow the template for these types or should I strive to do it in some size-independent way that is self-contained within elf.c? For example by having conditional statements that check the EI_CLASS of field of the ELF header to determine whether to output data for a 32-bit or 64-bit target. Perhaps I read too much into that comment at the top of elfcode.h, and should just go with the current method used in this file, relying on the fact it will be compiled separately for 32-bit and 64-bit targets. That seems a lot neater than having loads of checks for EI_CLASS in elf.c. Thanks, Jozef