[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] aarch64
From: |
Will Newton |
Subject: |
Re: [Gcl-devel] aarch64 |
Date: |
Fri, 15 Aug 2014 09:15:53 +0100 |
On 14 August 2014 23:59, Camm Maguire <address@hidden> wrote:
> Greetings! And thanks so much again for your feedback here.
>
> Will Newton <address@hidden> writes:
>
>> Pointers are always 8 bytes and naturally aligned. The problem was
>
> Great! Wanted: a reliable configure test to check for possibly
> 'unnaturally aligned' pointers on the stack. Tried some obvious C to no
> avail.
>
>>> 2) Should aarch64 use arm-linux.h, like the other 64bit versions of
>>> older 32bit machines? I'm confused about the arm/aarch nomenclature.
>>
>> It is pretty confusing. ;-)
>
> OK leaving a separate file.
>
>>> 3) Thanks for the work on the print_isns, but I don't have this working
>>> in any useful fashion for anything but x86 at the moment. I can
>>> elaborate if interested.
>>>
>>> 4) no SGC?
>>
>> Hmm, I thought I had enabled that. I believe it does work.
>
> I'm having seemingly unrelated uncontrollable segfaults on my machine,
> and gdb is broken, so I'm leaving it out for now. Would be nice if
> someone with real hardware could define it and see if it breaks.
>
>>
>>> 5) You have some reloc entries like
>>>
>>> + store_val(where,MASK(19) << 5, (s & 0x1ffffc) << 3);
>>>
>>> Since the last shift differs from that applied to the mask, this will
>>> miss the ending bits in the 19bit range. Is this what you intend?
>>
>> I think so. ;-)
>>
>> The bottom two bits are stored at bits 30:29, and the remaining 19
>> bits are stored at 23:5 so we have already masked off the bottom two
>> bits so just need to shift up 3 to get everything aligned with the
>> opcode field.
>
> OK.
>
> Separately, CALL26/JUMP26 can have an addend right? They seem to be all
> 0.
Yes, there is an addend - relocs are RELA on AArch64, but I would not
expect a non-zero addend on branches very often as it would imply
jumping into the middle of a function.
>>
>>> 6) I'm not sure what the libgcc issue is, but it is reminiscent of the
>>> situation on hppa, which we solve by linking it in statically. Please
>>> let me know if this is not OK for some reason.
>>
>> I think the problem is that linking statically with a .a file links
>> only the functions that are actually used and discards the rest so
>> only the symbols that are used initially are available and if code is
>> loaded that needs other symbols it will fail to link. Dynamic linking
>> means that all the symbols will be available.
>>
>
> Do you recall what symbols wound up missing?
Arithmetic helpers e.g. __umodsi3/__modsi3, or floating point helpers.
>>> The current implementation uses an 'ldr/br' sequence, requiring two
>>> extra words per 26bit call. Its weak in the sense that the space really
>>> required is much less than this, yet there is a circular dependency in
>>> that the loaded memory location depends on the size, which depends on
>>> the location if optimal. Left for another day.
>>>
>>> I'll be starting an acl2 build soon and see where we stand.
>>
>> Thanks, hope it works!
>
> Seems to so far :-).
>
> Take care,
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
Will Newton
Toolchain Working Group, Linaro