Community
Participate
Working Groups
This bug covers the implementation of the registers service using standard MI protocol. Effort estimate 8, 1
Hi I am trying to enable support for multiple contexts in Register Service. I have got it working but I have doubts related to context. It would be hard to explain it in writing here but I will try as Monday is far away There are 2 ontexts MIRegisterGroupDMC and MIRegisterDMC. I cleansed the current definition for MIRegisterGroupDMC & MIRegisterDMC to make it work for multiple contexts. Since Register values are affected by frame selection, So we are passing IFrameDMContext instead of IExecutionDMContext public MIRegisterGroupDMC(MIRegisters service, IFrameDMContext frameDmc, int groupNo, String groupName) { super(service.getSession().getId(), service.getServiceFilter(), new IDMContext[] { frameDmc, service.getServiceContext() }); fGroupNo = groupNo; fGroupName = groupName; } public MIRegisterDMC(MIRegisters service, MIRegisterGroupDMC group, int regNo, String regName) { super(service.getSession().getId(), service.getServiceFilter(), new IDMContext[] { group }); fRegNo = regNo; fRegName = regName; } Problem is solved and it works fine but it doesn't seem right to me. Acc to me MIRegisterGroupDMC shouldnt have any dependence on Frame context as Register Group does not change due to Frames. Whereas Register context should be defined by Register Group Context and Frame Context. I started with this assumption but stumbled first bcoz interface didn't support this theory as we will need to pass two contexts to getRegisters command (RegisterGroup context and Frame context)and also updateLabels and updateElements in session thread is not invoked when different stack frame in different execution context is selected. ie. If you have 2 contexts and registers for the second context is being displayed. Now you go to the first execution context and select a frame in it, updateElements or labels is not invoked. May be because register view is not listening to changes/selection in debug view ?? Or is it something else ? Which approach is right according to you & Why ? Veenu
(In reply to comment #1) > Acc to me MIRegisterGroupDMC shouldnt have any dependence on Frame context as > Register Group does not change due to Frames. > Whereas Register context should be defined by Register Group Context and Frame > Context. I think your assumption is correct. IRegisterGroupDMContexts should not depend on current frame, they should probably really depend on IContainerDMContext. And I believe that your conclusion is also correct: IRegisters.getRegisters() should take two arguments: IRegisterGroupDMContext and a generic IDMContext<?>, which could be the frame context. We should probably also make the group context optional, so that optionally all registers in all groups could be retrieved at once. I created a separate bug for this and assigned it to Randy. > I started with this assumption but stumbled first bcoz interface didn't support > this theory as we will need to pass two contexts to getRegisters command > (RegisterGroup context and Frame context)and also updateLabels and > updateElements in session thread is not invoked when different stack frame in > different execution context is selected. ie. If you have 2 contexts and > registers for the second context is being displayed. Now you go to the first > execution context and select a frame in it, updateElements or labels is not > invoked. May be because register view is not listening to changes/selection in > debug view ?? Or is it something else ? > No I don't know why this would be, the view shoudl be refreshed when you change the selection. When I change stack frame selection, the view updates correctly. I want to try your use case with the multi thread example but I can't seem to build it in a CDT project because it chokes on the pthread calls (any hints?).
(In reply to comment #2) > No I don't know why this would be, the view shoudl be refreshed when you > change > the selection. I am attaching a patch with the necessary changes. Apply it and then perform the following steps. 1. Step till you have 2 execution contexts 2. Once you have the second execution context, check the values of the register and then select execution context 1 and stack frame 0 and check the value of register again. Its the same. In updateLabels... update does not report the new selection which is execution frame 1. It still reports the execution context 2 as the selection. Same with changing frames. In TreeModelLabelProvider class, value of elementPath on selecting the first execution context and frame 0 is .container#registers.group[0].container.thread[2]#stack.frame[0].register[0] ?????? > When I change stack frame selection, the view updates > correctly. I want to try your use case with the multi thread example but I > can't seem to build it in a CDT project because it chokes on the pthread > calls > (any hints?). You need to include pthread library in Properties under Tool settings->Gcc C++ linker->Libraries. Add 'pthread' library there. Veenu
Created attachment 77877 [details] Multiple context in Registers Hi Pawel, Here comes the temporary patch for testing the above behavior.
I reproduced the bug and tracked it down to the VMCache module, and I filed bug 202680 for it. The request for list of registers is made for the register group DMC element, and prior to your change, the register group DMC included the frame DMC and exec DMC. So, when a different thread or frame was selected, the cache which uses the element as key would not find the new key in the cache and would request the data from the service. However after your change, the register group element is the same regardless of which thread or frame is selected, so the cache would return the same values. As far as the register service changes I think it looks very good. My only comment is that the registers should be retrievable even if a thread is selected in debug view. So RegisterLayoutNode cannot depend on the frame context being present in the path, and should look for either the frame context or execution context, maybe even container context. Also I would like to hear from Randy before making the register interface change.
Hi Pawel, What behavior do we need for showing register group ? In CDT, register are only shown when a stack frame is selected. In DSF, we have Register groups and registers beneath it. According to my understanding Register groups ideally should be shown for a container context and registers for the execution context and the frame context. Or other idea is to just show register groups with register names for container context and register names + values for execution context and frame context. But I see problems in implementing like this. If register groups are shown for container context then RegisterDMC doesn't have an execution context which is the cause of the problem as to build registers one need execution context for getting value and type of register. To avoid that we can have 2 constructors for RegisterDMC's. public MIRegisterDMC(MIRegisters service, MIRegisterGroupDMC group, int regNo, String regName) public MIRegisterDMC(MIRegisters service, MIRegisterGroupDMC group, IMIExecutionDMContext dmc, int regNo, String regName) So that we can build registerDMC without value or type for container context so that register names can be seen when a container is selected. This register DMC will only have name and null/blank for value and type. And second one will be used when Execution context is present. And this will rightly show the value and type as well along with the name This has problem because UI tends to cache stuff too. When context is changed to some execution context from the container context the cache is used and getRegisters which rebuilds registerDMCs is not called. The only way it seems to work fine is to show register group and registers when execution or frame context is selected which means to have the following constructor public MIRegisterDMC(MIRegisters service, MIRegisterGroupDMC group, IMIExecutionDMContext dmc, int regNo, String regName) This will not allow register groups at container level. What's ur take ? Which option shall we chose ? ****************************************************************************** Another question is regarding format...I don't see a way to select formats in register view. Do we need to implement in Register view or shall it be available from the platform ? ****************************************************************************** CDT shows actual type & declared type column in Register views and DSF doesn't. Any reason for that ? or shd we also have this column ??? **************************************************************************** Last thing that i noticed and may be an irritant to the user is that we collapse the group when a new context is selected in debug view. CDT keeps it open all the time. I think its a bit irritating to keep expanding it when thread switches automatically or when u switch the context. If we want to keep it this way due to register views possibly having multiple groups then we should provide a way to pin the group that we wanna watch. Veenu
(In reply to comment #6) You've touched on a lot of open issues in DSF UI. I'll try to answer your questions best I can. > ... > What's ur take ? Which option shall we chose ? The fact that the values are cached accross different contexts is a bug in the cache: bug 202680, it has a dependency on a platform bug, but we could work around it for a time being. I think it's fine to allow a register context to be created without an execution context, and have the service not return any value when its evaluated. IMO this is the correct implementation if you with to show the registers when only the container is selected. I have no opinion whether this would be useful for the end users though, I think you may have a better idea about that. > **************************************************************************** > Another question is regarding format...I don't see a way to select formats in > register view. Do we need to implement in Register view or shall it be > available from the platform ? There is also a bug for this: bug 197358. Randy never got to fixing this when he implemented the number formats in the first place. There is also bug 202556, which is to allow setting the format for individual variables/registers, which is something CDT has as well. > **************************************************************************** > CDT shows actual type & declared type column in Register views and DSF doesn't. > Any reason for that ? or shd we also have this column ??? We certainly could. Although is there ever a difference between declared type and actual type for registers? This could be a left over from the fact that CDT shares its UI presentation with Java, which is capable of retrieving the information about declared and actual type for variables. > **************************************************************************** > Last thing that i noticed and may be an irritant to the user is that we > collapse the group when a new context is selected in debug view. CDT keeps it > open all the time. I think its a bit irritating to keep expanding it when > thread switches automatically or when u switch the context. If we want to keep > it this way due to register views possibly having multiple groups then we > should provide a way to pin the group that we wanna watch. > This is something that we can do by taking advantage of a new flexible-hierarchy interface added by platform in 3.4. I filed bug 211487 for it. However, we can only keep the view from refreshing (collapsing and re-expanding) when switching stack frames, because registers are the same for all stack frames. Separately, we can force the register view to re-use the same information about which groups are expanded regardless of which thread is selected in debug view. I filed bug 211487 to track that issue. Thanks you for your diligence :-)
Hi Pawel, Patch with contexts sorted and writeRegister implemented. Since view cache is not working properly (bug 202680) therefore cached values will be seen when context is changed but applying Refresh button will show the actual values. Let me know if its alright to commit this. I can disappear anytime now :) so I will do frequent patching followed by committing so that you get the latest. Now I am working on Format. Veenu
Sounds good Veenu, although I think you forgot to attach the patch. Don't worry, just commit the changes to CVS, and I'll look at the diffs when I synchronize. BTW, there's good news on the update modes bug. Platform fixed bug 202678, which opens the way for us to fix this bug :-)
Hi Yes, I forgot to attach the patch :) Sorry !!! I have committed the changes now. Will you commit changes for DSF bug #202680 (dependent on platform bug)? I was looking into UTCs for MIRegisters. We are using CompositeDMContext in MIRegisters. Is there a way to handle this from UI? Veenu
(In reply to comment #10) > Will you commit changes for DSF bug #202680 (dependent on platform bug)? Yes, although I want to talk to Ted first to make sure that I don't break the nightly build with a depencency to new platform API. > I was looking into UTCs for MIRegisters. We are using CompositeDMContext in > MIRegisters. Is there a way to handle this from UI? I must have missed something, what does UTC stand for?
Hi My lazyness....UTC means Unit test case :) (In reply to comment #11) > I must have missed something, what does UTC stand for? >
Hi > I was looking into UTCs for MIRegisters. We are using CompositeDMContext in > MIRegisters. Is there a way to handle this from UI? I think I was half asleep when I wrote it. I meant handling it from non UI. To test MIRegisters service from unit tests, we need to have CompositeDMContext object (we need both treepath and viewerInput). viewerInput shd most probably be IVMContext object. Is there a way to handle test case for this ? Like constructing CompositeDMContext to get different contexts
Hi Pawel, I couldn't find any "Type" column in DSF register view. Though we are evaluating whether a register is float or not but we are not using it anywhere as far as I know. The only columns available are Name, description and Value. In CDT on the other hand there is no description column and there exists Declared Type and Actual Type along with Name and value. In declared type column, type is shown as int, void * , union etc. If we plan to have type column in DSF(we did have some discussion about its usability, if you remember) then probably we should open a bug for this and it should describe the "Type" as in CDT rather than just stating if its float or not. Else we shd clean the code in service where we are finding whether the register is float or not. Also I don't see any point in having description column as there is no description for the register atleast in GDB. What do you think ??? Veenu
(In reply to comment #14) You make a good point about the type, I created bug 212839 to track this issue. Note that in order for the MIRegisters implementation to calculate the type, it will have to evaluate an expression of format "$<register name>". Evaluating the register expression is also how CDI-MI discovers bit fields for registers. As far as the description column it has a use-case with the Wind River debugger, as well as other hardware debuggers.
This is an umbrella bug for the 1.0 release to capture bugs related to the registers service implementation. Based on the comments above, I believe we can close out this bug and address individual bugs in the registers service as needed.
Marking as fixed (see previous comment). Randy please review.
I agree Randy
Thanks Randy. BTW, as this was the first data service implemented, it was especially fun... nice job :-)
Closing out 1.0 bugs.
