Changes between Version 93 and Version 94 of NewGhciDebugger


Ignore:
Timestamp:
Apr 20, 2007 10:16:27 AM (8 years ago)
Author:
mnislaih
Comment:

Closed ToDos

Legend:

Unmodified
Added
Removed
Modified
  • NewGhciDebugger

    v93 v94  
    294294 * Investigate whether the compiler is eta contracting this def: "bar xs = print xs", this could be a problem if we want to print out "xs". (MODERATE)
    295295
     296 * Save/restore the link environment at breakpoints. At a breakpoint we modify both the hsc_env of the current Session, and also the persistent linker state. Both of these are held under IORefs, so we have to be careful about what we do here. The "obvious" option is to save both of these states on the resume stack when we enter a breakpoint and then restore them when we continue execution. I have to check with Simon if there are any difficult issues that need to be resolved here, like gracefully handling exceptions etc. (MODERATE)
     297
     298 * Remove dependency on -fhpc flag, put debugging on by default and have a flag to turn it off. (EASY)
     299
     300 * Support Unicode in data constructor names inside info tables. Actually this should just be a matter of using the underlying fast string in the occname. (MODERATE)
     301
     302 * Fix the (sometimes) slow search of the ticktree for larger modules, perhaps by keeping the ticktree in the module info, rather than re-generating it each time. Simon: I currently re-build the tick tree for a module every time I set a breakpoint. This seems rather ugly. I think it would be better to keep the tick tree inside the ModInfo, and thus only build the ticktree when the module is (re)loaded. (MODERATE)
     303
     304 * Use a primop for inspecting the STACK_AP, rather than a foreign C call. (MODERATE)
     305
     306 * Timing and correctness tests. Pepe has some code for timing that might be useful. (MODERATE)
     307
     308 * Stabilise the API. (MODERATE)
     309
     310 * Fix the calculation of free variables at tick sites (currently done too late in the pipeline, gives some wrong results). Note a possible problem with letrecs, which means some locals vars are missing in where clause. (MODERATE/DIFFICULT)
     311
     312 * Extend the stack inspection primitive to allow unboxed things to be grabbed. (MODERATE)
     313
     314=== Partially done ===
     315
     316 * The delete command. It is fairly primitive, and probably not done in the best way. This will be fixed when the API is finalised. (EASY)
     317
     318 * User documentation. You're looking at it. The user manual will have to move into the main GHC docs at some point. (ONGOING)
     319
     320=== Tentative ===
     321
     322 * Perhaps there are some redundant ticks we can delete, such as ones which begin at the same start position? (MODERATE)
     323
     324 * Allow breakpoints to be enabled and disabled without deleting them, as in gdb. (EASY)
     325
     326 * Extend breaks and step with counters, so that we stop after N hits, rather than immediately. (EASY/MODERATE)
     327
     328 * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. (MODERATE/DIFFICULT)
     329
     330=== Closed ===
     331
     332 * Wolfgang's patch for PIC seems to break the strings in Info tables, so we need to fix that. (MODERATE)
     333
     334 * Look at slow behaviour of :print command on long list of chars. I've asked Pepe about this, he has an idea of what the problem is and will be working on a solution soon. (MODERATE)
     335
     336 * Allow breakpoints to be set by function name. Some questions: what about local functions? What about functions inside type class instances, and default methods of classes? One possible solution is to extend the tick tree slightly so that we can search it for function declarations. Another alternative is if the GHC API supports source location queries. The client can simply query GHC to ask what the outermost span of a declaraiton is, then we can set a tick on that span directly. Something to note is that the HPC code has some stuff in it for remembering the "path" of a function, which would be useful for naming nested functions. I don't know if it supports functions inside class declataions. (MODERATE)
     337
    296338 * Fix the ghci help command. This can be done when we decide on the final syntax of the commands. (EASY)
    297339
    298  * Save/restore the link environment at breakpoints. At a breakpoint we modify both the hsc_env of the current Session, and also the persistent linker state. Both of these are held under IORefs, so we have to be careful about what we do here. The "obvious" option is to save both of these states on the resume stack when we enter a breakpoint and then restore them when we continue execution. I have to check with Simon if there are any difficult issues that need to be resolved here, like gracefully handling exceptions etc. (MODERATE)
    299 
    300  * Remove dependency on -fhpc flag, put debugging on by default and have a flag to turn it off. (EASY)
    301 
    302  * Allow breakpoints to be set by function name. Some questions: what about local functions? What about functions inside type class instances, and default methods of classes? One possible solution is to extend the tick tree slightly so that we can search it for function declarations. Another alternative is if the GHC API supports source location queries. The client can simply query GHC to ask what the outermost span of a declaraiton is, then we can set a tick on that span directly. Something to note is that the HPC code has some stuff in it for remembering the "path" of a function, which would be useful for naming nested functions. I don't know if it supports functions inside class declataions. (MODERATE)
    303 
    304  * Support Unicode in data constructor names inside info tables. Actually this should just be a matter of using the underlying fast string in the occname. (MODERATE)
    305 
    306  * Fix the (sometimes) slow search of the ticktree for larger modules, perhaps by keeping the ticktree in the module info, rather than re-generating it each time. Simon: I currently re-build the tick tree for a module every time I set a breakpoint. This seems rather ugly. I think it would be better to keep the tick tree inside the ModInfo, and thus only build the ticktree when the module is (re)loaded. (MODERATE)
    307 
    308  * Use a primop for inspecting the STACK_AP, rather than a foreign C call. (MODERATE)
    309 
    310  * Timing and correctness tests. Pepe has some code for timing that might be useful. (MODERATE)
    311 
    312  * Wolfgang's patch for PIC seems to break the strings in Info tables, so we need to fix that. (MODERATE)
    313 
    314  * Stabilise the API. (MODERATE)
    315 
    316  * Fix the calculation of free variables at tick sites (currently done too late in the pipeline, gives some wrong results). Note a possible problem with letrecs, which means some locals vars are missing in where clause. (MODERATE/DIFFICULT)
    317 
    318  * Extend the stack inspection primitive to allow unboxed things to be grabbed. (MODERATE)
    319 
    320340 * Add a commnad to show the current breakpoint stack (`:show context`?)
    321 
    322 === Partially done ===
    323 
    324  * The delete command. It is fairly primitive, and probably not done in the best way. This will be fixed when the API is finalised. (EASY)
    325 
    326  * Look at slow behaviour of :print command on long list of chars. I've asked Pepe about this, he has an idea of what the problem is and will be working on a solution soon. (MODERATE)
    327 
    328  * User documentation. You're looking at it. The user manual will have to move into the main GHC docs at some point. (ONGOING)
    329 
    330 === Tentative ===
    331 
    332  * Perhaps there are some redundant ticks we can delete, such as ones which begin at the same start position? (MODERATE)
    333 
    334  * Allow breakpoints to be enabled and disabled without deleting them, as in gdb. (EASY)
    335 
    336  * Extend breaks and step with counters, so that we stop after N hits, rather than immediately. (EASY/MODERATE)
    337 
    338  * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. (MODERATE/DIFFICULT)
    339341
    340342----