[Chicken-janitors] Re: #458: Chicken can't profile itself

[Chicken Trac]

#458: Chicken can't profile itself
-----------------------+----------------------------------------------------
  Reporter:  sjamaan   |       Owner:                                      
      Type:  defect    |      Status:  reopened                            
  Priority:  major     |   Milestone:  4.7.0                               
 Component:  compiler  |     Version:  4.6.x                               
Resolution:            |    Keywords:  expander, profiler, self-compilation
-----------------------+----------------------------------------------------

Comment(by sjamaan):

 It turns out this is caused by the fact that C_profiler_toplevel is
 invoked by the generated {{{(##core#callunit "profiler")}}} which is added
 to library.scm by the {{{-profile}}} flag.

 The profiler toplevel depends on a few identifiers from library.scm being
 bound (those in the LETs around the lambdas of {{{##sys#register-profile-
 info}}} and {{{##sys#finish-profile}}}). Getting rid of those surrounding
 LETs doesn't fix the problem, though.

 Compiling the whole thing with {{{CHICKEN='chicken -profile'}}}, then
 deleting library.c and profiler.c and running Make again with
 {{{CHICKEN=chicken}}} results in a properly functioning Chicken.  However,
 this is a manual step and it leaves a huge part of Chicken uninstrumented
 with profiling info.

 My guess is that locking down profiler.scm into using direct calls
 everywhere instead of through symbol lookups should fix this bootstrapping
 problem. Is this possible?  I tried using usual-integrations, but I think
 some are "unusual" integrations :)

 Another approach that might work is somehow forcing the profiler toplevel
 to run after the toplevel stuff in library.scm

 Finally, the profiler itself should never be compiled with profiling info,
 I think.  If I compile everything except library.scm with profiling info,
 I get the error

 {{{Error: unbound variable: ##sys#register-profile-info}}}

 This happens because profiler.scm is instrumented with itself, so before
 the toplevel had a chance to run the profiling procedures are already
 invoked.  This *might* also be solvable by not looking up profiling
 procedures by symbol (but that would be in the _emitted_ profiling code, I
 think)

 I hope these ramblings make sense...

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/458#comment:8>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.