#528: RFC
-----------------------+----------------------------------------------------
 Reporter:  chromatic  |       Owner:  chromatic
     Type:  roadmap    |      Status:  new      
 Priority:  normal     |   Milestone:  1.2      
Component:  none       |     Version:           
 Severity:  medium     |    Keywords:           
     Lang:             |       Patch:           
 Platform:  all        |  
-----------------------+----------------------------------------------------
 libparrot exports thousands of symbols.  Many of those are the vtable
 functions in our PMCs.  They get exported because of the way initializing
 a PMC builds its vtable.  Look in src/pmc/class.c in a built Parrot source
 tree for now. Parrot_Class_class_init() creates the Class PMC's vtable as
 an array of function pointers.  Because Class inherits some behavior from
 the Default PMC, its vtable array contains pointers to functions declared
 in Default.

 That doesn't imply anything about the visibility of those symbols...
 except that dynpmcs have the same strategy.  Every dynpmc either
 reimplements its own functions, or its initialization code has to refer to
 symbols explicitly exported from libparrot to get at the function pointers
 directly from the Default PMC, or whichever core PMC is its parent.

 We need a way to map the appropriate slot in the vtable array for each
 overridden entry.  That's easy.  We need a way for a dynpmc to access and
 clone its parent's vtable.  That's a little bit more work, if only because
 we have to do this in generated code, and it's a divergence between how
 dynpmcs initialize their vtables and how built-in PMCs initialize their
 vtables.

 Core PMCs all get stuffed into the same libparrot, so all of the necessary
 symbols are visible.

 I've already checked in code which initializes PMC vtables in the proper
 order: parents before children.  When we load a dynpmc group, all of
 Parrot's vtables are assembled properly.  The group initializes all of its
 dynpmcs in the proper order.

 When dynpmcs no longer access vtable functions directly, we can remove
 PARROT_EXPORT from the generated vtable functions -- that's the goal of
 this exercise.

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/528>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to