Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] DSF: register view problems 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Malu Sasi
> Sent: Tuesday, July 07, 2009 1:21 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] DSF: register view problems
> 
> 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

I suggest you to this work in CDT.  org.eclipse.dd is not longer being
worked on.  If you have some "discourage access" we can deal with in
when we review the patch.

You should be able to do what you want by extending 
org.eclipse.cdt.dsf.mi.service.MIRegisters (part of plugin
org.eclipse.cdt.dsf.gdb). 

> 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","r
> 7","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_us
> r","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
>

Back to the top