Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
39 user(s) are online (30 user(s) are browsing Forums)

Members: 0
Guests: 39

more...

Headlines

 
  Register To Post

fdtrans, 68k->ppc cross-call stubs generation
Home away from home
Home away from home


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

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

ProgressWindow *LIBFUNC L_OpenProgressWindow(
    
REG(a0struct TagItem *tags),
    
REG(a6struct MyLibrary *lib))
{
.....
}


Its prototype done like

Quote:

APTR OpenProgressWindow(struct TagItem *);


In .fd file its done like:

Quote:

OpenProgressWindow(tags)(a0)



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:

<method name="OpenProgressWindow" result="APTR">
<arg name="tags" type="struct TagItem *"/>
</method>


Generated interfaces/inlines after that looks like this:

inline4:
Quote:

#define OpenProgressWindow(tags) IDOpus->OpenProgressWindow((tags))


interfaces:
Quote:

APTR APICALL (*OpenProgressWindow)(struct DOpusIFace *Self, struct TagItem * tags);


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

static APTR stub_OpenProgressWindowPPC(uint32 *regarray)
{
    
struct Library *Base = (struct Library *) regarray[REG68K_A6/4];
    
struct ExtendedLibrary *ExtLib = (struct ExtendedLibrary *) ((uint32)Base Base->lib_PosSize);
    
struct DOpusIFace *Self = (struct DOpusIFace *) ExtLib->MainIFace;

    return 
Self->OpenProgressWindow(
        (
struct TagItem *)regarray[8]
    );
}
STATIC CONST 
struct EmuTrap stub_OpenProgressWindow = { TRAPINSTTRAPTYPE, (uint32 (*)(uint32 *))stub_OpenProgressWindowPPC };


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

Go to top
Re: fdtrans, 68k->ppc cross-call stubs generation
Just popping in
Just popping in


See User information
@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).

Go to top
Re: fdtrans, 68k->ppc cross-call stubs generation
Home away from home
Home away from home


See User information
@centaurz
Quote:

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.

Yes

Quote:

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.


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:

// Open a progress window
ProgressWindow *LIBFUNC L_OpenProgressWindow(
    
REG(a0struct TagItem *tags),
    
REG(a6struct MyLibrary *lib))
{

ProgressWindow *prog;
....
prog->pw_Lib=lib;
....


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:

return Self->OpenProgressWindow(
(struct TagItem *)regarray[8]
);


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:

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

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:

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


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:

return Self->OpenProgressWindow(
(struct TagItem *)regarray[8],
(struct Library *)regarray[13]
);


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:

return Self->OpenProgressWindow(
(struct TagItem *)regarray[8],
(struct Library *)regarray[14]
);


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.


Edited by kas1e on 2013/4/1 5:52:39
Go to top

  Register To Post

 




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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project