| ??? 06/18/07 22:59 Read: times |
#140962 - Debugging challenges Responding to: ???'s previous message |
Jan Waclawek said:
Do I understand it right, that for this sort of output, the optimisations will be kept "civilised" enough to be able to use these formats (hence the debugging tools depending on these formats)? In other words, will you have a "keep it *omf51 compatible" switch for the OCG compiler? This is something we will have to decide when we find what debugging limitations are caused by the *OMF51 formats. It may be that such an option (*omf51 compatible) could simply be an alias for an optimization level, but without knowing what the problems we will be facing I'm not willing to guess the solutions just yet. Erik Malund said:
if 3 functions (a, b and c) 'share' some common code (made common by the optimizer, not the source code) and I want to set a breakpoint when function b passes this 'optimized' code; how do you propose to stop there when only function b passes without any difference in operation/timing. This is something we'll be looking at closely. We have some ideas for ways around it and ways of at-least informing the user as to what is going on. It will also be something that may vary depending on what you are using to control the debugger. Erik Malund said:
If you plan to come up with something that changes the operation of code under debug other than when the breakpoint is reached scrap them immediately!!! There are no such plans, and based on user feedback (debug what you fly) I very much doubt that such techniques will be used without the user explicitly requesting it. At this stage I cannot explicitly state what will and will not be possible (from debugging perspective) as we are only in the early stages. But I'm confident we will be able to come up with something that is a step in the right direction. |
