From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E19C0EB64D9 for ; Mon, 10 Jul 2023 23:18:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 435F68E0002; Mon, 10 Jul 2023 19:18:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E6028D0001; Mon, 10 Jul 2023 19:18:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AEA38E0002; Mon, 10 Jul 2023 19:18:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1CFF58D0001 for ; Mon, 10 Jul 2023 19:18:30 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DC2511A0212 for ; Mon, 10 Jul 2023 23:18:29 +0000 (UTC) X-FDA: 80997268338.01.1B26A8C Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf18.hostedemail.com (Postfix) with ESMTP id D42161C0006 for ; Mon, 10 Jul 2023 23:18:26 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=dabbelt-com.20221208.gappssmtp.com header.s=20221208 header.b=OyOED7x3; dmarc=none; spf=pass (imf18.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689031108; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=4roUBQPeYZ6G2jGF4CagIg1dFwgSWu47NljA15TV1d0=; b=ppDY0XP3fXYbm58ReW0dCYjoygNKLGMCsdmfpui7NIQQ5NeKfDfBtUCkKBraWBRee3gtln sBz9WLyqLrfLzomexbRm4o5MDkA7lKrjxFwBCNOHkEhL01WPUQgdqHOo1MMr3w3xhMTiRm G6GYraaIXaCheHkKXbquOjxtcAF+vVo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=dabbelt-com.20221208.gappssmtp.com header.s=20221208 header.b=OyOED7x3; dmarc=none; spf=pass (imf18.hostedemail.com: domain of palmer@dabbelt.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=palmer@dabbelt.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689031108; a=rsa-sha256; cv=none; b=XNzvtkC1yaM18VI7SFQy0cNWkH4qzRTpxbw//y8ONoir87oV5BefYqp6q6GueUmcE/9gWd Sx1NUIFP3MDJ4cpt4rcQ5LYC2Aw0oeuTmDcyGTVXmC9YGyHs66ufsByLW/qRueVtz5r/Zx iazaUWgW7SQg5srUcZqPKNhhVOMi2Ww= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1b8bd586086so38082625ad.2 for ; Mon, 10 Jul 2023 16:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1689031106; x=1691623106; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=4roUBQPeYZ6G2jGF4CagIg1dFwgSWu47NljA15TV1d0=; b=OyOED7x3RvFX23IVRtJARC7NxMlj1Y+CvB3MgE2nc1QP6nBNodbdLQHmzcKIEMaZNf MN95AvhUJ6slw43bb5ldhNPlI61RxThDbXq72AK0hKZcj9yBTfpHo3lsajVpMOV7CKS9 i1glD7ASUTTXoZjT6QWtSKe2GXul6F/gv9+3khR3LkFeXFUBrdIG9Xj5Q9D3nUkfXG79 QRMB8wyxg/6GrCH3mG4Sx7bV2WDz2Z/4IPxzvHEb14pMGmmzo3ybhYcPnqWMNuraUgy2 DSWUSic341TAGYmut0og3P+Ln0Cg/kwwG4+EBQAcqKE9XvV/ec2qbKSLS+vbwIbm7GEh MsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689031106; x=1691623106; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4roUBQPeYZ6G2jGF4CagIg1dFwgSWu47NljA15TV1d0=; b=jlLdkOaJxBEqxkZJdzogVpxNXe3mSclzzpc9V1RqPk9TzgX1QSAG5ZgqAAwDfvMAFh f8IAg1S40vSAqgwrd++IjKQabvzJ8czUGHxBtPN988yLskgviWBgxx8PzBYCQJGymN4+ H1O2GqcUzD6GhsLwr8LnA9ebRrp694c+PlqvXMTbq65kzuQiy9lZ3nGVT5l3SoHj+oEy 2JOXeHNHVISfNARh8nf1bAhtG3MgQWVLxA3B0vXntf7ldF2z9EA0zWFeDMgcQD5Z1ERb w5O08XxLtgcHINNeHrLJcN1CXaa5HZmks66t9tfaBRdNB07YolRmpxoxASsyCgkvOS0j 6H2w== X-Gm-Message-State: ABy/qLbMW0tt+BJPA4FIQQRM5LM7WhWmHawpCSG0F7igxAKFnZuzIC2w h2ZtcXXQd4FZfqc/uuoEs9uSCQ== X-Google-Smtp-Source: APBJJlGrNQ3vaCwjLrpvxAtvTh2+w3ga6JyltDtQXJx4sqQ9N6zEPon7fn9GOm+QIQecLzr1hMUxiA== X-Received: by 2002:a17:903:1111:b0:1b5:64a4:be8b with SMTP id n17-20020a170903111100b001b564a4be8bmr18159134plh.35.1689031106466; Mon, 10 Jul 2023 16:18:26 -0700 (PDT) Received: from localhost ([50.38.6.230]) by smtp.gmail.com with ESMTPSA id e16-20020a17090301d000b001b9ecee459csm383672plh.34.2023.07.10.16.18.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jul 2023 16:18:25 -0700 (PDT) Date: Mon, 10 Jul 2023 16:18:25 -0700 (PDT) X-Google-Original-Date: Mon, 10 Jul 2023 16:09:58 PDT (-0700) Subject: Re: [PATCH 1/2] binfmt_elf_fdpic: support 64-bit systems In-Reply-To: <7af8ca24-2ef2-dd08-1039-4d1d232d7715@kernel.org> CC: viro@zeniv.linux.org.uk, brauner@kernel.org, ebiederm@xmission.com, keescook@chromium.org, linux-riscv@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Palmer Dabbelt To: gerg@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D42161C0006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ux6c83411xcdk5j8gn4orrb4pdwrdbde X-HE-Tag: 1689031106-205825 X-HE-Meta: U2FsdGVkX1//PoytucwnH40Ur+74Hqzg+mfZ4KidjVIZFacYloipuEzBXk9/8pnxJwm91J/ZbdkKOm0D3GbYePFtJeu3CPusVzrhgA0FPpzeUMlel/ou4+UNED4s8MiRseVx6yS4v8vGRrfW2/gChANM3KsaSsNHtpcxa9YiXja/zgfsgO2vEjRDv/Hswwg06hWUu5l/0Iil6wVVVhsgOUwwxDOo0YGtTKwyuXS8Xr87c0WDceo63lhVMFXiacDBQNsFgmfXrg0AgMhKcyOEcEJOzJdBY7M/UrcFbWaZDfXlAolUMRxS0GpjB/1Ok8J5btF4qU2sK1VnwdxscYgYXJ4jge2ZM1Fcuh+MyNlEWttvWLYbCVrXvmYgRxqPgv+oveIFbmaXZ6lzD+dY1ExdsACrNFMTi/10PwWJNvEuj/v2pkgNMu9p4mTC0EpoxVZH3HFYSFMuz+Z0G0qxWqJoFUzQkDtP/KyJgCsUgnQDYlmTTVzAOs1zfK2c7T1as/GUjoGgmxdmFmM5v43w+mMeE5CPC83SstoY0Rbbi3bV7LTzrEjfzGuqCsG6TvIh1j+8dc6wbZGiiNyINEJkee0eW+sc9UsRtAebmZgUw8ui5KKg0AT/aLAldq+bE+m+W7jaoQtHxf0E7QpFsoWqB20kiGMqNj2uKwdAaKHD32VUv65s+nV5kC0SvPnn3yb8oLNuIPM73tx75pOa6fqEAhe/BLNTnkF1nMkNOulv59/KZJGSPzhmztpvcOFdJsqmrzw1TkD6v6GYzcHLaaqhFgH6qJaD/c211CyLdwoqODu3qWvBqJJImsLcJxE0ihr93wxfVMTX4IPOdAlYrE5Th4BbwSaVYkWjnh7c4fwm/ZLhiesxQMP+AzhrFvdh9kxozsLc+Tm7LnH/ezXFWikPr30fU85Id8v9+KvKXteVaTzxfk3tC72QHz5JQ6A+cB4R0k1/9Do8iy9+ifImIYjr74B 0qT8rQFK iVEVmgA+10MB/gKIEf5rxcYK3s3IVfwKUjF501+bROZvan04X+1K0cTGNwKlJAwW3DbqxdfzPgqGRoj2tJ5w+xWyHRT0xJCigLsNzKiSniAAqj415Ts7L4cehQjfvAEUL1KccdbQdM8T9jv5N6MbmgHKSSW3qaCzwoe2/xJhQ5l037oBo0p7wo+/nXZwRhEXIsQYvwt8eIex/SLybnOczpQ1+VmkUS8r9fAkhaDw3WAqUvI65zfoWDq+8GnUvN+rFD2yxQvoP28hCe2BYMr5WBztPq4zxYG1zuRsaj/m80h+JWBwqwazHmgOTeiKpwz4ED2t0vLR/Oh79FAXv6KNmJRxbT8tKe/up0kAwd/Y5jmkg3RG5Dxt7rQx5r/4oGxpsbc0etN3UeNQFolOiCPIlgpwP4YtpkZ1zRJj9ZIr7A5R/VaJ/v05Z65pGESrdkj7c8OCi1054EpKcl7FssyrGSSYgqCLqSwHH8j+NeHbPQYkWX8et2Pe1fZbhtVgkgeSjo7nPXIXxknrORFmhy+fnkZqK3UDzozHvW94A0iSkrvLduv+/Y5r25ekdN94QWGShhwIMNqRhaDV4MsM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 20 Apr 2023 07:58:29 PDT (-0700), gerg@kernel.org wrote: > Hi Palmer, > > On 19/4/23 13:27, Palmer Dabbelt wrote: >> On Wed, 29 Mar 2023 06:48:55 PDT (-0700), gerg@kernel.org wrote: >>> >>> On 22/3/23 08:49, Palmer Dabbelt wrote: >>>> On Tue, 28 Feb 2023 05:51:25 PST (-0800), gerg@kernel.org wrote: >>>>> The binfmt_flat_fdpic code has a number of 32-bit specific data >>>>> structures associated with it. Extend it to be able to support and >>>>> be used on 64-bit systems as well. >>>>> >>>>> The new code defines a number of key 64-bit variants of the core >>>>> elf-fdpic data structures - along side the existing 32-bit sized ones. >>>>> A common set of generic named structures are defined to be either >>>>> the 32-bit or 64-bit ones as required at compile time. This is a >>>>> similar technique to that used in the ELF binfmt loader. >>>>> >>>>> For example: >>>>> >>>>>   elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg >>>>>   elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap >>>>> >>>>> the choice based on ELFCLASS32 or ELFCLASS64. >>>>> >>>>> Signed-off-by: Greg Ungerer >>>>> --- >>>>>  fs/binfmt_elf_fdpic.c          | 38 +++++++++++++++++----------------- >>>>>  include/linux/elf-fdpic.h      | 14 ++++++++++++- >>>>>  include/uapi/linux/elf-fdpic.h | 15 ++++++++++++++ >>>>>  3 files changed, 47 insertions(+), 20 deletions(-) >>>> >>>> Adding some of the binfmt/fs folks, who weren't directly on the mail. It's looking like we're generally OK with this in RISC-V land, though there's still no userspace posted.  I don't think there's any rush here and it might be prudent to wait for userspace to start going through a bit of a review, but figured I'd at least poke everyone to see if there's any thoughts. >>>> >>>> I'm fine either way, so >>>> Acked-by: Palmer Dabbelt >>>> >>>> if that helps any.  Also happy to take this through the RISC-V tree along with the other if that's easier, but again no rush. >>> >>> Just following up. I haven't seen any feedback on this - did I miss any? >> >> If you did then I did too.  I'm not really sure what to do here: it looks fine to me, but it's not really my area so I'd prefer to have someone who understands this stuff a bit better chime in. >> >> It looks like some Arm patches recently went in through that tree, though, so maybe that's how things are supposed to go here? > > There doesn't seem to be anyone who is clearly the designated maintainer > for binfmt_elf_fdpic, or even just sheparding fixes for it. It mostly seems > to be tree-wide changes and cleanups that are getting done to it. > > So I have no idea... I have at least one fix inside binfmt_elf_fdpic.c for > ARM architecture that I am preparing now too, not sure how that is going to > go either. Looks like maybe nobody is taking these, then? Certainly nobody has chimed in. There's been some minor conflicts over the past few months, do you mind sending a v2? If nobody says anything on that I'll just take it via the RISC-V tree. > > Regards > Greg > > > >>>>> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c >>>>> index a05eafcacfb27..2eea6dd429fd6 100644 >>>>> --- a/fs/binfmt_elf_fdpic.c >>>>> +++ b/fs/binfmt_elf_fdpic.c >>>>> @@ -138,7 +138,7 @@ static int is_constdisp(struct elfhdr *hdr) >>>>>  static int elf_fdpic_fetch_phdrs(struct elf_fdpic_params *params, >>>>>                   struct file *file) >>>>>  { >>>>> -    struct elf32_phdr *phdr; >>>>> +    struct elf_phdr *phdr; >>>>>      unsigned long size; >>>>>      int retval, loop; >>>>>      loff_t pos = params->hdr.e_phoff; >>>>> @@ -560,8 +560,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, >>>>>      sp &= ~7UL; >>>>> >>>>>      /* stack the load map(s) */ >>>>> -    len = sizeof(struct elf32_fdpic_loadmap); >>>>> -    len += sizeof(struct elf32_fdpic_loadseg) * exec_params->loadmap->nsegs; >>>>> +    len = sizeof(struct elf_fdpic_loadmap); >>>>> +    len += sizeof(struct elf_fdpic_loadseg) * exec_params->loadmap->nsegs; >>>>>      sp = (sp - len) & ~7UL; >>>>>      exec_params->map_addr = sp; >>>>> >>>>> @@ -571,8 +571,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, >>>>>      current->mm->context.exec_fdpic_loadmap = (unsigned long) sp; >>>>> >>>>>      if (interp_params->loadmap) { >>>>> -        len = sizeof(struct elf32_fdpic_loadmap); >>>>> -        len += sizeof(struct elf32_fdpic_loadseg) * >>>>> +        len = sizeof(struct elf_fdpic_loadmap); >>>>> +        len += sizeof(struct elf_fdpic_loadseg) * >>>>>              interp_params->loadmap->nsegs; >>>>>          sp = (sp - len) & ~7UL; >>>>>          interp_params->map_addr = sp; >>>>> @@ -740,12 +740,12 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params, >>>>>                    struct mm_struct *mm, >>>>>                    const char *what) >>>>>  { >>>>> -    struct elf32_fdpic_loadmap *loadmap; >>>>> +    struct elf_fdpic_loadmap *loadmap; >>>>>  #ifdef CONFIG_MMU >>>>> -    struct elf32_fdpic_loadseg *mseg; >>>>> +    struct elf_fdpic_loadseg *mseg; >>>>>  #endif >>>>> -    struct elf32_fdpic_loadseg *seg; >>>>> -    struct elf32_phdr *phdr; >>>>> +    struct elf_fdpic_loadseg *seg; >>>>> +    struct elf_phdr *phdr; >>>>>      unsigned long load_addr, stop; >>>>>      unsigned nloads, tmp; >>>>>      size_t size; >>>>> @@ -767,7 +767,7 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params, >>>>> >>>>>      params->loadmap = loadmap; >>>>> >>>>> -    loadmap->version = ELF32_FDPIC_LOADMAP_VERSION; >>>>> +    loadmap->version = ELF_FDPIC_LOADMAP_VERSION; >>>>>      loadmap->nsegs = nloads; >>>>> >>>>>      load_addr = params->load_addr; >>>>> @@ -843,8 +843,8 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params, >>>>>              if (phdr->p_vaddr >= seg->p_vaddr && >>>>>                  phdr->p_vaddr + phdr->p_memsz <= >>>>>                  seg->p_vaddr + seg->p_memsz) { >>>>> -                Elf32_Dyn __user *dyn; >>>>> -                Elf32_Sword d_tag; >>>>> +                Elf_Dyn __user *dyn; >>>>> +                Elf_Sword d_tag; >>>>> >>>>>                  params->dynamic_addr = >>>>>                      (phdr->p_vaddr - seg->p_vaddr) + >>>>> @@ -854,11 +854,11 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params, >>>>>                   * one item, and that the last item is a NULL >>>>>                   * entry */ >>>>>                  if (phdr->p_memsz == 0 || >>>>> -                    phdr->p_memsz % sizeof(Elf32_Dyn) != 0) >>>>> +                    phdr->p_memsz % sizeof(Elf_Dyn) != 0) >>>>>                      goto dynamic_error; >>>>> >>>>> -                tmp = phdr->p_memsz / sizeof(Elf32_Dyn); >>>>> -                dyn = (Elf32_Dyn __user *)params->dynamic_addr; >>>>> +                tmp = phdr->p_memsz / sizeof(Elf_Dyn); >>>>> +                dyn = (Elf_Dyn __user *)params->dynamic_addr; >>>>>                  if (get_user(d_tag, &dyn[tmp - 1].d_tag) || >>>>>                      d_tag != 0) >>>>>                      goto dynamic_error; >>>>> @@ -927,8 +927,8 @@ static int elf_fdpic_map_file_constdisp_on_uclinux( >>>>>      struct file *file, >>>>>      struct mm_struct *mm) >>>>>  { >>>>> -    struct elf32_fdpic_loadseg *seg; >>>>> -    struct elf32_phdr *phdr; >>>>> +    struct elf_fdpic_loadseg *seg; >>>>> +    struct elf_phdr *phdr; >>>>>      unsigned long load_addr, base = ULONG_MAX, top = 0, maddr = 0; >>>>>      int loop, ret; >>>>> >>>>> @@ -1011,8 +1011,8 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params, >>>>>                           struct file *file, >>>>>                           struct mm_struct *mm) >>>>>  { >>>>> -    struct elf32_fdpic_loadseg *seg; >>>>> -    struct elf32_phdr *phdr; >>>>> +    struct elf_fdpic_loadseg *seg; >>>>> +    struct elf_phdr *phdr; >>>>>      unsigned long load_addr, delta_vaddr; >>>>>      int loop, dvset; >>>>> >>>>> diff --git a/include/linux/elf-fdpic.h b/include/linux/elf-fdpic.h >>>>> index 3bea95a1af537..e533f45131945 100644 >>>>> --- a/include/linux/elf-fdpic.h >>>>> +++ b/include/linux/elf-fdpic.h >>>>> @@ -10,13 +10,25 @@ >>>>> >>>>>  #include >>>>> >>>>> +#if ELF_CLASS == ELFCLASS32 >>>>> +#define Elf_Sword            Elf32_Sword >>>>> +#define elf_fdpic_loadseg        elf32_fdpic_loadseg >>>>> +#define elf_fdpic_loadmap        elf32_fdpic_loadmap >>>>> +#define ELF_FDPIC_LOADMAP_VERSION    ELF32_FDPIC_LOADMAP_VERSION >>>>> +#else >>>>> +#define Elf_Sword            Elf64_Sxword >>>>> +#define elf_fdpic_loadmap        elf64_fdpic_loadmap >>>>> +#define elf_fdpic_loadseg        elf64_fdpic_loadseg >>>>> +#define ELF_FDPIC_LOADMAP_VERSION    ELF64_FDPIC_LOADMAP_VERSION >>>>> +#endif >>>>> + >>>>>  /* >>>>>   * binfmt binary parameters structure >>>>>   */ >>>>>  struct elf_fdpic_params { >>>>>      struct elfhdr            hdr;        /* ref copy of ELF header */ >>>>>      struct elf_phdr            *phdrs;        /* ref copy of PT_PHDR table */ >>>>> -    struct elf32_fdpic_loadmap    *loadmap;    /* loadmap to be passed to userspace */ >>>>> +    struct elf_fdpic_loadmap    *loadmap;    /* loadmap to be passed to userspace */ >>>>>      unsigned long            elfhdr_addr;    /* mapped ELF header user address */ >>>>>      unsigned long            ph_addr;    /* mapped PT_PHDR user address */ >>>>>      unsigned long            map_addr;    /* mapped loadmap user address */ >>>>> diff --git a/include/uapi/linux/elf-fdpic.h b/include/uapi/linux/elf-fdpic.h >>>>> index 4fcc6cfebe185..ec23f08711292 100644 >>>>> --- a/include/uapi/linux/elf-fdpic.h >>>>> +++ b/include/uapi/linux/elf-fdpic.h >>>>> @@ -32,4 +32,19 @@ struct elf32_fdpic_loadmap { >>>>> >>>>>  #define ELF32_FDPIC_LOADMAP_VERSION    0x0000 >>>>> >>>>> +/* segment mappings for ELF FDPIC libraries/executables/interpreters */ >>>>> +struct elf64_fdpic_loadseg { >>>>> +    Elf64_Addr    addr;        /* core address to which mapped */ >>>>> +    Elf64_Addr    p_vaddr;    /* VMA recorded in file */ >>>>> +    Elf64_Word    p_memsz;    /* allocation size recorded in file */ >>>>> +}; >>>>> + >>>>> +struct elf64_fdpic_loadmap { >>>>> +    Elf64_Half    version;    /* version of these structures, just in case... */ >>>>> +    Elf64_Half    nsegs;        /* number of segments */ >>>>> +    struct elf64_fdpic_loadseg segs[]; >>>>> +}; >>>>> + >>>>> +#define ELF64_FDPIC_LOADMAP_VERSION    0x0000 >>>>> + >>>>>  #endif /* _UAPI_LINUX_ELF_FDPIC_H */ >>>>