| ??? 06/21/07 22:17 Read: times |
#141146 - Debugging problems Responding to: ???'s previous message |
Jon Ledbetter said:
It's when more than one subroutine share some common code (optimized) and the debugger can't determine which routine is using this shared code. Code sharing is one thing that can cause 'strangeness' when debugging, in fact it's probably one of the most severe and difficult optimisations to get around, but it's not the only thing. What the OP is describing could also be described by many other optimisations or complicated code segments which prevent the debugger from accurately mapping the program memory address to the appropriate C line. These limitations can pop up from time to time and unfortunately make C level debugging almost impossible for those sections/functions. There are a few things you can try: - Vary the optimization levels (as Jon suggests) - Try a different output file format (if available) - If all else fails debug the assembler As a side note these problems can be caused by inadequate information from the compiler, debug file format limitations or even limitations in the debugger itself, making it hard to find the right place to point the 'finger of blame'. :) |
| Topic | Author | Date |
| stepping throught "c" code | 01/01/70 00:00 | |
| Optimizations. | 01/01/70 00:00 | |
| Optimization Level ? | 01/01/70 00:00 | |
| Yep, very likely the optimization | 01/01/70 00:00 | |
| Fly what you debug; Debug what you fly | 01/01/70 00:00 | |
| Fly what you TEST; TEST what you fly | 01/01/70 00:00 | |
| It's about time | 01/01/70 00:00 | |
| OH? | 01/01/70 00:00 | |
| Re: OH? | 01/01/70 00:00 | |
| If you have a very complicated calculation | 01/01/70 00:00 | |
| break it up | 01/01/70 00:00 | |
| I give up | 01/01/70 00:00 | |
Nevermind | 01/01/70 00:00 | |
| Debugging problems | 01/01/70 00:00 | |
| Update | 01/01/70 00:00 |