VBCC: building a TextEdit syntax plugin for OS3.2

[phx]

Originally Posted by boemann

Yes the released version of TextEdit is built with near model - I've since changed it but too late for the release but it will be fixed in 3.2.1

Thanks.
Although I would have hoped that TextEdit can still be built with the near model for best performance. There is probably just a

__saveds

missing somewhere?

Originally Posted by alkis

__saveds makes C compiler call __geta4() or something similar (see http://franke.ms/cex/z/7736WY for gcc)
(...)
There are two different programs __saveds will restore a4 to two different values. Plugin's functions' __saveds with set A4 to say value1 and __saveds functions in TextEdit will set A4 to value2.

But that doesn't matter, does it?

__saveds

does not only restore A4 for the current program's context, but it also saves its previous value and restores it on exit. The example you linked above shows that, and other compilers (like vbcc) behave exactly the same. This shouldn't be a problem for TextEdit, when calling a hook. A4 will be unmodified after the call.

[alkis]

Originally Posted by phx

But that doesn't matter, does it?

__saveds

does not only restore A4 for the current program's context, but it also saves its previous value and restores it on exit. The example you linked above shows that, and other compilers (like vbcc) behave exactly the same. This shouldn't be a problem for TextEdit, when calling a hook. A4 will be unmodified after the call.

The only "logical" point to cause a problem is if
https://gitlab.com/boemann/texteditf...example.c#L129
this call is in TextEdit's code which expect near model and HighlightSetFormat is missing __saveds

[phx]

Originally Posted by alkis

https://gitlab.com/boemann/texteditf...example.c#L129
this call is in TextEdit's code which expect near model and HighlightSetFormat is missing __saveds

I realised that

HighlightSetFormat()

is a new function of texteditor.library, so I thought it was safe. But when this call somehow ends in the original TextEdit context, then you are right!

And then this function (or the function in TextEdit which is called by it) would need fixing with

__saveds

. You're absolutely correct.

[boemann]

Originally Posted by phx

Thanks.
Although I would have hoped that TextEdit can still be built with the near model for best performance. There is probably just a

__saveds

missing somewhere?

For some of my callbacks yes, but those are not exposed to you guys yet so shouldn't be what causes the problems although I'll be sure to fix it though before making the next part of the plugin API public

The HightLightSetFormat is a library function in the texteditor.gadget library and not part of TextEdit (the program).

And although that function is not __saveds either it doesn't actually use any global values in the texteditor.gadget (there aren't any)

[boemann]

Originally Posted by phx

I realised that

HighlightSetFormat()

is a new function of texteditor.library, so I thought it was safe. But when this call somehow ends in the original TextEdit context, then you are right!

And then this function (or the function in TextEdit which is called by it) would need fixing with

__saveds

. You're absolutely correct.

Nothing in TextEdit or the plugin is called _by_ HighlightSetFormat

[phx]

Looks like a real mystery then. I would be curious to debug that.
Maybe guy lateur comes up with some new information.

[alkis]

How many instances do those plugins get? Multiple? Is plugin considered "resident" or does it get loaded separately for each time? Cause we might hit another problem that way...

[boemann]

It is loaded once by TextEdit, and as far as settings is concerned there should be only one setting.

The highlighter however can be called by many different texteditor.gadgets (if you have more than one file open) and you can also make no assumption about the order of the lines it is called on.

[alkis]

gcc's note on __saveds

Please do not use this attribute in pure executables. This is because several invocations of pure executables can run concurrently, each one having its own data section, and there is no way to find out to which of these sections should ‘a4’ be set.

(Couldn't tell from previous response, if plugin is loadseg'd once for all instances or once for each instance, so I don't know if this is relevant)

[boemann]

ah no TextEdit is not pure

[phx]

Originally Posted by alkis

gcc's note on __saveds

Please do not use this attribute in pure executables. This is because several invocations of pure executables can run concurrently, each one having its own data section, and there is no way to find out to which of these sections should ‘a4’ be set.

Although this is more a shortcoming of gcc's resident startup. It is possible to deal with

__saveds

in such executables, and it works with SAS/C and vbcc.

[guy lateur]

Ok, I did some more testing, and something quite weird is going on. As suggested, I'm trying to build the most basic plugin that gets detected by TextEdit without crashing it or bringing the whole system down. I've not succeeded so far.

I've attached my code (entire

master

folder). It includes the object files, the resulting plugin and the output from

make

(which I've also pasted below). As before, the whole system freezes as soon as TextEdit is started.

Here's the

init()

function:

static void init(APTR userData)
{
    //openLibs();

    struct Filetype *fType = (struct Filetype *)userData;
    //struct Hook *hook = (struct Hook *)AllocVec(sizeof(struct Hook), MEMF_CLEAR);

    //fType->pluginData = (ULONG)1234567; // any number or pointer of our choosing
    //fType->highlighterHook = hook;
    
    fType->typeName = "example";
    fType->autoFileTypes = "example";
    
    //fType->terminate = terminate;
    //fType->settingsTitle = settingsTitle;
    //fType->settingsGadget = settingsGadget;
    //fType->processGadgetUp = processGadgetUp;
    //fType->setSettingsFromGUI = setSettingsFromGUI;
    //fType->setGUIFromSettings = setGUIFromSettings;
    //fType->applySettings = applySettings;
    //fType->saveSettings = saveHighlightSettings;
    //fType->loadSettings = loadHighlightSettings;
    //fType->disposeGadgets = disposeGadgets;

    fType->name = "Example";

    //hook->h_Entry    = (ULONG (*)()) highlightBlock;
    //hook->h_SubEntry = NULL;
    //hook->h_Data = 1234567;
}

Here's the output from

make

:

vc -nostdlib -c99 -c example.c
>{
warning 68 in line 107 of "example.c": redeclaration of var <saveHighlightSettings> with new type
>{
warning 123 in line 107 of "example.c": formal parameters conflict with parameter-type-list
>{
warning 68 in line 114 of "example.c": redeclaration of var <loadHighlightSettings> with new type
>{
warning 123 in line 114 of "example.c": formal parameters conflict with parameter-type-list
>ULONG __saveds __asm highlightBlock(
warning 54 in line 120 of "example.c": ; expected
>ULONG __saveds __asm highlightBlock(
warning 67 in line 120 of "example.c": type defaults to int
>ULONG __saveds __asm highlightBlock(register __a0 struct 
warning 57 in line 120 of "example.c": , expected
>ULONG __saveds __asm highlightBlock(register __a0 struct Hook *h,register  __a2
warning 57 in line 120 of "example.c": , expected
>ULONG __saveds __asm highlightBlock(register __a0 struct Hook *h,register  __a2
warning 57 in line 120 of "example.c": , expected
vc -nostdlib -lamiga -ldebug -o exampleplugin pluginheader.o example.o

I have also tried setting

fType->pluginData

, then also assigning all functions that return nothing or NULL, then assigning all functions, and finally also uncommenting

openLibs()

. Everything gives the same result, ie the system freezes as soon as TextEdit is started.

For completeness, here's the output from

smake

(Camilla's example, built using SAS/C, which does work as expected):

	makedir tagfiles
	sc idlen=64 comnest streq strmerge nostkchk  		optimize opttime cpu=any debug=symbolflush noopt          params=register strsect=code mccons data=far  		IDIR=NDK32:Include_H pluginheader.c
Using options file "scoptions"
SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.

Compiler Phase 1 for "pluginheader.c"
No errors; No warnings; No user suppressed warnings
Compiler Phase 2 for "pluginheader.c"
Module size P=00000000 D=00000000 U=00000000 C=00000000 F=00000024 UF=0000000C

	sc idlen=64 comnest streq strmerge nostkchk  		optimize opttime cpu=any debug=symbolflush noopt          params=register strsect=code mccons data=far  		IDIR=NDK32:Include_H example.c
Using options file "scoptions"
SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.

Compiler Phase 1 for "example.c"
example.c 107 Warning 93: no reference to identifier "fType"
example.c 114 Warning 93: no reference to identifier "fType"

====================
    UWORD end = strlen(text);
example.c 125 Warning 100: no prototype declared for function "strlen"

====================
    hook->h_Data = 1234567;
example.c 171 Warning 225: pointer type mismatch
                           "void *" does not match "int"
No errors; 4 warnings; No user suppressed warnings
Compiler Phase 2 for "example.c"
Module size P=00000242 D=00000000 U=00000000 C=00000000 F=00000014 UF=00000000

	slink pluginheader.o example.o to exampleplugin.debug lib lib:scnb.lib NDK32:lib/amiga.lib NDK32:lib/debug.lib assert.lib addsym smallcode noicons batch smalldata  		map exampleplugin.map,fhx fwidth 32 pwidth 32 swidth 32
Slink - Version 6.58
Copyright (c) 1988-1995 SAS Institute, Inc.  All Rights Reserved.


SLINK Complete - Maximum code size = 668 ($0000029c) bytes

Final output file size = 29228 ($0000722c) bytes
	slink exampleplugin.debug to exampleplugin noicons nodebug
Slink - Version 6.58
Copyright (c) 1988-1995 SAS Institute, Inc.  All Rights Reserved.


SLINK Complete - Maximum code size = 668 ($0000029c) bytes

Final output file size = 808 ($00000328) bytes

I'm a bit at a loss as to how to continue with this. On a side note, my Vampire CF card died yesterday -- which is why it took me a while to get back here. I thought I'd take this 'opportunity' to set everything up in WinUAE, as that has a handy debugger. However, my install of OS3.2 on WinUAE is very unstable. Eg, TuiTED just crashes as soon as it is started, although it works perfectly fine on my Vampire OS3.2 installation. Maybe it has to do with me not being able to point WinUAE to ROM 3.2, I don't know, but it does appear to run a lot better (freshly reinstalled) on my Vampire (which does use ROM 3.2).

I'm just mentioning this because this means debugging this may not be as straightforward for me ATM as we had originally hoped. We can still do the

trap #0

approach, of course, but I'd prefer to have some more specific instructions on where to put those and how to proceed with that before trying that. I'd rather not spend another afternoon turning my Vampire off and on again without having anything to show for it afterward. I'm kinda hoping you guys spot something in the output of

make

that might tell us what the problem might be..

[phx]

Originally Posted by guy lateur

As before, the whole system freezes as soon as TextEdit is started.

Freezes? Wasn't it some kind of Guru before?
Anyway, it is essential to find out whether

init()

is called at all or whether it even returns before the problem occurs.

Here's the

init()

function:

As far as I understand TextEdit zeroes the

Filetype

structure before the call. So it should be ok to leave most of its fields uninitialised (Camilla, please correct me). Or are there any fields which absolutely require a value? Like the hook pointer?

>ULONG __saveds __asm highlightBlock(
warning 54 in line 120 of "example.c": ; expected
>ULONG __saveds __asm highlightBlock(
warning 67 in line 120 of "example.c": type defaults to int
>ULONG __saveds __asm highlightBlock(register __a0 struct 
warning 57 in line 120 of "example.c": , expected

You still didn't fix the SAS/C attributes in the

highlightBlock()

function, like Bubbob told you. Although it doesn't matter as the hook isn't even used.

I'm just mentioning this because this means debugging this may not be as straightforward for me ATM as we had originally hoped. We can still do the

trap #0

approach, of course, but I'd prefer to have some more specific instructions on where to put those

Put

__asm("\ttrap\t#0");

as the first instruction in your

init()

. Then we know that TextEdit has called it, as soon as you see a Software Failure #80000020.
Otherwise TextEdit has already problems with loading the plugin or processing the header. I guess TextEdit uses

LoadSeg()

to read and relocate a plugin into memory'?

I'm kinda hoping you guys spot something in the output of

make

that might tell us what the problem might be..

Of course, there are some warnings to fix, but it is nothing which would justify a complete malfunction as it is now.

[guy lateur]

Originally Posted by phx

Freezes? Wasn't it some kind of Guru before?
Anyway, it is essential to find out whether

init()

is called at all or whether it even returns before the problem occurs.

I get a Guru when I use Camilla's code as it is. When I leave the init() function as empty as possible (as suggested by both you and Camilla) the entire system hangs.

Originally Posted by phx

You still didn't fix the SAS/C attributes in the

highlightBlock()

function, like Bubbob told you. Although it doesn't matter as the hook isn't even used.

Yes I did, and I even asked you if the modified function looked ok: https://eab.abime.net/showpost.php?p...3&postcount=10 But like I said I lost my entire system yesterday (I should take way more backups of my stuff), so I had to practically start from scratch, so I started from Camilla's original sources again and forgot to modify that signature. So nice catch; I'll modify it again.

Originally Posted by phx

Put

__asm("\ttrap\t#0");

as the first instruction in your

init()

. Then we know that TextEdit has called it, as soon as you see a Software Failure #80000020.

Ok, will do, I'll report back asap.

[alkis]

why is openlibs commented out?
Libraries should be opened before anything else.

Also, could I ask something. On the example plugin that works, with sas/c run scopts and switch startup code to 'nostartup", clean, build, check that it still works please. Thanks

[guy lateur]

I've been checking when the Guru/Software Failure turns into a system freeze. Starting from Camilla's source, I always have to add an

#include <string.h>

, because otherwise I get an undefined reference to

strlen()

. If that's the only change I make, I get a Guru:

Program failed (error #80000006)

, or sometimes

Program failed (error #8000000A)

. ATM it's unclear to me what causes the either one or the other error to show up. BTW, on the Vampire, it's not an actual Guru Meditation screen; it's just a

Software Failure

dialog window, like this:



The next thing I do (at least, from now on ) is change the signature of the highlightBlock() function. That still results in a Software Failure, not a hang.

However, if I then put the call to

openLibs()

at the top of the

init()

function (which seems like the smart thing to do), the system hangs when I start TextEdit. So I'm assuming calling

AllocVec()

before opening any libraries leads to the Software Failure.

The above implies that the

init()

function does indeed get called, which is confirmed by the

trap #0

check. If I put that at the top of the init() function, I indeed get

Software Failure #80000020

:



Next step will be to see how far down I can put the trap before the system hangs again.

[guy lateur]

Originally Posted by alkis

why is openlibs commented out?
Libraries should be opened before anything else.

That was suggested to me by both Camilla and phx. The idea was to have the plugin at least register with TextEdit, without generating a Software Failure or having the system freeze. It would obviously not do anything in that case, but when that worked, I could then start adding stuff back in until I ran into trouble again, thus narrowing down where the problem arises. I was advised to only give the plugin its name, and leave everything else in the

init()

function untouched. As you may have read above, though, it seems that's not really an option, unfortunately.

Originally Posted by alkis

Also, could I ask something. On the example plugin that works, with sas/c run scopts and switch startup code to 'nostartup", clean, build, check that it still works please. Thanks

Sure, I'd gladly oblige if I knew what that means.. Is scopts a command I just run in the example folder? Where do I set 'nostartup'? Is that a line I add to the

SCOPTIONS

file? Sorry, total SAS/C noob here..

[bebbo]

Originally Posted by alkis

gcc's note on __saveds

Please do not use this attribute in pure executables. This is because several invocations of pure executables can run concurrently, each one having its own data section, and there is no way to find out to which of these sections should ‘a4’ be set.

(Couldn't tell from previous response, if plugin is loadseg'd once for all instances or once for each instance, so I don't know if this is relevant)

off topic - but regarding saveds and resident: You are free to store a4 in the tc_UserData and provide your function to use that. But since the name contains 'user' I won't make gcc use that by default.

[alkis]

Originally Posted by guy lateur

Sure, I'd gladly oblige if I knew what that means.. Is scopts a command I just run in the example folder? Where do I set 'nostartup'? Is that a line I add to the

SCOPTIONS

file? Sorry, total SAS/C noob here..

From shell go to the folder that you build the example.
type scopts and hit enter
A gui should pop out.
Press button "Linker options..."
You should see (in say middle 'column') something like startup=c, keep pressing that button till it says NoStartup
Press ok, that will go to previous setup and there press Save.

Now clean, build, check.

[guy lateur]

Originally Posted by alkis

From shell go to the folder that you build the example.
type scopts and hit enter
A gui should pop out.
Press button "Linker options..."
You should see (in say middle 'column') something like startup=c, keep pressing that button till it says NoStartup
Press ok, that will go to previous setup and there press Save.

Now clean, build, check.

Yes, it still works.