[SOLVED] Method patch example request...ideas?

[Belxjander]

I need help with the following "patch" in
http://code.google.com/p/polymorph/sour ... y/filter.c

I need "LoadSegVMM" to actually perform a call to "LoadSegDOS" which is the original dos.library/LoadSeg() LVO call
and to do so with the following restrictions...

No GCC optimization or call modification (static definition of the entrypoint)...
Arguments given when called *must* be used unchanged in calling the original vector,

any return value except NULL is to be handed back to the caller,

the "EnablePolymorphX" needs to be checked when "LoadSegDOS()" returns NULL,

I currently have a "naked" Assembly function presented as "LoadSegVMM()" specifically to try and call the original LoadSegDOS()
without the SysV argument setup in registers being modified (currently I am seeing deadlocks and recoverable alerts)

there is also a commented C version at the bottom... if there is some means of fixing a function to that Polymorph can patch and wrapper
LoadSeg() calls without crashing the system in the process...

LoadSegVMM() is provided by Polymorph
LoadSegDOS() is proveded by dos.library

dos.library / LoadSeg() is patched to call LoadSegVMM() as transparent replacement

LoadSegVMM() first calls the LoadSegDOS() function which is obtained when the patch is applied
----
IF (rc = LoadSegDOS(name))==NULL THEN
IF EnablePolymorphX THEN
dtid = ObtainDataTypeIdent(name)
plugin = ObtainPolymorphPlugin(dtid)
rc = PluginLoadSeg(plugin,name)
ENDIF
ENDIF
----

What am I missing in declaring the function in C?

Have I incorrectly tried to call the LoadSegDOS() function using a direct branch?

Help... please?

The above link is directly into the repository fopr the whole project... so feel freeto check it out and comment if you have a constructive suggestion

[colinw]

Please post a detailed enhancement request for the functionality you require to do this properly.
Use the "AmigaOS Feature Request" forum to do so.

I do not provide developer support for hacks that patch system functions.

[Belxjander]

@ColinW:

1 It is not a feature of dos.library alone,

2 is there an open mechanism for adding additional program formats where the plugin library can opt for faking a native presence?

3 Are you stating there is a non SetMethod() option to add behaviours?

4 Do you have any understanding of what I am trying to actually achieve?

The code in my patch needs to be invisible to the caller and dos.library.....

I am being as bluntly specific as I can and this patch does not make behavioral changes

I am making use of an existing behavior to conditionally trigger use of plugins when a NULL return is provided by the original code.


I only need to be able to call your original function and test for non 0 results (immediate return)

Does this need to be embedded into dos.library?

Edited from my phone... I will edit again at home tonight

[thomasrapp]

there is also a commented C version at the bottom... if there is some means of fixing a function to that Polymorph can patch and wrapper
LoadSeg() calls without crashing the system in the process...

I think you create an endless loop or recursion. You patch LoadSeg() to call ObtainDataType() in case of failure which might lead to another call to LoadSeg() (to load a library or the code from a datatype descriptor) which might again call ObtainDataType() and so on.

You probably have to develop a mechanism to recognise and prohibit recursive calls of your patch.

[Belxjander]

Which I am more than prepared to do once I can first cleanly call the original loadseg function to validly test trying known working and deliberately failing test files

Any recursion or other test logic I would prefer to perform in C in order to keep the binding patch itself as small as possible

And...as you pointed out... any recursion would be on a failure result of LoadSeg() meaning only DataTypes and Polymorph plugins which are non-native will trigger re-entry into polymorph

Policy will be for polymorph to remain an external patch optional and not a mandated feature along with no mixed host support... as each host is subject to its own quirks which are clearly not needing to be transferred

The results I have obtained so far are have triggered a recursive stack error just trying to perform the LoadSeg() call on its own

If it was possible to do this entirely in C and use the return from SetMethod() as the first function called without locking the machine completely AND returning valid non-zero results

I am missing details and information about details

Unless there is a hidden mechanism that elf.library and hunk.library are using?

As for recursion... I have to allow it, however there will be limitations for any plugins in needing to be z

They must be native-loading and will be ignored otherwise
This will be a specific cross call ignoring the patch entrypoint

If there is any recursion when calling a DataType I will have to deal with it... however for right now I need a minimalistic patch that works without any system collapse or lockups when making the function call

Thank you both for at least looking and replying

I don't see the need for polymorph's plugin mechanism to be integrated into dos.library until there is a clearer separation of the required functionality from the rest of polymorph and it can be submitted on its own with polymorph already displaying functional usage that helps

[thomasrapp]

You crash because you omitted the self pointer in your method.

This is the right declaration of your method patch:

BPTR LCALL_LoadSegVMM( struct DOSIFace *self, CONST_STRPTR name );

You declared LCALL_LoadSegVMM not only with a wrong prototype but also as an external pointer which as far as I can see is never initialised.

I am sure you don't need to switch to assembler. That's just overkill on your side.

[Belxjander]

Thank you again for looking at it.

I'll fixup both the LoadSegDOS() and LoadSegVMM() calls to include the corrections

Which works into needing the plugin handling as next to do...

[colinw]

By the way, just incase you didn't realise this.
Depending on the version of dos.library, you may have up to five LoadSeg() function vectors to patch...
At best, three, and two if you want to exclude some 68K loadables.

[Belxjander]

I'm aware of LoadSeg NewLoadSeg and InternalLoadSeg for 68K
Other than the LoadSeg documented in the Autofocus for DPS.library I have not seen other vectors...

Hperverse for whatever reason calling through as transparent as possible triggers a locking loop so I am wondering quite what SetMethod is returning.

All polymorph plugins need to be host native as a loading rule.

Which is to block recursive loading.

The majority of what I am trying is based on what I made work specifically with the 68K OS with changes...

This newer version is targetting AOS4 as nativ3 host for itself and to wrap anything its plugins

@ColinW thank you for pointing out I have more details to look through while trying to work out this deadlocking loop

Thank you for all the help

I just wish the SetMethod return was actually callable so that the original function could be used on its own with any DOSIFace *p usable as the first argument without repeat looping into my code

Or do I need an Unpatched clone of the DOSIface to be made first?

I'll try that first and see what I get.

I still want to kept patches to a bare minimum

[thomasrapp]

I think you didn't point out clearly enough that you are still missing the basics. Here is a working example: http://thomas-rapp.homepage.t-online.de ... atchlseg.c