Ludo Brands wrote:
Now tested with a non-trivial program on both ARM on Qemu and running
natively on an NSLU2 "Slug" (describes itself as XScale-IXP42x, for
completeness little-endian). No obvious issues on either ARM or SPARC.
Good. I've been running lazarus a while on Debian etch on a qemulated Sparc
without any problems neither (other than waiting for the 250 bogomips to
move on).
The speed of emulated or low-resource systems is obviously a problem- I
put some informal benchmarks on the wiki page I did a few weeks ago when
I was putting Qemu on a development system with ARM, Mipsel and so on.
At one point I thought I saw something nasty happen when I switched
(KDE) desktops during a build, but either that was spurious or your
recent fixes have cured it.
Do you think you could explain why you started having
alignment problems
on x86 Solaris when x86 Linux is OK? And what does
FPC_REQUIRES_PROPER_ALIGNMENT actually do- I noticed it when
I started
working through the MIPS code generation.
The FPC_REQUIRES_PROPER_ALIGNMENT define indicates that the cpu requires
aligned data. This define causes several type definitions to be non packed.
Packed records can violate alignment constraints.
So if I understand that correctly, that define is telling the compiler
that it should always arrange data structures so that fields are
aligned. It's obviously not in control of structures which are forced in
some way, or of explicit pointer arithmetic.
The compiler sets FPC_REQUIRES_PROPER_ALIGNMENT for Solaris, independent of
the cpu used. So, fe. TPropData is packed on x86 linux and aligned on x86
solaris.
I suspected that might be the case, but was hoping for confirmation from
somebody who knew what he was doing :-)
The first series of lazarus crashes seen on solaris x86 and solaris
sparc are linked to the fact that lazarus assumed TPropData to be aligned
and did some pointer arethmic to get to the different record members. Since
the alignment put the record members (pointers in this case) on a different,
aligned, location, x86 crashed with a wrong pointer (SIGSEGV) and sparc with
an unaligned access (SIGBUS). In other words, if the compiler hadn't set
FPC_REQUIRES_PROPER_ALIGNMENT for solaris x86 then these problems wouldn't
have popped up.
The second type of alignment problems as seen in synregexpr didn't raise
their head on solaris x86 because the data is simply unaligned. No wrong
pointers. Synregedit uses pointer arithmetic to create and run a kind of
state machine and doesn't have a notion of alignment. So a lot of unaligned
data but solaris x86 doesn't bother. Sparc and Arm do. The patch I made for
synregexpr assures proper alignment for pointers in the state machine data
structure.
So in other words it was a typical multiple-cause bug. Presumably
x86-Solaris aligns data by convention in order to be as compatible as
possible with the OS running on SPARC.
Time will tell whether Oracle choose to push SPARC and Solaris. My
suspicion is that they will, in which case this work means we're ready
for 'em.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
