Hi
all,
Does
DSF register view supports Peripheral registers?
I
also tried to debug MIPS with DSF and gdb. But the register view
doesn’t
display any peripheral registers.
If
anyone have any idea about displaying peripheral registers in
the register view, please help me
Thanks
in advance,
Bhavana
Thank you for
pointing it out
:-) I added a new patch with a workaround. Please give it a try.
-Pawel
Malu Sasi wrote:
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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
***** Confidentiality Statement/Disclaimer ***** 