Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755259AbbLPTS1 (ORCPT ); Wed, 16 Dec 2015 14:18:27 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:54616 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753802AbbLPTS0 (ORCPT ); Wed, 16 Dec 2015 14:18:26 -0500 From: Arnd Bergmann To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, broonie@kernel.org, Nathan_Lynch@mentor.com, agraf@suse.de, linux-kernel@vger.kernel.org, klimov.linux@gmail.com, Andrew Pinski , Yury Norov , jan.dakinevich@gmail.com, Andrew Pinski , ddaney.cavm@gmail.com, bamvor.zhangjian@huawei.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH v6 09/20] arm64:ilp32: share HWCAP between LP64 and ILP32 Date: Wed, 16 Dec 2015 20:17:25 +0100 Message-ID: <15616150.rsIFodoBKz@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151216171904.GF27051@e104818-lin.cambridge.arm.com> References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <20151216165819.GD27051@e104818-lin.cambridge.arm.com> <20151216171904.GF27051@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:tS/KLVneF1L/cvVze2kmPDOuM3bWRX6KcXTlUi2/VMU7UHw30Oq wbZho/tNkKPxzcP21VqhKAiAYTeVyX7Seu1mTjD7L5qQbe50ZTyF4H4sCOjHLIDS5gid5zf ndaimHMCeM6GACAP2yjTJ8AV+CPUAT5O387VBm6sCIyOZVN8H7HaFKsXdQZoEOfVimwqrw6 SV8KhKMlpDlmel+wjPLMQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:yvZk4QQkrZo=:WIvVrUBXTnbVnl1cFMF0MG ttFzY5fQSK/2hzC5UfrR2XBWxTPNZinuAvgIVWwnduhbrV9HrlLaJPSDm+38BJABJfMDEG98o 6847uyHF79SHLrCcDpOWkY9xE7Ksn3b3dK2LaXIdEI8WD5tHBkgp+dQYdFAMxcJu5/tnM01ti NH6JWgHivUhhLVoBvJ+34n8cdIz3ZD51nZj6lev9740wQgvkSYi+U3HZxtZ/DtWMGHjas9/OM 0zjp8i93cgYZDsCqw5fXMSL4dR2tphZpaqNbLnWUIWMtsf/g8zUzM2IQj1bh+On5SJ1s8tRl4 NV9Y1k+OM1hx69qSCGGYI0R7IFO2y01a83K2UQLiwLDX6nOG5zKMmiQS2M+DGKojK1RkDc5Vm jEqG3i91f8R6oKEmgVU14mZ79NR8fnCnsN8ydOrKlgbIG2Mi5N1Bru5/a8fJiUYvEU8HBrDHj wCZSVEvREDbw1PhWSa9zHQ2mNuIxUd5BALayNNJvwKoM85Pt6+dX82GNtORk64KvXIabiGotc YR0QaGElH26E2hbZ8D7F97VFWwH7/Pv+JDzBKzWjuOK4qBoJ86ADE0W9D+6yM2hlbUb36cr9v 5JwKSJIbZVQtKGJTUOJhKiLtLrzIXmSTJix9sIOKXPTYQVrDpfVsD8l5MN5m5GCAnLQd0Czb+ FjQiXFh8L9YX68A0OjRJvRB5Qsul31SfI5W0ieqjJ6TBTliTeYQXInpAL77ZXBRQ6TK43fMWC fDrcq0rsbOumAyDj Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2628 Lines: 66 On Wednesday 16 December 2015 17:19:05 Catalin Marinas wrote: > On Wed, Dec 16, 2015 at 04:58:20PM +0000, Catalin Marinas wrote: > > On Wed, Dec 16, 2015 at 04:54:34PM +0100, Arnd Bergmann wrote: > > > On Wednesday 16 December 2015 00:42:35 Yury Norov wrote: > > > > > > > > #ifdef CONFIG_COMPAT > > > > -#define COMPAT_ELF_HWCAP (compat_elf_hwcap) > > > > -#define COMPAT_ELF_HWCAP2 (compat_elf_hwcap2) > > > > extern unsigned int compat_elf_hwcap, compat_elf_hwcap2; > > > > +#define COMPAT_ELF_HWCAP \ > > > > + (is_a32_compat_task() \ > > > > + ? compat_elf_hwcap \ > > > > + : elf_hwcap) > > > > + > > > > +#define COMPAT_ELF_HWCAP2 \ > > > > + (is_a32_compat_task() \ > > > > + ? compat_elf_hwcap2 \ > > > > + : 0) > > > > + > > > > #endif > > > > > > I'm trying to understand how this is used. Are you compiling > > > fs/compat_binfmt_elf.c twice to handle both 32-bit ELF types? > > > > It's the same compat_binfmt_elf.c which handles all 32-bit ELF types, > > i.e. AArch32 and A64/ILP32. The above macros are not constants, so they > > are evaluated every time a new ELF file is loaded. We do a similar trick > > with COMPAT_SET_PERSONALITY in patch 11. Ok, I see. I've also looked at other architectures, and found that MIPS does it the way I thought it would be git grep -w binfmt_elf.c arch/mips/kernel/binfmt_elfn32.c:#include "../../../fs/binfmt_elf.c" arch/mips/kernel/binfmt_elfo32.c:#include "../../../fs/binfmt_elf.c" I still think doing the same for arm64 would result in more maintainable code, because it completely separates the two different formats into separate files. We'd obviously leave the existing compat handling as it is, and just add one more file, not do both of them separately as MIPS does. Do you see any downsides of that approach? > IIUC, we may have a problem with this. elf_hwcap is 64-bit long while > elf_info[n] is 32-bit (Elf32_Addr), so we truncate AT_HWCAP if we ever > go beyond bit 31. The above may need to look something like: > > #define COMPAT_ELF_HWCAP \ > (is_a32_compat_task() \ > ? compat_elf_hwcap \ > : (u32)elf_hwcap) > > #define COMPAT_ELF_HWCAP2 \ > (is_a32_compat_task() \ > ? compat_elf_hwcap2 \ > : (u32)(elf_hwcap >> 32)) Yes, interesting find. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/