[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <552EE560.9070205@suse.de>
Date: Thu, 16 Apr 2015 00:25:36 +0200
From: Alexander Graf <agraf@...e.de>
To: Catalin Marinas <catalin.marinas@....com>,
"Dr. Philipp Tomsich" <philipp.tomsich@...obroma-systems.com>
CC: Andreas Kraschitzer <andreas.kraschitzer@...obroma-systems.com>,
Arnd Bergmann <arnd@...db.de>,
"Pinski, Andrew" <Andrew.Pinski@...iumnetworks.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Pinski <apinski@...ium.com>,
Kumar Sankaran <ksankaran@....com>,
Benedikt Huber <benedikt.huber@...obroma-systems.com>,
linux-arm-kernel@...ts.infradead.org,
Christoph Muellner <christoph.muellner@...obroma-systems.com>,
Andreas Schwab <schwab@...e.de>
Subject: Re: [PATCH v4 00/24] ILP32 for ARM64
On 15.04.15 19:22, Catalin Marinas wrote:
> On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote:
>> On 15 Apr 2015, at 17:38, Catalin Marinas <catalin.marinas@....com> wrote:
>>> On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
>>>> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
>>>>> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
>>>>>> We’ve run full systems (built from buildroot) consisting of ILP32 binaries
>>>>>> only (ok… admittedly gdb was an exception, as we haven’t fixed the fact
>>>>>> that someone has assumed sizeof(long) == 8 in some data-structure of
>>>>>> the AArch64 backend there) in our verification runs. In fact, it will be very
>>>>>> special classes of applications that will need a 64bit address-space.
>>>>>
>>>>> If we are to merge AArch64-ILP32, I'd like to see a full software stack,
>>>>> maybe a distro like Debian. Otherwise the kernel code will bit-rot (just
>>>>> like it regularly happens with big endian).
>>>>
>>>> I actually don't think this should be a prerequisite. We have too many
>>>> dependencies here, and as long as we are debating the exact ABI,
>>>> any work that gets put into a full distro support (other than openembedded
>>>> etc) would likely be wasted.
>>>
>>> I agree with this not being a prerequisite for merging ILP32 but at
>>> least a long term plan to do something beyond openembedded, once we
>>> agreed on the ABI and _upstreamed_ the kernel and glibc code. Those
>>> legacy applications will probably need more than glibc to run and it's
>>> likely that people will want to run them in a full AArch64 (LP64)
>>> environment. A simpler approach (to me, I'm not a distro person) would
>>> be to just provide additional ILP32 libs in a multi-lib arm64 distro
>>> like Debian rather than all the packages. As for the compiler, AFAIK
>>> aarch64-linux-gnu-* simply needs an option to build for ILP32.
>>
>> We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses,
>> termcap, zlib and a few others in a multiarch setup… this was used in the
>> field by customers and worked rather well.
>>
>> One of the engineers in my team is currently working on carrying this forward
>> so we can use this for any Debian-based AArch64 distribution in the future.
>
> That sounds great. What I'm looking for is to be able to build something
> like LTP to be able to reproduce the testing before merging the code. So
> the PPA approach looks good.
We've just started to bootstrap openSUSE for ILP32 with the non-final
abi. However, keep in mind that at least for us bootstrapping is a
manual process. So changing syscall numbers means we'll need to go
through the manual process again.
So if you need any help on getting you an environment that allows you to
build LTP with whatever syscall abi people come up with, feel free to
poke Andreas or me.
Alex
PS: This mail does not include any commitment to maintain an ILP32
openSUSE distribution ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists