Found the cause of the crash of the IDE on Solaris x86 when closing a project: in procedure Search in TProject.UpdateUnitComponentDependencies (ide/project.pp) some pointer arithmetic is used assuming TTypeData is packed. This is not the case for solaris x86.
Snippet:

PropInfo:=PPropInfo(PByte(@TypeData^.UnitName)+Length(TypeData^.UnitName)+1)
;
      // read property count
      CurCount:=PWord(PropInfo)^;
      inc(PtrUInt(PropInfo),SizeOf(Word));
      // read properties
      while CurCount>0 do begin
        // point PropInfo to next propinfo record.
        // Located at Name[Length(Name)+1] !
        if (PropInfo^.PropType^.Kind=tkClass) then begin

Curcount is ok
PropInfo+SizeOf(Word) causes PropInfo^.PropType^.Kind to crash. It's 2 bytes off.

Where should I report this bug? FPC or Lazarus. The latter I guess?

Ludo

To be more precise TPropData is assumed packed.

Ludo

The define FPC_REQUIRES_PROPER_ALIGNMENT and the types TTypeData and TPropData are definitely FPC and not Lazarus, so you should report it as a FPC bug.

Regards,
Sven

But lazarus is assuming they are packed...

Rtl/objpas/typinfo.pp contains some helper functions to get PropInfo from Typeinfo. They are using constructs like
PPropInfo(aligntoptr(pointer(@Result^.Name)+byte(Result^.Name[0])+1));. Shouldn't Lazarus do the same?

Ludo

Sven Barth wrote

The define FPC_REQUIRES_PROPER_ALIGNMENT and the types TTypeData and TPropData are definitely FPC and not Lazarus, so you should report it as a FPC bug.

To me the problem is clearly in Lazarus.

Hi,

I'm starting this thread on Lazarus forum to report issues and also suggested fixes my team has made for Indy 10.2.0.3 on Debian/Linux (Lazarus 0.9.30, FPC 2.4.2.) while working for my projects. <http://wiki.lazarus.freepascal.org/Indy_with_Lazarus>

Link - http://forum.lazarus.freepascal.org/index.php/topic,13717.new.html

Thanks.
Joshua Lim

I'm working on a patch that uses GetPropList instead of walking through TPropData. GetPropList is one of the helpers in Rtl/objpas/typinfo.pp and knows about the alignment.

Ludo

I wonder if this is related to the problems I've been experiencing on SPARC and ARM (both Linux)? Bug 0019109.

Yes, my mistake. I've misread Ludo's mail.

Regards,
Sven

Without jumping to too fast conclusions like with my mail above, it could be so.

Regards,
Sven

I wonder if this is related to the problems I've been experiencing on SPARC and ARM (both Linux)? Bug 0019109.

Hadn't seen that bug. The backtrace is identical to the one I'm seeing. Working on a patch.

Ludo

The patch is attached to http://bugs.freepascal.org/view.php?id=19109

Ludo

Ludo Brands wrote

The patch is attached to http://bugs.freepascal.org/view.php?id=19109 Ludo

I'll try to test that later, eventually on both SPARC and ARM Linux, but today- for various reasons- is going to be very busy and difficult so I crave indulgence.

One interesting thing is that I notice that the problem on ARM fails to trigger a count in /proc/cpu/alignment, I've been tinkering with various values on both Qemu and native.

There is no urgency. It's working for me and I can continue testing Lazarus on Solaris.

With values you mean as in "echo value > /proc/cpu/alignment" ? Default is to ignore alignment errors.

Ludo

Yes, as in setting it to (working from memory) 3 which should fix+warn.

Initial testing (SPARC/Linux, not yet ARM) seems to indicate that the exception on exit is fixed, but I'm still getting a problem when opening an existing project. With the major caveat that compiler is still 2.4.2.

[TJITForms.DoCreateJITComponent] Error Error: CreateNewClass new aligned TypeData
Stack trace:
$00719F38 TJITCOMPONENTLIST__CREATENEWJITCLASS, line 1473 of /usr/local/share/lazarus-newstable/designer/jitforms.pp $00716764 TJITCOMPONENTLIST__ADDJITCOMPONENTFROMSTREAM, line 908 of /usr/local/share/lazarus-newstable/designer/jitforms.pp $0073C9E8 TCUSTOMFORMEDITOR__CREATERAWCOMPONENTFROMSTREAM, line 1393 of customformeditor.pp
$000AC900 TMAINIDE__DOLOADLFM, line 6637 of main.pp $000ABBE0 TMAINIDE__DOLOADLFM, line 6182 of main.pp $000B8EE4 OPENRESOURCE, line 8680 of main.pp
$000B8C44 TMAINIDE__DOOPENEDITORFILE, line 8935 of main.pp $000C01B4 TMAINIDE__DOOPENPROJECTFILE, line 10297 of main.pp $0009ECF8 TMAINIDE__MNUOPENPROJECTCLICKED, line 3827 of main.pp $006A7C64 TIDEMENUITEM__MENUITEMCLICK, line 552 of menuintf.pas $006AC868 TIDEMENUCOMMAND__MENUITEMCLICK, line 1623 of menuintf.pas $0024814C TMENUITEM__CLICK, line 75 of ./include/menuitem.inc $00248AC0 TMENUITEM__DOCLICKED, line 269 of ./include/menuitem.inc $00036164 TOBJECT__DISPATCH, line 472 of
/usr/local/src/fpc/fpcbuild-2.4.2/fpcsrc/rtl/inc/objpas.inc $00350B80 DELIVERMESSAGE, line 112 of lclmessageglue.pas $00314494 DELIVERMESSAGE, line 3528 of gtk2proc.inc $003C90A4 GTK2MENUITEMACTIVATE, line 138 of gtk2wsmenus.pp TCustomFormEditor.JITListException List.CurReadStreamClass=nil TUnitInfo

I haven't run into that one. , the code checks whether the PTypeData points to the location after Typeinfo.name and raises the exception if it isn't the case. To be confirmed by the developer that wrote the code but I guess the purpose was to anticipate alignment problems such as the one I fixed. If that is the case then the check could simply be removed.

While I was trying to provoke a misalignment in jitforms.pp by changing the name of the component I ran into another alignment problem in StdCodeTools. Yet another location where pointer arithmetic is used to get ppropinfo from typedata. I guess we'll have to weed them out as they are encountered...

Ludo

Was able to reproduce the problem. Just a matter of component name length.

I removed the check in jitforms.pp (comment line 1471 to 1473, if .. then raise ... ) and at first sight that solves this problem. A confirmation about the purpose of the check from one of the developers would be helpfull. Still working on the problem in StdCodeTools.

Ludo

Still working on the problem in StdCodeTools.

Attached patches to http://bugs.freepascal.org/view.php?id=19109. I suggest you keep this bug open for a while and that we attach alignment fixes as we encounter them.

Just found another possible problematic piece of code in jitforms.pp in function ClassTypeInfoAsString. Others in ide\emptymethodsdlg.pas and ideintf\propedits.pp ...

tbc

Ludo

With those three patches applied basic operation appears OK, but I might now be seeing different behavior on the three systems I'm testing.

First, on ARM Linux (Debian "Squeeze") running in the context of Qemu I am able to build a non-trivial program (several units, background thread, database access) which runs successfully. I've not yet tested debugger access etc.

Second, on SPARC Linux (Debian "Lenny") running on a Sun Ultra-1 with a minimal project (button on form -> close) I get this during "Build All":

Compiling project1.lpr
Compiling unit1.pas
unit1.pas(16,25) Hint: Parameter "Sender" not used Assembling unit1
Assembling project1
Compiling resource /home/markMLl/lib/sparc-linux/project1.or

Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7fa5aa0 (LWP 3925)]
0x00686ee8 in TREGEXPR__EMITNODE (OP=6 #6, this=0xf6129660) at synregexpr.pas:1507
1507 PRENextOff (regcode)^ := 0; // Next "pointer" := nil (gdb) bt
#0 0x00686ee8 in TREGEXPR__EMITNODE (OP=6 #6, this=0xf6129660) at synregexpr.pas:1507
#1 0x00687b3c in TREGEXPR__PARSEBRANCH (FLAGP=0, this=0xf6129660) at synregexpr.pas:1820
#2 0x00687790 in TREGEXPR__PARSEREG (PAREN=0, FLAGP=1, this=0xf6129660) at synregexpr.pas:1756
#3 0x006873d4 in TREGEXPR__COMPILEREGEXPR (EXP=0xf5d700d0 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+',
this=0xf6129660) at synregexpr.pas:1669
#4 0x00686b3c in TREGEXPR__COMPILE (this=0xf6129660) at synregexpr.pas:1423 #5 0x00686c74 in TREGEXPR__ISPROGRAMMOK (this=0xf6129660) at synregexpr.pas:1448
#6 0x0068e588 in TREGEXPR__EXECPRIM (AOFFSET=1, this=0xf6129660) at synregexpr.pas:3453
#7 0x0068e550 in TREGEXPR__EXECPOS (AOFFSET=1, this=0xf6129660) at synregexpr.pas:3414
#8 0x007f6638 in SYNREMATCHES (
THETEXT=0xf5a81e78 'Compiling resource
/home/markMLl/lib/sparc-linux/project1.or',
REGEXPR=0xfab824 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', MODIFIERSTR=0xf48388 'I', STARTPOS=1)
at sourceeditprocs.pas:729
#9 0x0057be58 in REMATCHES (
THETEXT=0xf5a81e78 'Compiling resource
/home/markMLl/lib/sparc-linux/project1.or',
REGEXPR=0xfab824 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', MODIFIERSTR=0xf48388 'I', STARTPOS=1)
at texttools.pas:121
#10 0x005d8560 in TIDEMSGQUICKFIXITEM__ISAPPLICABLE (LINE=0xf613b820, this=0xf65c9f60) at idemsgintf.pas:450
#11 0x008570ec in TMESSAGESVIEW__UPDATEMSGICONS (this=0xf60b1b70) at msgview.pp:1185
#12 0x008562e4 in TMESSAGESVIEW__IDLETIMER1TIMER (SENDER=0xf600b220, this=0xf60b1b70) at msgview.pp:957
#13 0x0025ad0c in TCUSTOMTIMER__DOONTIMER (this=0xf600b220) at customtimer.pas:181
#14 0x0025ac30 in TCUSTOMTIMER__TIMER (this=0xf600b220) at customtimer.pas:156
#15 0x00327028 in GTKTIMERCB (DATA=0xf61c2c20) at gtk2callback.inc:2406 #16 0xf787cb40 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0xf787cb40 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I don't know what to make of the "corrupt stack" messages which resemble something from an older version which had debugging record errors. They might be a red herring since lazbuild and generated code are OK on this system.

Third, on ARM Linux (Debian "Lenny") running natively on an NSLU2 "Slug" I appear to get a failure building a program. This is using Lazarus built on the Qemu system (building natively takes an unacceptable length of time), I don't yet have a backtrace etc. on account of slow operation on this system (work continues).

Great.

Before I forget, I have created a patch for clocale which has been committed in svn 17919. Before the patch exceptions where created in functions like DateToStr.

This probably indicates an alignment error.

[Switching to Thread 0xf7fa5aa0 (LWP 3925)] 0x00686ee8 in TREGEXPR__EMITNODE (OP=6 #6, this=0xf6129660) at synregexpr.pas:1507 1507 PRENextOff (regcode)^ := 0; // Next "pointer" := nil

regcode is a PCHAR, PRENextOff is ^PtrInt. So, yes, that is asking for non-aligned access? There are several similar constructs in SynRegExpr. That is going to be a non-trivial fix, I'm afraid.

Perhaps stackframes removed. But there you are already in glib. The lazarus routine is triggered by a timer and, if I understand this correctly, you are in the routine that is scanning the messages window and puts icons in front of the messages. Here it is looking for "Unit x not used in y" messages. You can check "Hide Messages Icons" in Tools/IDE Options/Window to get around this one, for the time being.

Tbc

Ludo

Here's what I get running natively on ARM, with a minimal project (button on form -> close). As far as possible I've tried to do this identically on all systems, i.e. save files with default names in ~ then Build All:

Assembling unit1

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40c50070 (LWP 2095)]
0x005b0e8c in TREGEXPR__REGNEXT (P=0x4c697f22 <Address 0x4c697f22 out of bounds>, this=0x41916ba0)
at synregexpr.pas:2785
2785 offset := PRENextOff (p + REOpSz)^; //###0.933 inlined NEXT (gdb) bt
#0 0x005b0e8c in TREGEXPR__REGNEXT (P=0x4c697f22 <Address 0x4c697f22 out of bounds>, this=0x41916ba0)
at synregexpr.pas:2785
#1 0x005acfa0 in TREGEXPR__TAIL (P=0x41697f22 #11, VAL=0x41697f4c '', this=0x41916ba0) at synregexpr.pas:1471
#2 0x005adc88 in TREGEXPR__PARSEBRANCH (FLAGP=1, this=0x41916ba0) at synregexpr.pas:1832
#3 0x005ad8dc in TREGEXPR__PARSEREG (PAREN=0, FLAGP=1, this=0x41916ba0) at synregexpr.pas:1756
#4 0x005ad584 in TREGEXPR__COMPILEREGEXPR (EXP=0x41e92ac0 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+',
this=0x41916ba0) at synregexpr.pas:1669
#5 0x005acdb0 in TREGEXPR__COMPILE (this=0x41916ba0) at synregexpr.pas:1423 #6 0x005acee4 in TREGEXPR__ISPROGRAMMOK (this=0x41916ba0) at synregexpr.pas:1448
#7 0x005b308c in TREGEXPR__EXECPRIM (AOFFSET=1, this=0x41916ba0) at synregexpr.pas:3453
#8 0x005b3050 in TREGEXPR__EXECPOS (AOFFSET=1, this=0x41916ba0) at synregexpr.pas:3414
#9 0x006eab60 in SYNREMATCHES (THETEXT=0x42525288 'Assembling unit1', REGEXPR=0xcc9ea8 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', MODIFIERSTR=0xc6b824 'I', STARTPOS=1)
at sourceeditprocs.pas:729
#10 0x004c8720 in REMATCHES (THETEXT=0x42525288 'Assembling unit1', REGEXPR=0xcc9ea8 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', MODIFIERSTR=0xc6b824 'I', STARTPOS=1)
at texttools.pas:121
#11 0x00514ebc in TIDEMSGQUICKFIXITEM__ISAPPLICABLE (LINE=0x41b041e0, this=0x41533690) at idemsgintf.pas:450
#12 0x0073ef24 in TMESSAGESVIEW__UPDATEMSGICONS (this=0x41a5a780) at msgview.pp:1185
#13 0x0073e2c4 in TMESSAGESVIEW__IDLETIMER1TIMER (SENDER=0x41c87be0, this=0x41a5a780) at msgview.pp:957
#14 0x0021a944 in TCUSTOMTIMER__DOONTIMER (this=0x41c87be0) at customtimer.pas:181
#15 0x0021a884 in TCUSTOMTIMER__TIMER (this=0x41c87be0) at customtimer.pas:156
#16 0x002cb2ac in GTKTIMERCB (DATA=0x4187bfb0) at gtk2callback.inc:2406 #17 0x405e4c04 in ?? () from /usr/lib/libglib-2.0.so.0

There might be others related to UI events, e.g. I think I saw one earlier when I switched (KDE) desktops during a build. However at present I'm trying to be consistent.

This is one of the many "use char^ as pointer^" in synregexpr I refered to in my previous message. Turn of the message icons to compile the program. Running the program from inside the IDE hits this point, even with message icons turned off. Why??

Ludo

Turn of the message icons to compile the program.

I was wrong. Turning off the message icons still does the call to regex...

Ludo

Mark,

