Re: [Gcl-devel] aarch64

[Will Newton]

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