[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 #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-11 22:24:52 BST ---
(In reply to comment #15)
> (In reply to comment #14)
> > > 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?
> 
> Ah, I've worked out we've been talking at cross-purposes. I had misunderstood
> what you were asking about and as a result got myself mixed up about what bit
> you were referring to. Okay, start over, reboot, forget previous thread of
> conversation...
> 
> You say you are using TARGET_HAS_LARGE_REGISTERS. This is fine. You are right
> that stub_format_registers() cannot skip registers. We need it to skip
> registers (ditto stub_update_registers()). We will probably need to add a hook
> in generic-stub.c for this which cortexm_stub.h can define. Perhaps something
> like: 
> 
> #ifdef TARGET_G_PACKET_SKIPS_REGS
>     if ( !reg_in_g_packet( reg ) )
>         continue;
> #endif
> 
> 

This is a variation (Bug 1001559). Works for me and looks like solution.


> > 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?
> 
> Assuming you are actually using NUMREGS instead of NUMREFS, which I'm sure you
> must be, those look ok on the face of it, but obviously the problem may well be
> elsewhere. Have you set HAL_STUB_REGISTERS_SIZE for example? And if so, to
> what?

Thank you for the lead. (Bug 1001558)

> 
> In due course, you may be better off looking at the remote protocol dump, using
> either "set debug remote 1" or "set remotelogfile gdbpkts.txt" just to be sure
> what is being sent matches what you expect.
> 
> 
> > Ideally the variant/platform will only need to implement
> > CYGINT_HAL_CORTEXM_FPU.
> 
> We can probably anticipate that other Cortex-Ms will come out in the future
> with different VFP versions, or a different number or size of registers. 

My point was supposed to be: "In ideal case you don't have to add anything to
variant other than implementing the interface in order to make it fit for FPU".
In reality you need to add appropriate CFLAGS to the platform.

> This should be anticipated. So it's unlikely it will be just be a question of > FPU or
> not FPU. Maybe we should follow the example of GCC and have something like
> CYGINT_HAL_CORTEXM_VFP4_SP_D16? Or maybe just CYGINT_HAL_CORTEXM_VFP4, and then
> variants must use a CDL 'requires' to set a specific FPU implementation, such
> as SP-D16.

I have changed CYGHWR_HAL_CORTEXM_FPU to booldata so now it can select desired
FPU.

    cdl_component CYGHWR_HAL_CORTEXM_FPU {
        display          "Floating Point Unit"
        flavor           booldata
        active_if        { CYGINT_HAL_CORTEXM_FPU }
        legal_values     { "FPV4_SP_D16" }
        default_value    { "FPV4_SP_D16" }
        description      "Floating Point Unit"
cdl_option CYGHWR_HAL_CORTEXM_FPU_SWITCH {
            display "FPU context switch"
            flavor data
            legal_values { "ALL" "LAZY" "NO" }
            default_value { "LAZY" }
         ....
    }

Please comment.

Ilija

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