Re: [gold] First patch for aarch64 backend

[Andrew Pinski <pinskia at gmail dot com>]

On Tue, Jul 1, 2014 at 4:09 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Jul 1, 2014 at 4:06 PM, Jing Yu <jingyu@google.com> wrote:
>> On Tue, Jul 1, 2014 at 3:15 PM, Yufeng Zhang <yufengzhangdev@gmail.com> wrote:
>>> On 26 June 2014 00:46, Jing Yu <jingyu@google.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We start to work on gold aarch64 backend. Here is the first patch.
>>>> This patch is just a skeleton which almost does nothing.
>>>> The change that enables gold for aarch64 in top level configure was
>>>> removed from this patch.
>>>>
>>>> Tested:
>>>> 1) On x86_64,
>>>> ${binutils}/configure --build=x86_64-unknown-linux-gnu
>>>> --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
>>>> --enable-plugins --disable-multilib --disable-nls --enable-threads
>>>> --enable-gold=default --enable-targets=all
>>>> $make all-gold
>>>>
>>>> Also built with -O1 and -O0.
>>>>
>>>> 2) On aarch64,
>>>> gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
>>>> $ ../binutils-gdb/configure --enable-plugins --disable-multilib
>>>> --disable-nls --enable-threads --enable-gold=default
>>>> --enable-targets=all
>>>> $make all-gold
>>>> Also built with -O1 and -O0.
>>>>
>>>> The generated native gold/ld-new is able to read hello.o and libc.so.
>>>>
>>>> Thanks,
>>>> Jing
>>>>
>>>> diff --git a/elfcpp/aarch64.h b/elfcpp/aarch64.h
>>>> new file mode 100644
>>>> index 0000000..09bc498
>>>> --- /dev/null
>>>> +++ b/elfcpp/aarch64.h
>>>> @@ -0,0 +1,183 @@
>>>> +// aarch64.h -- ELF definitions specific to AARCH64  -*- C++ -*-
>>>> +
>>>> +// Copyright (C) 2012-2014 Free Software Foundation, Inc.
>>>> +// Written by Jing Yu (jingyu@google.com)
>>>> +
>>>> +// This file is part of elfcpp.
>>>> +
>>>> +// This program is free software; you can redistribute it and/or
>>>> +// modify it under the terms of the GNU Library General Public License
>>>> +// as published by the Free Software Foundation; either version 2, or
>>>> +// (at your option) any later version.
>>>> +
>>>> +// In addition to the permissions in the GNU Library General Public
>>>> +// License, the Free Software Foundation gives you unlimited
>>>> +// permission to link the compiled version of this file into
>>>> +// combinations with other programs, and to distribute those
>>>> +// combinations without any restriction coming from the use of this
>>>> +// file.  (The Library Public License restrictions do apply in other
>>>> +// respects; for example, they cover modification of the file, and
>>>> +/// distribution when not linked into a combined executable.)
>>>> +
>>>> +// This program is distributed in the hope that it will be useful, but
>>>> +// WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>> +// Library General Public License for more details.
>>>> +
>>>> +// You should have received a copy of the GNU Library General Public
>>>> +// License along with this program; if not, write to the Free Software
>>>> +// Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
>>>> +// 02110-1301, USA.
>>>> +
>>>> +#ifndef ELFCPP_AARCH64_H
>>>> +#define ELFCPP_AARCH64_H
>>>> +
>>>> +namespace elfcpp
>>>> +{
>>>> +
>>>> +// The relocation type information is taken from:
>>>> +//
>>>> +//   ELF for the ARM 64-bit Architecture (AArch64)
>>>> +//   Document number: ARM IHI 0056B, current through AArch64 ABI release 1.0
>>>> +//   Date of Issue: 22nd May, 2013
>>>> +//
>>>
>>> Is there a particular reason that you didnât choose the ABI release
>>> 1.1 which has the support for ELF32, including the ELF32 relocation
>>> codes?
>>>
>> We don't have a plan to support ELF32 in anytime soon.
>> The document that describes ELF32 relocations is a beta proposal.ELF_PLATFORM
>
> Why not?  The Linux kernel support for ILP32 is in review right now.
> And I will be submitting the glibc support right after the kernel
> support goes in.
>
> They are only beta because ARM does not want to commit to them until
> an implementation is upstream.  Yes it is a catch 22 though.


In fact I think Android should be looking into support ILP32 also.  It
would make better sense for them.

Thanks,
Andrew Pinski

>
> Thanks,
> Andrew Pinski
>
>
>>
>>>> +
>>>> +enum
>>>> +{
>>>> +  // Null relocation codes
>>>> +  R_AARCH64_NONE = 0, // None
>>>> +  withdrawn = 256, // Treat as R_AARCH64_NONE
>>>> +
>>>> +  // Static relocations
>>>> +  R_AARCH64_ABS64 = 257, // S + A
>>>> +  R_AARCH64_ABS32 = 258, // S + A
>>>> +  R_AARCH64_ABS16 = 259, // S + A
>>>> +  R_AARCH64_PREL64 = 260, // S + A - P
>>>> +  R_AARCH64_PREL32 = 261, // S + A - P
>>>> +  R_AARCH64_PREL16 = 262, // S + A - P
>>>> +  R_AARCH64_MOVW_UABS_G0 = 263, // S + A
>>>> +  R_AARCH64_MOVW_UABS_G0_NC = 264, // S + A
>>>> +  R_AARCH64_MOVW_UABS_G1 = 265, // S + A
>>>
>>> [snip]
>>>
>>>> diff --git a/gold/configure.tgt b/gold/configure.tgt
>>>> index 93d622d..eaf164b 100644
>>>> --- a/gold/configure.tgt
>>>> +++ b/gold/configure.tgt
>>>> @@ -144,6 +144,14 @@ arm*-*-*)
>>>>   targ_big_endian=false
>>>>   targ_extra_big_endian=true
>>>>   ;;
>>>> +aarch64-*)
>>>
>>> I think you'll need aarch64*-* in order to support targ_extra_size=32
>>> and targ_extra_big_endian=true.
>>>
>> Will do. Thanks!
>> Jing
>>
>>> Yufeng