[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 #15 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-03 00:37:21 BST ---
(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


> 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?

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. 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.

Jifl

-- 
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.