Ticket #528 (closed roadmap: fixed)
Clone and Modify in DynPMC VTABLE Initialization
|Reported by:||chromatic||Owned by:||chromatic|
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.