From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [PATCH v3 04/23] elf: Add relocation types to elfstructs.h Date: Mon, 22 Feb 2016 15:19:50 +0000 Message-ID: <56CB2716.30805@citrix.com> References: <1455300361-13092-1-git-send-email-konrad.wilk@oracle.com> <1455300361-13092-5-git-send-email-konrad.wilk@oracle.com> <56C19BB202000078000D1EED@prv-mh.provo.novell.com> <20160219210535.GE11420@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aXsHL-0003G5-C6 for xen-devel@lists.xenproject.org; Mon, 22 Feb 2016 15:20:03 +0000 In-Reply-To: <20160219210535.GE11420@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Jan Beulich Cc: Keir Fraser , Ian Campbell , jinsong.liu@alibaba-inc.com, Ian Jackson , Tim Deegan , mpohlack@amazon.de, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org, sasha.levin@citrix.com List-Id: xen-devel@lists.xenproject.org On 02/19/2016 09:05 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 15, 2016 at 01:34:42AM -0700, Jan Beulich wrote: >>>>> On 12.02.16 at 19:05, wrote: >>> --- a/xen/include/xen/elfstructs.h >>> +++ b/xen/include/xen/elfstructs.h >>> @@ -348,6 +348,14 @@ typedef struct { >>> #define ELF64_R_TYPE(info) ((info) & 0xFFFFFFFF) >>> #define ELF64_R_INFO(s,t) (((s) << 32) + (u_int32_t)(t)) >>> >>> +/* x86-64 relocation types. We list only the ones we implement. */ >> >> "we implement" is too vague for my taste: This comment should >> have some kind of reference to xSplice. > > > /* x86-64 relocation types. We list only the ones xSplice implements. */ > > ? > >> >>> +#define R_X86_64_NONE 0 /* No reloc */ >>> +#define R_X86_64_64 1 /* Direct 64 bit */ >>> +#define R_X86_64_PC32 2 /* PC relative 32 bit signed */ >>> +#define R_X86_64_PLT32 4 /* 32 bit PLT address */ >>> +#define R_X86_64_32 10 /* Direct 32 bit zero extended */ >>> +#define R_X86_64_32S 11 /* Direct 32 bit sign extended */ >> >> Is there really a use case for the last two in the hypervisor >> (which doesn't live in the top 2G of address space)? (If the > > No. But they are there to catch tools (and developers) by accident > building the payloads with wacky linker options (like I did). > >> use case are constants, I suppose R_X86_64_{8,16} ought >> to also be permitted.) Also, is there a reason why at least >> R_X86_64_PC64 shouldn't also be supported? > > It hasn't been implemented. Nor has the situation come up > when this was used. > > In the previous round of reviews the feedback was that we should only > list the ones the code base was referencing. > > Let me add R_X86_64_PC64 on the TODO list. >> From my testing, GCC generates R_X86_64_64, R_X86_64_PC32, and R_X86_64_PLT32 relocations so those are the ones we need initially. More can be added later as needed, I suppose. -- Ross Lagerwall