fdtrans, 68k->ppc cross-call stubs generation

Have an interesting problem, maybe someone have a clue about.

Let's say i have in old 68k code such kind of function:



Its prototype done like

Quote:

In .fd file its done like:

Quote:


So, as can be seen protos/fd are one arg, but function itself want in a6 register library base pointer. m68k ABI mean that every library function call from a program must put the library base in register a6, and so, that works fine on os3.

Then, we come to os4. We have only one arg in proto/fd file, and so, our generated .xml file looks like this for that function:

Quote:

Generated interfaces/inlines after that looks like this:

inline4:
Quote:

interfaces:
Quote:

Now, we generate 68k-ppc cross-call stubs via fdtrans, and thats what we have:



So, what i do not undestand is

1. will it works as it should now with 68k code , which expect libary base as second argument ?

2. did that first line about *base = reg68k_a6/4 carry about it, and so all 68k->ppc calls will worry about it, and libbase will be in the a6 register as it should be ?

3. is fdtrans respect m68k abi or not, and i still need to modify stubs/protos manually, (or fd/proto to generate right stubs) ?

@kas1e

1. If I got it right, you're in the situation of legacy 68k code calling a native library through a 68k jump table and emulation traps. Native code is not aware of emulated A6 register, it only requires an interface pointer as first parameter (Self) so I don't see any problem.

I think you are mixing up with the glue code which wrap 68k library calls from native code.

2. This first line is used to retrieve a pointer to the libbase (which is not used directly by ppc code).

@centaurz
Quote:
Yes

Quote:

Problem is that this native library is not my own, but port from os3. And that library have in few places functions which want library base pointer as argument and then later use it for their needs. For example:



And then use "prog" for the internal needs (like to do createproc() over IPC).

But (!) there is big fat but : original prototype and original fd files, have only one single argument : tags. Nothing about "lib". For m68k abi there is no needs to pass second argument in proto/fs, because a6 always and all the time contain library base. So they just take it without problems and use it.

Now we build that code for os4, from the same proto/fd files (i.e. from that build .sfd , from .sfd xml and includes), what mean that proto functions in includes will have also only one single argument (tags). Exactly because its in protos/fd done with one argument (see prev. post).

From those proto/fd/sfd we build 68k->ppc cross call stubs via fdtrans, which looks like a show before. There is relevant part:

Quote:

I.e. it return to function only Tags as argument. While, function in the library still expect that second argument will be a6 with library base pointer.

And as i see it, it just will not works. Or at least it just not works right now. I test it, and it crashes because have wrong libary base pointer. Why ?

Quote:
no no, its all exactly in other way: i have 68k binary, which use native aos4 library (which was done originally for 68k, with all those functions which want library base in a6 as argument, just to have ability use it later to fill necessary structs).

Quote:

So, that line do not mean that emulated a6 will have library base pointer ? It just do a pointer for stub itself and later calls, but not fill a6 by library pointer (while it should by 68k abi).

I for now go that way:

I tryed to build .sfd with changing proto/fd to have 2 arguments: (tags, lib) (a0,a6). fd2pragma "scream" that i can't use a6 as argument. So ok, i use a5 and generate .sfd and then stub. Thats how it start to look after:

Quote:

So far i understand that if [8] is a0, and [13] is a5, then logically that [14] will be a6. So i just change it on:

Quote:

In my 68k->ppc stub in library, and OpenProgessWindow() which use a6 as argument with library base pointer start to work.

Because of that questions is still valid:

Why autogenerated stubs do not fill a6 by library base pointer by default _all_the_time_. Or, if they did and plans that they should, then still something wrong with generated stubs, because they just not works as it, and i need to make changes in stubs to make all works.