[Lazarus] RE : RE : RE : RE :RE:RE:FPC_REQUIRES_PROPER_ALIGNMENTdefinedonSolariscausescrashinlazarus

[Mark Morgan Lloyd]

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]