On 14 August 2014 23:59, Camm Maguire <[email protected]> wrote: > Greetings! And thanks so much again for your feedback here. > > Will Newton <[email protected]> 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 [email protected] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- Will Newton Toolchain Working Group, Linaro _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