Attached is a patch to components/synedit/synregexpr.pas that fixes alignment issues. I've tested the code against a test unit (attached) that is a mix of fpc/packages/regexpr/examples/testreg1.pp and Demos/SelfTest/TestRegExpr.drp (from the official TRegExpr package). The result is the same for aligned and non-aligned platforms (error 120,121,122,123,124 and 703). This tests only that my changes have not introduced a new bug, but, since I'm testing on Solaris x86, I can't be sure that all data is aligned properly. It's possible I've missed something. I've tried to set the AC cpu flag to force alignment checking but that generates alignment errors in libc :(

Could you please test this on one of your sparc/arm systems?

Thanks, Ludo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testregexpr.lpr
Type: application/octet-stream
Size: 23035 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110706/629777fa/attachment-0002.obj> -------------- next part --------------
A non-text attachment was scrubbed...
Name: align_synregexpr.diff
Type: application/octet-stream
Size: 9657 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110706/629777fa/attachment-0003.obj>

I've tested the patch on a "qemulated" sparc debian and it works fine with the test unit. QEMU sparc does generate SIGBUS for unaligned data (contrary to QEMU ARM). A small testprogram (unaligned integer) confirmed that.

Ludo

Not using Qemu for SPARC here- got the real thing in abundance :-) I can't help but wonder whether Qemu ARM ignores alignment issues because of the CPU it's emulating or simply because the coder didn't notice the restriction. More tomorrow.

it for host CPU's that didn't check alignment. Recent ARM processors apparently don't bother about alignment anymore by default, apart from the speed impact. So there is no real incentive anymore to implement the alignment check.

Ludo

Looking good. Very well done, sir :-)

Applied (with a very minor manual intervention) to 0.9.30 with 2.4.2 on an UltraSPARC running Debian "Lenny". Result successfully compiled etc. a non-trivial program (couple of background threads, quite a lot of database activity).

Will apply to ARM later and build on Qemu, then test the binary on an NSLU2 "Slug" which is known to be sensitive to alignment issues. I'll probably not have result until tomorrow, but suggest that the patch as it stands is worth adding to the bug report to get it into the record.

Patch and test unit added to the bug report.

Ludo

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.

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.

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 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.

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. 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.

Ludo

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.

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 :-)

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.

Do you have an Url for that 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.

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.

Ludo

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.

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.

Thanks, noted.

http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators

Interesting.
I found that the qcow format is slowing installation a lot. The filesystem spends more time growing the qcow disk than anything else. The raw format is faster.

QEMU comes now with an integrated VNC server. The problem is that the OPENBIOS used for sparc supports only 8 bit or 24 bit color depths while the debian suntcx driver doesn't support 24 bits. Leaves the 8 bit which lazarus doesn't support. VNC doesn't change that.

The QEMU build in VNC server for arm works well but gives you the small resolution of the versatilepb board.

On both arm and sparc I'm using XFCE which is quite lean also. I noticed very little difference in speed when running lazarus with X transported over ssh (no windowmanager running on the guest) or running in a windowmanager. The cpu time spent in ssh/sshd transferring the X packets roughly equals the cpu time spent by the window manager dealing with them. The advantage of ssh is the increased resolution/color depth. For the arm limited to 256M memory, not running a windowmanager gives you also more precious memory.

I noticed that the small hints that pop up when you hover over about anything are very costly. The cause a lot of painting and repainting.

I just uploaded another patch for syneditmiscclasses.pp. When you cut a text in one unit and paste it in another unit a sigbus exception was thrown. A char pointer cast to an integer pointer.

Ludo

Yes, but that VNC is in the IP space of the host, and having multiple sessions (e.g. multiple guests of different types, or multiple sessions from a single guest) gets messy. I tend to use it only if the guest is Windows, although on one version of Qemu I've got here it occasionally screws the (Windows guest) mouse pointer necessitating a reboot.

Again, running a guest (rather than host) Qemu should allow you to specify the size, since it doesn't refer to the emulated hardware or (the equivalent of) a BIOS or OBP. I run 16-bits as standard, I've not checked whether that's what I actually get but visually I see no obvious problems.

256M? Luxury! I'm not saying that this is a sensible thing to attempt, but Lazarus will just about run in FluxBox on a 32Mb "Slug".

In that case it must have been fixed. You'd have noticed :-)

I just uploaded another patch for syneditmiscclasses.pp. When you cut a text in one unit and paste it in another unit a sigbus exception was thrown. A char pointer cast to an integer pointer.

