Community
Participate
Working Groups
Created attachment 238762 [details] Wrong stepping into How to reproduce ================== 1. Create C project using hello world template 2. Open any c file and set break points by double-click on break point ruler as shown in the picture. 3. Right click on c file and click on Debug As->Local C/C++ Application. 4. Initially debug pointer will be at line number 27. 5. Click F6 again and again then debug pointer will go inside the fun() method as shown in picture. Observation: ============== If fun() and fun2() method are moved below the main method then debug pointer will not go inside fun method on pression F6. ================= OS: Ubuntu 13.10 =================== Eclipse version: Eclipse IDE for C/C++ Developers Version: Kepler Service Release 1 Build id: 20130919-0819 ==================
This is caused by the invalid breakpoints that are set. GDB sets them at an address that does not correspond to the line they were actually set on. In this case, they are set at the first valid address in the binary which happens to be inside your function. *** This bug has been marked as a duplicate of bug 425062 ***
After looking into bug 425062 in more detail, I no longer think these two bugs are duplicates. The problem seen here would be fixed by bug 425062, but other solutions could also be used. The problem seen here is that when we tell GDB to set a breakpoint at an invalid line, GDB will automatically set it at the first valid address but CDT does not pay attention to that. I see a couple of ways of improving this. 1- Fix bug 425062 which would prevent setting a bp at an invalid line 2- Prevent GDB from setting a bp at another line than the specified one. I didn't see any way to do this with the current GDB, so we'd need to modify GDB. 3- Have GDB notify CDT of the actual line where the bp was truly set. CDT could then somehow indicate this to the user. This also needs a modification to GDB. 4- Have CDT check every bp when set and check if the address of the bp returned by GDB actually maps to the user-specified line for the bp. If not, CDT could indicate this to the user. This may be possible without any changes to GDB. I'm not sure options 3 or 4 are the right way to go though. What would CDT do when it realized the breakpoint was set at a different line than what the user requested? We could: a) move the eclipse breakpoint to the new line. This may not be what the user wants. A bp in Eclipse can affect multiple debug sessions so moving it may affect multiple sessions. Also, a bp can be set in Eclipse at a different time than when we debug; in that case the bp will stay at the invalid line until the debug session is started, and then be moved. b) remove the breakpoint from the invalid line. That would be good if we could do it as soon as the bp is set, however, since a bp can be set when GDB is not running, it may be a long time before we realize the bp is at an invalid line. I prefer options 1 or 2.
(In reply to Marc Khouzam from comment #2) > After looking into bug 425062 in more detail, I no longer think these two > bugs are duplicates. The problem seen here would be fixed by bug 425062, > but other solutions could also be used. > > The problem seen here is that when we tell GDB to set a breakpoint at an > invalid line, GDB will automatically set it at the first valid address but > CDT does not pay attention to that. I see a couple of ways of improving > this. > > 1- Fix bug 425062 which would prevent setting a bp at an invalid line > > 2- Prevent GDB from setting a bp at another line than the specified one. I > didn't see any way to do this with the current GDB, so we'd need to modify > GDB. > > 3- Have GDB notify CDT of the actual line where the bp was truly set. CDT > could then somehow indicate this to the user. This also needs a > modification to GDB. > > 4- Have CDT check every bp when set and check if the address of the bp > returned by GDB actually maps to the user-specified line for the bp. If > not, CDT could indicate this to the user. This may be possible without any > changes to GDB. > > I'm not sure options 3 or 4 are the right way to go though. What would CDT > do when it realized the breakpoint was set at a different line than what the > user requested? We could: > > a) move the eclipse breakpoint to the new line. This may not be what the > user wants. A bp in Eclipse can affect multiple debug sessions so moving it > may affect multiple sessions. Also, a bp can be set in Eclipse at a > different time than when we debug; in that case the bp will stay at the > invalid line until the debug session is started, and then be moved. > > b) remove the breakpoint from the invalid line. That would be good if we > could do it as soon as the bp is set, however, since a bp can be set when > GDB is not running, it may be a long time before we realize the bp is at an > invalid line. > > I prefer options 1 or 2. Are there cases when some lines can be valid for one target and invalid for other? For instance, code inside the "ifdef" preprocessor statements.
(In reply to Mikhail Khodjaiants from comment #3) > Are there cases when some lines can be valid for one target and invalid for > other? For instance, code inside the "ifdef" preprocessor statements. Good point. I believe such a situation would only cause a problem for #1 which is handled in bug 425062. But it may not even be a problem since CDT should know from the compilation what part of the ifdef is valid or not. In fact, we compile for a single target at a time, so I believe this shouldn't cause a problem.
(In reply to Marc Khouzam from comment #4) > (In reply to Mikhail Khodjaiants from comment #3) > > > Are there cases when some lines can be valid for one target and invalid for > > other? For instance, code inside the "ifdef" preprocessor statements. > > Good point. I believe such a situation would only cause a problem for #1 > which is handled in bug 425062. But it may not even be a problem since CDT > should know from the compilation what part of the ifdef is valid or not. In > fact, we compile for a single target at a time, so I believe this shouldn't > cause a problem. Ir could be a problem for some CDT based products. Anyway, I just wanted to mention it here.
