RE: [cdt-dev] DSF: register view problems

["Malu Sasi" <malu.sasi@xxxxxxxxxxxxx>]

Hi Pawel,

	Similar issue was reported one year back. The problem was with
Register View when tried to debug with a MIPS gdb and DSF. A bug was
reported in Bugzila.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243726

You had made a patch to it. But sorry to say that it didn't work as
expected. 

I am currently looking into customizing register view in DSF framework.
Can you please help me. Can I do the same by extending the MIRegisters
Class of DSF org.eclipse.dd.mi.service? There are some gdb commands to
get the co- processor register values of the board. I need to integrate
it into the existing register view. When I tried to do it with CDT
framework it showed some "discouraged access". I had reported it to
nabble. Please see this link,
http://www.nabble.com/Extending-RegistersView-td17465800.html.

So we thought of migrating into DSF from CDT. There we are stuck with
issues as said early. Please find some time to help me.



Thanks in Advance,
Malu




-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Pawel Piech
Sent: Monday, July 06, 2009 10:58 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] DSF: register view problems

Hi Dimitry,
This bug hasn't been reported before, but it's something we've seen with

the memmory view as well:  The register view coalesces requests for 
individual register values into a single command  for a range of 
registers.  However, if GDB finds a problem with any of the registers it

reports an error for the entire command, so all the register values 
appear blank in the view.
I'm not sure how we should best address it.  It could be argued that GDB

should be fixed and report partial results, or QEMU should be fixed to 
support the missing registers, but neither of these would help your 
situation.  What we could do in DSF-GDB is to remove the coalescing 
completely, or add logic to request values individually in case the 
coalesced command fails, etc.  Please file a bug to track this issue, we

should be able to at least do something simple in 6.0.1.

Thanks!
Pawel

Dmitry Smirnov wrote:
> I'm observing the following problem with the register view.
> I'm debugging an ARM program, that is running on QEMU simulator.
>
> QEMU supports GDB stub API for register name/value retrieving and
changing.
> For the ARM core, it supports registers r0-r15, cpsr. There is a gap
> between ro-r15 and cpsr registers: these registers are not supported
> by QEMU and responded as bad register number.
> If Register view of CDT (in DSF debug configuration) starts displaying
> the registers from the beginnig and I scroll down row by row, every
> register is displayed as expected: correct values for r0-r15(pc) and
> error message as a value for others, correct value for cpsr.
>
> If the one of the absent register is visible on the Register view and
> I press Refresh for this view, ALL visible register becomes invalid
> ("Failed to execute MI command" as a value) including those that exist
> (registers 10-15 in the log below).
> What is interesting here, is that if one of the existing and visible
> register is selected in the view, its name and value are displayed
> correctly in the lower part of the Register view (like register number
> 10 in the log below) but not in upper half.
>
> Here is the log of the traces for this case.
>
> Shouldn't DSF skip requesting registers with empty names?
>
> 497,864 847-data-list-register-names
> 497,880
847^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r
9","r10","r11","r12"\
>
,"sp","lr","pc","","","","","","","","","","cpsr","","","","","","","","
","","","","","","","","",""\
>
,"","","","","","","","","","","","","","","","d0","d1","d2","d3","d4","
d5","d6","d7","d8","d9","d10\
>
","d11","d12","d13","d14","d15","fpsid","fpscr","fpexc","r8_usr","r9_usr
","r10_usr","r11_usr","r12_u\
>
sr","r8_fiq","r9_fiq","r10_fiq","r11_fiq","r12_fiq","r13_usr","r14_usr",
"r13_svc","r14_svc","r13_abt\
>
","r14_abt","r13_und","r14_und","r13_irq","r14_irq","r13_fiq","r14_fiq",
"spsr_svc","spsr_abt","spsr_\
> und","spsr_irq","spsr_fiq"]
> 497,880 (gdb)
> 497,895 848-data-list-register-values x 10 11 12 13 14 15 16 17
> 497,895 849-data-list-register-values N 10 11 12 13 14 15 16 17
> 497,911 848^error,msg="bad register number"
> 497,911 (gdb)
> 497,911 850-data-list-register-values x 10
> 497,926 851-data-list-register-values N 10
> 497,926 849^error,msg="bad register number"
> 497,926 (gdb)
> 497,926 850^done,register-values=[{number="10",value="0x0"}]
> 497,926 (gdb)
> 497,926 851^done,register-values=[{number="10",value="0"}]
> 497,926 (gdb)
> 497,973 852-data-list-register-values t 10
> 497,973 853-data-list-register-values o 10
> 497,973 854-data-list-register-values d 10
> 497,973 852^done,register-values=[{number="10",value="0"}]
> 497,973 (gdb)
> 497,973 853^done,register-values=[{number="10",value="0"}]
> 497,973 (gdb)
> 497,973 854^done,register-values=[{number="10",value="0"}]
> 497,973 (gdb)
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>   

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
***** Confidentiality Statement/Disclaimer *****  

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.

The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.