| | 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 | |
| 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 | | |
| 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) |