Re: Always the problem between gplc/gcc--obj_chain and initialization

[spratt]

On Friday, August 30, 2002, at 06:26  AM, Timo Karjalainen wrote:

> Reflecting on the obj_chain_* stuff you quoted, it seems like there is
> some wacky symbol-address scheme. What else are those magic numbers good
> for except scanning the binary and forking all user code between the
> beginning and the end.

This is how the initialization/1 directive is implemented. I don't 
understand the complete story yet, but...

:- initialization(foo).

compiles into a bit of object code that is:
OBJ_CHAIN_MAGIC_1 /* == 0xdeadbeef */
OBJ_CHAIN_MAGIC_2 /* == 0x12345678 */
next /* address of next obj_chain */
fct_init /* address of foo/0 */

To run gprolog, the first thing that one has to call (in C) is 
Start_Prolog(argc, argv). Start_Prolog does several things, including 
calling Find_Linked_Objects(), which *searches the executable file* 
looking for obj_chain structures. Depending on the platform, the search 
may sweep through the code between obj_chain_begin and obj_chain_end a 
byte at a time (except for when obj_chain structures are found), or it 
may skip directly from obj_chain to obj_chain (following the 'address of 
next obj_chain' field).

As each obj_chain structure is located, the procedure at 'fct_init' 
( "foo/0" in this example) is invoked, achieving the requested 
initialization.

There are many system initializations, as well as any number of user 
initializations.

I don't know if this counts as a "wacky symbol-address scheme", but it 
is an unusual architecture and it complicates incorporating gprolog into 
a larger system. I have been working on building a Cocoa/ObjectiveC app 
on Mac OS X that includes gprolog (rather than invoking gprolog as a 
separate task) and it has been very challenging.

-lindsey