Thanks, I'll get it presently.

Not sure what you mean with "guest Qemu" and "host Qemu" . Is that what Qemu calls "User Mode Emulation" and "Full System Emulation"? qemu-arm vs qemu-system-arm?

Ludo

That was a typo. I meant to say that a guest VNC (i.e. what I'm using) should allow you to specify the size and other parameters of the screen it is simulating, while the host VNC (i.e. provided by Qemu, which is what you're using) is generally defined by the hardware being emulated and by its associated firmware (PC BIOS, Sun OBP etc.).

I typically find myself starting the Qemu and UML sessions I've described from an X session on the host, so that if they want to display their console in an xterm they can do so. I could probably tweak the parameters to prevent that, in general if I need a shell session I far prefer direct SSH since that gives me full control over presentation and minimises the performance hit.

If I understand things correctly "User Mode Emulation" (which I've not played with) allows you to run e.g. an ARM Linux program on a PC Linux host, while "Full System Emulation" allows you to emulate an entire computer.

OK Got it. VNC server comes with a pseudo graphics card driver. Its probably slower than the build in VNC server since the first runs on the emulated cpu.

Correct. Downside is that you need all the arm libraries used by the program on the PC host.

Ludo

I've tacked some scripts etc. onto the wiki page I mentioned earlier.

http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators

They work well for me, except for an ARM guest.

Ludo Brands wrote

VNC server comes with a pseudo graphics card driver.

Off topic: I am searching for this since some time.

Can you elaborate on how to get/use it ?

Thanks,
-Michael

On a system dedicated to cross-development and the hosting of emulation environments, something like FatELF http://icculus.org/fatelf/ could be worthwhile.

Problem is that host and guest are in most cases running a different version or even a different distribution of linux. Above is fine for distributing one binary of a specific library for, say, 32 and 64 bit versions.

In the mean time I got the user emulation mode working in a chrooted environment. The performance improvement for graphics is spectacular. Using lazarus on sparc in user emulation is really comfortable compared to full system emulation. Startup is twice as fast but the real difference is in doing X intensive stuff like the pop-ups mentioned before, editing forms, etc.

If you don't mind I'll update the Qemu wiki page to add the instructions on how to create and run the chrooted environment. It is a small effort for the initial set up but the payback in productivity is enormuous.

Ludo

Sounds good. By all means update the page- that's what it's there for :-)

Updated.

Ludo

I'll try to spend some time with that as soon as I've got any- things have cropped up here that are likely to occupy me for about the next week hence no progress on SPARC/Solaris.

I've just tacked some text into
http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators which describes setting up audio and MIDI support for a Windows 2000 guest (we use MIDI heavily here to keep track of what application servers think they're doing). It's really not very good, but is the result of experimentation I've had to do over the last couple of weeks due to a server crash.

I'll revisit it in the morning, and will also see if I can get a (Linux) guest to see a physical USB device.

I'd much appreciate it if anybody with relevant experience could help knock the article into shape.

Mark Morgan Lloyd wrote

I'll revisit it in the morning, and will also see if I can get a (Linux) guest to see a physical USB device.

qemu ... -usb host:DEVICEID:VENDORID ...

should do it. I don't know whether this is supported on Windows hosts as well.

On Linux you need to have access rights to the device in /dev/bus/usb/BUSID/DEVID.

You can get DEVICEID, VENDORID, BUSID and DEVID by doing a "lsusb". The output looks like this:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0ccd:0039 TerraTec Electronic GmbH Grabster AV 400 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 04a9:190a Canon, Inc. CanoScan LiDE 210 Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Consider the fourth line for example:
- BUSID: 001
- DEVID: 002
- VENDORID: 0ccd
- DEVICEID: 0039

Regards,
Sven

Or host:bus.id as an alternative. Haven't yet checked whether a Lazarus project compiled inside a guest works.

Ok, that is a new one (for me), but at least the DEVICEID:VENDORID approach will continue to work if you plug the device into a different port.

Regards,
Sven

Yes, but I don't know what would happen if you had multiple devices with the same identifier. The example I've used is for a Velleman K8055 board where the ID is set by jumper, but this is fairly unusual.