compiling IA32ABI for cocoa cog
Locked
 
|
Hi, I'm trying to compile new IA32ABI plugin, who should work with new Threaded FFI. As everybody requested, I'm trying to compile this plugin as an external plugin, and for that reason I need variable sqInt inIOProcessEvents; to be EXPORT(sqInt) inIOProcessEvents; ...how can I modify VMMaker to ensure this? I tried touching StackInterpreter>>#mustBeGlobal:, but that generates bad code on gcc3x-cointerpmt.c (it creates GIV(inIOProcessEvents) calls and that does not work) so... any idea? thanks, Esteban |
Re: compiling IA32ABI for cocoa cog
|
|
Hi Esteban, On Tue, Apr 12, 2011 at 5:03 PM, Esteban Lorenzano <[hidden email]> wrote:
Um, are you sure you need to. If you have a look at http://www.squeakvm.org/svn/squeak/branches/Cog r2378 you'll see that inIOProcessEvents is declared in cointerpmt.c and that IA32ABI.c imports it via
src/plugins/IA32ABI/IA32ABI.c: { extern int inIOProcessEvents; address = (sqInt)&inIOProcessEvents; } Doesn't that work? best, Eliot
I tried touching StackInterpreter>>#mustBeGlobal:, but that generates bad code on gcc3x-cointerpmt.c (it creates GIV(inIOProcessEvents) calls and that does not work) |
|
|
Hi Eliot, yes... I need it, because cocoa cog vm is compiled with: -fvisibility=hidden, and so I need to explicitly export functions/variables I want to use outside. I could change the visibility, but I'm not sure if this is a good idea. Cheers, Esteban El 12/04/2011, a las 9:17p.m., Eliot Miranda escribió: Hi Esteban, |
Re: compiling IA32ABI for cocoa cog
|
|
On Tue, Apr 12, 2011 at 6:30 PM, Esteban Lorenzano <[hidden email]> wrote:
If you must, you must. You can include specific declarations in the class-side declareCVarsIn: methods, e.g. StackInterpreter class>> declareCVarsIn:.
|
|
|
well... for testing, I changed -fvisibility=hidden with -fvisibility=default now it runs... and all the symbols are public. I do not perceive any loose of performance, nor loading, nor executing... I dunno, maybe I should keep this visibility... it certainly easies some things. What I don't know is if this is conceptually correct. What do you think? Cheers, Esteban El 12/04/2011, a las 10:34p.m., Eliot Miranda escribió:
|
Re: compiling IA32ABI for cocoa cog
|
|
I'm not a mac programmer, but I think that I recall a similar issue related to getting AioPlugin working on Mac. John McIntosh may remember the details, but my guess is that your change to -fvisibility is probably the right thing to do. Don't take my word for it because I have no experience here, but I just want to say that I think we have seen this issue before. Dave On Tue, Apr 12, 2011 at 11:25:24PM -0300, Esteban Lorenzano wrote: > > well... for testing, I changed -fvisibility=hidden with -fvisibility=default > now it runs... and all the symbols are public. > I do not perceive any loose of performance, nor loading, nor executing... > I dunno, maybe I should keep this visibility... it certainly easies some things. What I don't know is if this is conceptually correct. > What do you think? > > Cheers, > Esteban > > > El 12/04/2011, a las 10:34p.m., Eliot Miranda escribi?: > > > > > > > On Tue, Apr 12, 2011 at 6:30 PM, Esteban Lorenzano <[hidden email]> wrote: > > > > Hi Eliot, > > yes... I need it, because cocoa cog vm is compiled with: -fvisibility=hidden, and so I need to explicitly export functions/variables I want to use outside. I could change the visibility, but I'm not sure if this is a good idea. > > > > If you must, you must. You can include specific declarations in the class-side declareCVarsIn: methods, e.g. StackInterpreter class>> declareCVarsIn:. > > > > > > Cheers, > > Esteban > > > > El 12/04/2011, a las 9:17p.m., Eliot Miranda escribi?: > > > >> Hi Esteban, > >> > >> On Tue, Apr 12, 2011 at 5:03 PM, Esteban Lorenzano <[hidden email]> wrote: > >> > >> Hi, > >> I'm trying to compile new IA32ABI plugin, who should work with new Threaded FFI. > >> As everybody requested, I'm trying to compile this plugin as an external plugin, and for that reason I need variable > >> > >> sqInt inIOProcessEvents; > >> > >> to be > >> > >> EXPORT(sqInt) inIOProcessEvents; > >> > >> ...how can I modify VMMaker to ensure this? > >> > >> Um, are you sure you need to. If you have a look at http://www.squeakvm.org/svn/squeak/branches/Cog r2378 you'll see that inIOProcessEvents is declared in cointerpmt.c and that IA32ABI.c imports it via > >> > >> src/plugins/IA32ABI/IA32ABI.c: { extern int inIOProcessEvents; address = (sqInt)&inIOProcessEvents; } > >> > >> Doesn't that work? > >> > >> best, > >> Eliot > >> > >> I tried touching StackInterpreter>>#mustBeGlobal:, but that generates bad code on gcc3x-cointerpmt.c (it creates GIV(inIOProcessEvents) calls and that does not work) > >> > >> so... any idea? > >> > >> thanks, > >> Esteban > >> > > > > > > > |
Re: compiling IA32ABI for cocoa cog
|
|
Its an OK compromise. It used to work fine. The VM keeps those symbols it doesn't want to export to plugins private (static) and makes public only those it wants them to see. So having public symbols visible is fine. It isn't as clean with Cog. There is a broad API used to interconnect the CoInterpreter and the Cogit, lots of which plugins have no business seeing. But then plugins don't access them, and in fact it might be useful if some could (e.g. NativeBoost). The problems come when there are conflicts between VM symbols and those in arbitrary code. But this is worrying about an unlikely scenario that we can deal with when it arrives. Use -fvisibility=default until you get problems. If it ain't broke, don't fix it.
best Eliot > |
Re: compiling IA32ABI for cocoa cog
|
|
On 13 April 2011 05:05, Eliot Miranda <[hidden email]> wrote: > > Its an OK compromise. It used to work fine. The VM keeps those symbols it doesn't want to export to plugins private (static) and makes public only those it wants them to see. So having public symbols visible is fine. It isn't as clean with Cog. There is a broad API used to interconnect the CoInterpreter and the Cogit, lots of which plugins have no business seeing. But then plugins don't access them, and in fact it might be useful if some could (e.g. NativeBoost). The problems come when there are conflicts between VM symbols and those in arbitrary code. But this is worrying about an unlikely scenario that we can deal with when it arrives. Use -fvisibility=default until you get problems. If it ain't broke, don't fix it. IMO hidden is better, because it forcing you to export symbols explicitly, so you are in finer control what happens. And then helps to see dependency problems at static link stage, not at dynamic link stage during run time. > best > Eliot > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |