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

[Mark Morgan Lloyd]

Ludo Brands wrote:
>> 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.
> 
> Do you have an Url for that page? 

http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators although I 
suspect that there's not much in it that you're not doing already. I 
hacked it together when I was setting up the system since it's probably 
not every day that somebody does it from scratch. Benchmarks on the 
discussion page.

> On Qemu sparc I'm stuck with debian etch (gdb too old => dead lock with
> lazarus) since lenny is compiled for v8+. Display is limited at 8-bit which
> lazarus doesn't support. Only solution that is working for me is a reverse
> ssh tunnel, tunneling X11 and no encryption (else ssh and sshd cpu usage
> goes through the roof with lazarus). 
> Similar solution for Qemu arm where the low screen resolution of the
> versatilePB platform makes running lazarus impossible. On arm lenny is
> running and debugging in lazarus works fine.

But in the case of SPARC-on-Qemu you should be able to use VNC 
(specifically, Debian's vnc4server package), in conjunction with FluxBox 
as desktop/wm it's fairly lean and performs well. The machine in front 
of me is a (real) SPARC running Etch, thanks to your patches 
0.9.30+2.4.2 are now running fine on it so there's a fair chance the 
same would apply to an emulated system; I'm in no great hurry to update 
this system to a later OS but am overdue for going round everything and 
getting onto 2.4.4.

ARM is more of a problem since vnc4server is not ported to it, I believe 
that there are some ARM-specific problems in the VNC sources. There's a 
different server that does run on it (from memory, tightvncserver) but 
it appears to be hardcoded to expect the display manager to be xdm- I 
prefer gdm since it's the only one with a reliable XDMCP implementation.

In either case you /should/ be able to connect to the system using 
XDMCP, e.g. using Xnest on your local system and gdm+FluxBox on the 
headless one, subject to your network setup since XDMCP is a UDP-based 
protocol which implies that broadcasts don't route well. However at one 
time (I don't know whether this is fixed) Lazarus and some other apps 
performed very badly using networked X, my recollection is that the 
consensus was that there was excessive input-device polling.

>> 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 other way around. The compiler aligns data for all processors even when
> it is not mandatory for the processor. This is for speed. The packed
> directive tells the compiler to not align the data. The compiler sets
> FPC_REQUIRES_PROPER_ALIGNMENT for the programmer. He should use this to
> conditionally define packed structures or think twice when casting fe. pchar
> to pword.

Thanks, noted.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]