Re: [Gcl-devel] [PATCH 00/11] Add support for AArch64

[Will Newton]

On 11 June 2014 23:23, Camm Maguire <address@hidden> wrote:
> Greetings, and thanks so much for this!!
>
> Am assuming aarch64 is some sort of 64bit arm.

Indeed it is. It's still a fairly new architecture so there isn't much
hardware around at the moment unfortunately. It's coming, but nobody
knows quite when. ;-)

> Will Newton <address@hidden> writes:
>
>> This patch series allows building gcl on AArch64. The series is ordered
>> roughly in order of patch quality, with the final patch being a hack
>> to #ifdef out some x86 code that presumably should be #ifdefed in a
>> more subtle manner.
>>
>> Most of the patches are not AArch64 specific but are general issues that
>> I hit during the porting process. I was building with gcc 4.8 on Ubuntu
>> Trusty.
>>
>> The port requires using --enable-dlopen --disable-custreloc as the
>> branch range on AArch64 is +/-128MB and the heap soon gets too large
>> to branch between the loaded code objects. The maxpage tweak was an
>> effort to avoid that issue but it just delayed the inevitable.
>>
>
> More on your patches later, but dlopen is really a last resort.  The
> limitation on open file descriptors alone makes it almost useless for
> acl2.  We have many custreloc targets making use of some sort of
> trampoline, and I'd be happy to implement the same here, if machine
> access can be made available.  The quickest though non-optimal custreloc
> port is usually via some -mlongcalls switch to gcc.  Is this available
> here?

gcc aarch64 does not have -mlong-calls, and the closest equivalent,
-mcmodel=large is incompatible with PIC. Could you point me to the
code where other architectures implement trampolines? I had expected
to find something like that but it wasn't obvious to me where the work
was done.

I'm not sure if anyone has made publically available hardware yet.
There is a Debian port (and also Ubuntu) in the works for aarch64 but
I am not aware of any porter boxes. There's a qemu port, but I imagine
that would be painfully slow for this purpose.

-- 
Will Newton
Toolchain Working Group, Linaro