Community
Participate
Working Groups
Build ID: CDT 3.1.0.200606261600 Steps To Reproduce: Hi, I have a problem with Variables View and locals variables with CDT 3.1. Not that it works fine with CDT 3.0. With our core and debugger, the locals could be known by the debugger but they're accessible only when used.They have a limited scope. In debug mode, when the program is stopped in a function, the CDT asks for the debugger the list of locals. Our debugger returns the list of locals of the function. (gdb) 58-stack-list-locals 0 58^done,locals=[name="n_locale"] Then CDT asks the debugger to create the associated variables (see createLocalVariable method in LocalVariable class). It may fail because the locals are not yet being used (not in scope). In MIVarCreate class, getMIInfo() method, the MIOutput is well parsed and the locals appear with an error icon(see variablesView1.jpg). The locals are then added to the variableList. Fine. (gdb) 64-var-create - * n_locale &"No symbol \"n_locale\" in current context.\n" &"N/A\n" 64^error,msg="N/A" The list of variables have to be updated on futher suspend events (processSuspendedEvent method in EventManager class). Then CDT tries to update these locals but as they've not been successfully created, the update fails and generates an exception when tryings to get the MIVar (varName = variable.getMIVar().getVarName() ) even if the debugger is now able to update the locals. So, at this stage, I've modified a little the method "update(Target)" in VariableManager class. In the patch attached, if the update fails, I try to create again the variable and tries to update it. If it succeeds all is fine, elsewhere I throw a CDI Exception. With this patch, the locals are always updated when needed. If you need more details, I would be happy to discuss about it. Feel free to comment the attached patch. Regards, Jerome Correnoz More information:
Created attachment 56388 [details] Patch for VariableManager.java
Created attachment 56389 [details] Patch for Variable.java
Created attachment 56390 [details] Diff between CDT 3.1 and modified file
Created attachment 56391 [details] Diff with CDT 3.1
Bonjour, I can understand the problem, but have some difficulties with the patch, can you generate it with unified context, 'diff -u'. Also having a test case, will be great 8-). Is this with C++, which version of gdb?
Created attachment 56396 [details] Diff Variable.java with CDT 3.1
Created attachment 56397 [details] Diff VariableManager.java with CDT 3.1
I've just added the patch with 'diff -u'. Please let me know if it is OK now. It is with C source code. The debugger used is our debugger for MMDSP core. Is is based on GNU gdb 5.3 I don't know how to reproduce it with another toolchain like gcc for example... To reproduce (if you can): 1- Set a BKP at the beginning of a function (any)that contains locals 2- When stopped at the previous BKP, all the locals can't be created, they all appear with an error icon in Variables view. 3- set a BKP further in the same function somewhere some/all the locals are visible 4- Resume 5- When the 2nd BKP is reached, all the locals are still displayed with an error icon even if the debugger is now able to see the locals. Could the MI trace help you ? Jerome
Jerome, Your diff patches are reverse 8-).
Created attachment 56706 [details] Diff Variable.java with CDT 3.1
Created attachment 56707 [details] Diff VariableManager.java with CDT 3.1 Diff in correct order.
So if I read your PR correctly the variable Peer(MIVar) is not created and you are proposing to retry to recreate when doing the updates. For the purpose of documenting this PR, I am putting an excerpt of your email: "The bug is effectively particular but can be found with several optimizing compilers. No sure any compiler will allow to reproduce it. Why this happens? simply because the compiler allocates a register to a variable and does it only during the real lifetime of the variable. The register is used for other purposes when the variable is not alive." > Could the MI trace help you ? It would be nice and would further document the problem, since I can not reproduce it in my environment.
Code changed to the head for 4.0M5, Jerome can you retest please, the fix is base on your patch.
If you've checked it in, you should mark it fixed. Jerome, you can mark it verified if it does fix the problem.
Marking fixed since patch was applied.
