[Bug 1001524] Cortex-M: Remote 'g' packet reply is too long

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524

--- Comment #14 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-02 23:18:07 BST ---
(In reply to comment #13)
> (In reply to comment #12)
> > 
> > Well my statement was little bit too general. It's actually "C/C++GDB Hardware
> > Debugging" plugin that comes bundled with (some configurations of) Eclipse CDT.
> > When I tried to debug with Eclipse I got /Remote 'g' packet reply is too long:/
> > and this was the best explanation.
> > 
> > Now I got old good Zylin plugin, where I can manually set commands, and it
> > works for me (and confirms my doubt about the other one).
> > 
> > What matters, it's a non-issue for your GDB patch.
> 
> Okay. So just to be absolutely clear, do you think you have tested GDB enough
> that I should go ahead and submit this patch to upstream GDB? Or should I wait
> a bit longer?

Please hold on. My stub is still less then perfect so I can't confirm 100%
functionality (please see issues below). I hope to fix it in a couple of days.

> 
> > > > 2. Potential eCos/RedBoot issues
> > > > 
> > > > Since register numbers are not consecutive there may be issue with some stub
> > > > eCos/Redboot functions: For instance stub_format_registers() requires
> > > > consecutive numbers.
> > > 
> > > I don't think I see a real problem there. cortex-M, like many HALs, provides
> > > its own get_register() in cortexm_stub.c. So you can just return 0s for >invalid
> > 
> > I guess you mean REGSIZE() macro. I was about to ask about that as it seemed as
> > a way, though inefficient one. Now have I tried and looks OK. I'm happy for the
> > time being.
> 
> 
> Actually I did mean get_register(), which here comes from cortexm_stub.c.
> That's what stub_format_registers() calls (if !TARGET_HAS_LARGE_REGISTERS). My
> idea was to simply check the register number. However, using
> TARGET_HAS_LARGE_REGISTERS as you say you have done means in fact this is
> irrelevant.

I am little-bit confused since get_register() returns value not address.
Returned value for non-valid register is -1 not 0. Do i miss something?

I am asking this because last few FPU registers d13..d15 are not being
transfered and I haven't proper explanation. I hope you can give me some
insight.

Here are data definitions:
-------------------
cortexm_stubs.h:

enum regnames {
    R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, SP, LR, PC,
    XPSR = 25,
    D0 = 26, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15,
    FPSCR
};

#define NUMREFS (FPSCR + 1) // This counts FPA registers (16 .. 24)

#define REGSIZE( _x_ ) (_x_ <= PC ? 4 : \
                        (_x_ < XPSR ? 0 : \
                         (_x_ == XPSR ? 4 : \
                          (((_x_ >= D0) && (_x_ <= D15)) ? 8 : \
                           (_x_ == FPSCR ? 4 : 0 )))))


---------------------
hal_arch.h:

// Register layout expected by GDB VFP
typedef struct
{
    cyg_uint32 gpr[16];
    cyg_uint32 xpsr;
    cyg_uint32 s[32];
    cyg_uint32 fpscr;
} HAL_CORTEXM_GDB_Registers;

----------------------

Is above OK?

> 
> > > registers. Or arguably, an improvement might apparently be to define
> > > CYGHWR_REGISTER_VALIDITY_CHECKING in cortexm_stub.h and provide a
> > > get_register_valid() implementation. But that probably isn't worth the effort
> > > since either way the user should never see the result.
> > 
> > This would probably be even less efficient by wasting bandwidth for XXXes.
> 
> Well, the bandwidth will be exactly the same, but this is irrelevant now.
> 
> > I keep target_register_t cyg_uint32 with defined TARGET_HAS_LARGE_REGISTERS
> > It's still a development code but, now that we have STM 32F4 on board, I could
> > put it somewhere if it could speed up the development. (FYI - Lazy context
> > switching is implemented.)
> 
> Yes, using TARGET_HAS_LARGE_REGISTERS means not having to worry about
> target_register_t's size. In fact I now see that's what's done elsewhere for
> FPU regs.
> 
> Feel free to put up the code, but it's not likely I'd be able to work on
> adapting it for the F4 straight away - we're incredibly busy here at
> eCosCentric at the moment. I may be able to visually run through the patch
> though just to look for any potential problems.

Ideally the variant/platform will only need to implement
CYGINT_HAL_CORTEXM_FPU.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.