VBCC: building a TextEdit syntax plugin for OS3.2 - Page 4

alkis · 27 June 2021, 20:46

Quote:

Originally Posted by guy lateur

Yes, it still works.

Ok, sanity restored. Thanks!

guy lateur · 27 June 2021, 20:58

Quote:

Originally Posted by alkis

Ok, sanity restored. Thanks!

Hehe, my pleasure, cheers!

alkis · 27 June 2021, 21:13

Ok, can you try these suggestions on your plugin.

First somewhere on top:

Code:

struct Library *SysBase;
struct Library *UtilityBase=NULL;
struct Library *TextFieldBase=NULL;

Then change openlibs to return an int, 0 on failure, 1 at success

Code:

int openLibs(void)
{
  
    SysBase  = (*((struct Library **) 4));

    if (! (UtilityBase = OpenLibrary("utility.library",47)))
        return 0;

    if (! (TextFieldBase = OpenLibrary("gadgets/texteditor.gadget",47)))
        return 0;
    return 1;
}

And on init()

Code:

static void init(APTR userData)
{
  struct Filetype *fType = (struct Filetype *)userData;
  if (!openLibs()) {
    terminate(fType);
    return;
  }
	
    struct Hook *hook = (struct Hook *)AllocVec(sizeof(struct Hook), MEMF_CLEAR);


   ....
   ....

If you do those, does it still crash?

vbc · 27 June 2021, 21:36

Quote:

Originally Posted by phx

Requiring that all plugin authors don't touch A4 would restrict them to use SAS/C. I'm not sure if any other compiler has a

far

option which takes A4 away from the code generator.

-reserve-reg=a4 should work with vbcc. Better to fix the code, though.

bebbo · 27 June 2021, 22:07

and some thoughts on topic:

- such plugins IMHO must not use any global data. baserel or not is irrelevant.
- all data include *Base must be kept inside the plugins userdata, here it's ft->pluginData.

Code:

struct MyData {
  struct XyBase * xyBase;
  int aValue;
  ...
};

- to use *Base define a macro or use a local variable:

Code:

  XYBase * xyBase = ((struct MyData *)ft->pluginData)->xyBase;
  // call xyBase fx now...

maybe that helps

bebbo · 27 June 2021, 22:09

Quote:

Originally Posted by vbc

-reserve-reg=a4 should work with vbcc. Better to fix the code, though.

you could add a4 as an additional register parameter to all functions.
the incoming gets a4 and passes it to the outgoing. And the compiler is free to use it inbetween.

guy lateur · 27 June 2021, 22:21

Quote:

Originally Posted by alkis

Ok, can you try these suggestions on your plugin.
....
....
If you do those, does it still crash?

Yes. I guess this means at least the libs are successfully opened, which is nice.

Quote:

Originally Posted by vbc

-reserve-reg=a4 should work with vbcc. Better to fix the code, though.

Thanks for your input, that's good to know. It doesn't solve the problem, unfortunately; the system still freezes when I start TextEdit.

guy lateur · 27 June 2021, 22:26

Quote:

Originally Posted by bebbo

and some thoughts on topic:

- such plugins IMHO must not use any global data. baserel or not is irrelevant.
- all data include *Base must be kept inside the plugins userdata, here it's ft->pluginData.

Code:

struct MyData {
  struct XyBase * xyBase;
  int aValue;
  ...
};

- to use *Base define a macro or use a local variable:

Code:

  XYBase * xyBase = ((struct MyData *)ft->pluginData)->xyBase;
  // call xyBase fx now...

maybe that helps

Quote:

Originally Posted by bebbo

you could add a4 as an additional register parameter to all functions.
the incoming gets a4 and passes it to the outgoing. And the compiler is free to use it inbetween.

Thanks for your suggestions, much appreciated!

alkis · 27 June 2021, 22:38

Quote:

Originally Posted by guy lateur

Yes. I guess this means at least the libs are successfully opened, which is nice.

if, temporarily, you remove all code from your hook (i.e. your hook is empty) does it still crash?

guy lateur · 28 June 2021, 00:13

Quote:

Originally Posted by alkis

if, temporarily, you remove all code from your hook (i.e. your hook is empty) does it still crash?

The hook function itself (

highlightBlock()

) returns a ULONG, so it cannot be empty. I have tried just having it return 1L, but the system still freezes when I do that.

I have also tried leaving that function definition as it is, but not assigning it to the

Hook

in the

init()

function (which is probably what you meant). Here is that

init()

function:

Code:

static void init(APTR userData)
{
    //__asm("\ttrap\t#0");

    struct Filetype *fType = (struct Filetype *)userData;
    
    if(!openLibs())
    {
    	terminate(fType);
    	return;
    }

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

    fType->pluginData = (ULONG)1234567; // any number or pointer of our choosing
    fType->highlighterHook = NULL;
    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;
}

The first thing I tried was commenting out those last 3 lines. Then I also commented out the allocation of the hook (the

AllocVec()

line) and set

fType->highlighterHook = NULL

, and finally I also commented out the

highlightBlock()

definition completely. All 3 of those scenarios also resulted in a frozen system.

I then reverted back to the complete, uncommented

init()

function and tried putting the trap lower. If I put it after the

AllocVec()

line, I got

Software Failure #80000020

, which implies the allocation works.

Last thing I tried was putting the trap at the very bottom of the

init()

function. That gave a somewhat strange result: the dialog of the

Software Failure #80000020

started to appear, but the system froze before it could be rendered completely. So I ended up with frozen system showing a gray rectangle (without any text or other content) where the trap error would normally appear. This suggests to me that the end of the

init()

function was reached, but the system froze before it could finish rendering the

Software Failure #80000020

. I think I'm gonna have to sleep on that one..

alkis · 28 June 2021, 01:00

Ok, lets try logging.

Add -log -serlog to the winuae icon (i have a shortcut to my desktop, right click, properties, my target now reads "D:\winuae\winuae64.exe -log -serlog"

Now on your plugin code, somewhere near the top, define this prototype

Code:

int KPrintF(const char *, ...);

(since you already have in the makefile -lamiga -ldebug nothing else is needed)

Now, place right after the if of openlibs

Code:

KPrintF("Libraries opened ok\n");

and at the end of init()

Code:

KPrintF("Init's end reached\n");

Now, you should see those in the log window. If you do, great. Keep adding loging to hook

Code:

KPrintF("Hook called\n"); //fist line in your hook
...
...
KPrintF("Hook end reached\n"); //last line in your hook

alkis · 28 June 2021, 01:13

Also add this as last line in terminate

Code:

TextFieldBase = UtilityBase = NULL;

phx · 28 June 2021, 11:45

Quote:

Originally Posted by guy lateur

Last thing I tried was putting the trap at the very bottom of the

init()

function. That gave a somewhat strange result: the dialog of the

Software Failure #80000020

started to appear, but the system froze before it could be rendered completely.

Nevertheless you are sure it was a

Software Failure #80000020

?
This is very strange, and it implies that the

init()

function probably never returned without freezing the system. So you can forget about the hook for now.

If we assume that the system was stable before entering

init()

, and that TextEdit didn't already corrupt the system while loading the executable or processing the plugin header, there are only two possibilies for more system corruptions:

```
AllocVec()
```
doesn't really work and does bad things.
The
```
userData
```
pointer passed into the function is bad. So initialising
```
FileType
```
corrupts memory.

Did you already try a completely empty

init()

? Does TextEdit allow that? Maybe test that first with an SAS/C compilation.

BTW, was anybody successful to make such a plugin work with a different compiler, like gcc? Somehow I get the feeling that there might even be a problem in TextEdit (like the don't-change-a4 dependency) which is hidden when compiling the plugin with SAS/C...

Otherwise, this is probably the point where you have to start some serious debugging, with a real AmigaOS debugger or by using UAE. Also Enforcer or MuForce would help to catch some illegal accesses early. But AFAIK that doesn't work with your Vampire?

guy lateur · 28 June 2021, 22:49

Quote:

Originally Posted by phx

Nevertheless you are sure it was a

Software Failure #80000020

?

You're right, I cannot be sure of that. It's just that I had seen 17 such Software Failure's just before that, so I assumed it would have been the same error. But it may indeed have been something else entirely; no way to be sure.

Quote:

Originally Posted by phx

Did you already try a completely empty

init()

? Does TextEdit allow that? Maybe test that first with an SAS/C compilation.

I did now, and it turns out TextEdit does allow it, and it even works with VBCC. Well, 'work', I mean I can start TextEdit without a problem and I see a nameless entry in the Filetype menu. I can select it without a problem, but it obviously doesn't do anything.

Quote:

Originally Posted by phx

If we assume that the system was stable before entering

init()

, and that TextEdit didn't already corrupt the system while loading the executable or processing the plugin header, there are only two possibilies for more system corruptions:

```
AllocVec()
```
doesn't really work and does bad things.
The
```
userData
```
pointer passed into the function is bad. So initialising
```
FileType
```
corrupts memory.

I think you second suggestion is correct. I started filling my

init()

function back in, and this is how far I got:

Code:

static void init(APTR userData)
{
    struct Filetype *fType = (struct Filetype *)userData;
    
    fType->name = "Example";
    fType->typeName = "example";
    
    //!! the next line makes the system freeze when starting TextEdit
    //fType->autoFileTypes = "example";
}

The function as given works ok, but if I uncomment that last line, I get the system freeze again. So it seems like that pointer to

userData

is indeed bad. I don't know if there's anything I can do to make that pointer good? That seems to be pretty much out of my control, doesn't it?

Quote:

Originally Posted by phx

Otherwise, this is probably the point where you have to start some serious debugging, with a real AmigaOS debugger or by using UAE. Also Enforcer or MuForce would help to catch some illegal accesses early. But AFAIK that doesn't work with your Vampire?

You're right, the devs on the Discord server just told me neither Enforcer nor MuForce will work on the current Vampire Core. The next Core should contain similar functionality, though: 'Apollo Shield'. Cores normally get released on a bimonthly basis, so I expect this tool to be available somewhere in July.

boemann · 29 June 2021, 00:06

Quote:

Originally Posted by guy lateur

I did now, and it turns out TextEdit does allow it, and it even works with VBCC. Well, 'work', I mean I can start TextEdit without a problem and I see a nameless entry in the Filetype menu. I can select it without a problem, but it obviously doesn't do anything.

The function as given works ok, but if I uncomment that last line, I get the system freeze again. So it seems like that pointer to

userData

is indeed bad. I don't know if there's anything I can do to make that pointer good? That seems to be pretty much out of my control, doesn't it?

This is interesting - i doubt that pointer is bad as it works if when you build with sas/c and the memory is allocated with AllocVec

boemann · 29 June 2021, 00:10

Try and use the full example but just comment out that autoFileTypes assignment

boemann · 29 June 2021, 01:03

Hmm can it be that because init is static and thus vbcc pass arguments differently ? so it interprets userData in a wrong way ?vbcc

I've tried loading the plugin you provided in a zip, and what I see is that the pluginheaders seems to be correct, the pointer to init function seems correct too, and it does return. The string pointers are still null after the return though which doesn't correspond to the source files in the zip.

That is why I think the init might misinterpret the argument

bebbo · 29 June 2021, 09:55

try this:

Code:

void init(APTR userData asm("a0")) {
...
}

boemann · 29 June 2021, 10:01

Quote:

Originally Posted by bebbo

try this:

Code:

void init(APTR userData asm("a0")) {
...
}

Hmm I send args on the stack

bebbo · 29 June 2021, 10:50

Quote:

Originally Posted by boemann

Hmm I send args on the stack

the init functions in Default4Types start with code like

Code:

    suba.w #24,sp
    movem.l d2/d4/a2-a3/a5-a6,-(sp)
    movea.l a0,a2

27 June 2021, 22:07	#65
bebbo bye Join Date: Jun 2016 Location: Some / Where Posts: 680	and some thoughts on topic: - such plugins IMHO must not use any global data. baserel or not is irrelevant. - all data include Base must be kept inside the plugins userdata, here it's ft->pluginData. Code: struct MyData { struct XyBase xyBase; int aValue; ... }; - to use Base define a macro or use a local variable: Code: XYBase xyBase = ((struct MyData *)ft->pluginData)->xyBase; // call xyBase fx now... maybe that helps

28 June 2021, 01:00	#71
alkis Registered User Join Date: Dec 2010 Location: Athens/Greece Age: 53 Posts: 719	Ok, lets try logging. Add -log -serlog to the winuae icon (i have a shortcut to my desktop, right click, properties, my target now reads "D:\winuae\winuae64.exe -log -serlog" Now on your plugin code, somewhere near the top, define this prototype Code: int KPrintF(const char *, ...); (since you already have in the makefile -lamiga -ldebug nothing else is needed) Now, place right after the if of openlibs Code: KPrintF("Libraries opened ok\n"); and at the end of init() Code: KPrintF("Init's end reached\n"); Now, you should see those in the log window. If you do, great. Keep adding loging to hook Code: KPrintF("Hook called\n"); //fist line in your hook ... ... KPrintF("Hook end reached\n"); //last line in your hook

28 June 2021, 01:13	#72
alkis Registered User Join Date: Dec 2010 Location: Athens/Greece Age: 53 Posts: 719	Also add this as last line in terminate Code: TextFieldBase = UtilityBase = NULL;

29 June 2021, 09:55	#78
bebbo bye Join Date: Jun 2016 Location: Some / Where Posts: 680	try this: Code: void init(APTR userData asm("a0")) { ... }

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
AmigaOS 3.2 TextEdit - black text on black background?	Warty	support.Apps	7	08 June 2021 17:30
gedit asm syntax highlighting plugin?	grond	Coders. Asm / Hardware	0	19 May 2020 13:06
VBCC assembler linking syntax?	NovaCoder	Coders. General	2	20 May 2011 03:04
CLI Syntax	Greaser	New to Emulation or Amiga scene	1	08 October 2006 10:14
SynTax Disks (old)	andreas	request.Old Rare Games	1	19 July 2003 04:02

29 June 2021, 00:10	#76
boemann Camilla, AmigaOS Dev. Join Date: Mar 2020 Location: Frederiksberg Posts: 327	Try and use the full example but just comment out that autoFileTypes assignment

29 June 2021, 01:03	#77
boemann Camilla, AmigaOS Dev. Join Date: Mar 2020 Location: Frederiksberg Posts: 327	Hmm can it be that because init is static and thus vbcc pass arguments differently ? so it interprets userData in a wrong way ?vbcc I've tried loading the plugin you provided in a zip, and what I see is that the pluginheaders seems to be correct, the pointer to init function seems correct too, and it does return. The string pointers are still null after the return though which doesn't correspond to the source files in the zip. That is why I think the init might misinterpret the argument

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)