Community
Participate
Working Groups
Hi Eugene, This is a follow-up of 490228. With vxWorks ARM DKM build, I think the "Offset" for class_size is wrong (should be 12) {"ID":"@S2%802.152306D.56DE88FE.10.85C*802.152306D.56DE88FE.10.905+3.0.0.0.P2.538675288","OwnerID":"P2.538675288","UpdatePolicy":1,"Name":"class_size","TypeClass":2,"TypeID":"@S4%802.152306D.56DE88FE.10.86E*802.152306D.56DE88FE.10.905+3.0.0.0.P2.538675288","ContainerID":"@S9%802.152306D.56DE88FE.10.856+3.0.0.0.P2.538675288","Size":4,"Offset":8,"Flags":8192,"Frame":0,"Class":2} <eom> I do confirm : Both vxWorks runtime and tcf-server are in sync with latest open-source agent. With the Linux standalone build and latest open-source agent: {"ID":"@M0.@S2%802.1424AC4.56E2C3D8.1C.B6D*802.1424AC4.56E2C3D8.1C.C16+3.0.0.0.P16813.16813","OwnerID":"P16813.16813","UpdatePolicy":1,"Name":"class_size","TypeClass":2,"TypeID":"@M0.@S4%802.1424AC4.56E2C3D8.1C.B7F*802.1424AC4.56E2C3D8.1C.C16+3.0.0.0.P16813.16813","ContainerID":"@M0.@S9%802.1424AC4.56E2C3D8.1C.B67+3.0.0.0.P16813.16813","Size":4,"Flags":8192,"Frame":0,"Class":2} <eom> As you can see, there is no "Offset" field. When I look at the dwarf information between the Linux stand alone & Arm DKM, they look pretty similar to me for "class_size" field. As you said in bugzilla 489227, it looks "like tools get stale offset value" My guess would be that the fact the Expression & Symbols services are splitted with vxWorks triggers some ACPM caching issue which could explain the "stale offset value" ? I've attached the vxWorks ARM DKM, stand alone Linux version and logs. Thanks ! Xavier.
Created attachment 260252 [details] ARM VxWorks 7 DKM
Created attachment 260253 [details] Linux standalone build
Created attachment 260254 [details] Logs for vxWorks session - search mike & class_size
Created attachment 260255 [details] Log for standalone (break at p, step until Do_Nothing(Mike)
Hi Eugene, With the attached Linux process, using the standalone agent, you won't replicate the wrong "Offset" property returned. However, I guess it can be reproducible with the following setup: - tcf-server that acts like the vxWork's one: I mean it has the Symbol service but without Expression service. - agent that acts like a vxWorks's one. I mean with the Expression service but without Symbol (instead, SymbolProxy). I haven't tried yet but I think it should reproduce the problem. Do you have the config.h files that would "mimic" this vxWorks setup ? Best Regards, Xavier.
> Do you have the config.h files that would "mimic" this vxWorks setup ? This is easy: make CFLAGS=-DENABLE_ELF=0 > I haven't tried yet but I think it should reproduce the problem. No, I still cannot reproduce. Anyway, I guess caching strategy in the symbols proxy is too optimistic for ADA, I have changed it to cache less. Let me know if this fixed the problem.
Hi Eugene, > Anyway, I guess caching strategy in the symbols proxy is too optimistic for ADA, I have changed it to cache less. Let me know if this fixed the problem. I've rebased our tcf-server with latest code from open-source I've rebase our vx-works 7 runtime with latest code from open-source. With your change, our debug shell still exhibit the problem. However, there are interesting changes in the logs. I've attached a new set of logs with the ARM DKM executable. For bogus field "class_size" (good value should be 30 aka Ox1E) <--- R 73 {"ID":"@S2%802.152306D.56DE88FE.10.85C*802.152306D.56DE88FE.10.905+3.0.0.0.P2.540285392","OwnerID":"P2.540285392","UpdatePolicy":1,"Name":"class_size","TypeClass":2,"TypeID":"@S4%802.152306D.56DE88FE.10.86E*802.152306D.56DE88FE.10.905+3.0.0.0.P2.540285392","ContainerID":"@S9%802.152306D.56DE88FE.10.856+3.0.0.0.P2.540285392","Size":4,"Offset":8,"Flags":8192,"Frame":0,"Class":2} Offset is 8. Result of Expression evaluate is:"BAAAAAFNaWtlAAAAHgAAAA==" If I decode into readable format, I get: 0x04 0x00 0x00 0x00 0x01 0x4D 0x69 0x6B 0x65 0x00 0x00 0x00 0x1E 0x00 0x00 0x00 Offset should be 12 (or 9 ?) but I get 8, which is the 'e' from mike. I've attached all logs so you can see the traffic between tcf-server and our debug-agent, in case you see something. If you want me something to try, please let me know ! Best Regards, Xavier.
Created attachment 260616 [details] New log from today 28th of March
I think I know the root cause of the problem. Dynamic offset, by its nature, can only be computed in an expression. So Symbols service should not return Offset property for class_size. It does not return it in case of Linux agent, and this is correct behavior. I guess your debug shell uses Offset property when it is available, otherwise it uses Expressions service. In case of class_size, there should be no Offset property, and Expressions service is the only way to get address and value of class_size. I have committed a fix. Let me know if it works.
Hi Eugene, > I guess your debug shell uses Offset property when it is available, otherwise it uses Expressions service. Exactly ! I've tried your changes (updated my tcf-server & runtime-agent). It works. I've attached the log if you want to do a deeper check. C 76 Symbols getContext "@S2%802.152306D.56DE88FE.10.85C*802.152306D.56DE88FE.10.905+3.0.0.0.P2.538684008" <eom> R 76 {"ID":"@S2%802.152306D.56DE88FE.10.85C*802.152306D.56DE88FE.10.905+3.0.0.0.P2.538684008","OwnerID":"P2.538684008","UpdatePolicy":1,"Name":"class_size","TypeClass":2,"TypeID":"@S4%802.152306D.56DE88FE.10.86E*802.152306D.56DE88FE.10.905+3.0.0.0.P2.538684008","ContainerID":"@S9%802.152306D.56DE88FE.10.856+3.0.0.0.P2.538684008","Size":4,"Flags":8192,"Frame":0,"Class":2} <eom> There is no "Offset" field for class_size: Excellent ! I have a question for you: Expressions create "FP0.P2.538684008" null "mike" <eom> Expressions evaluate "EXPR160" <eom> "BAAAAAFNaWtl7u7uHgAAAA==" If I decode, I get [4][0][0][0][1]Mike[238][238][238][30][0][0][0] What are [238][238][238][30][0][0][0] after Mike ? This seems garbage. In other words, should the buffer be a little shorter and only contains "BAAAAAFNaWtl" ? (Not a big deal, just for my understanding. Thanks !) Thanks !
Created attachment 260662 [details] Log from 1st april 2016
