RFC: FPA support removal from gdb and its impact on kgdb

[Luis Machado]

Hi,

Following the removal of Arm FPA support from GCC in ~2012, I'm pursuing the same for gdb [1].

We should be able to remove mostly everything from gdb, but there is a small portion of code that
deals with targets (like kgdb) that don't expose their register sets through XML. This code in gdb
attempts to detect the register set based on the size of the register buffer ('g' remote packet).

The problem is that CPSR was historically hardcoded to register 25 to make way for the FPA registers in the middle.

 From arch/arm/kernel/kgdb.c:

struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] =
{
         { "r0", 4, offsetof(struct pt_regs, ARM_r0)},
         { "r1", 4, offsetof(struct pt_regs, ARM_r1)},
         { "r2", 4, offsetof(struct pt_regs, ARM_r2)},
         { "r3", 4, offsetof(struct pt_regs, ARM_r3)},
         { "r4", 4, offsetof(struct pt_regs, ARM_r4)},
         { "r5", 4, offsetof(struct pt_regs, ARM_r5)},
         { "r6", 4, offsetof(struct pt_regs, ARM_r6)},
         { "r7", 4, offsetof(struct pt_regs, ARM_r7)},
         { "r8", 4, offsetof(struct pt_regs, ARM_r8)},
         { "r9", 4, offsetof(struct pt_regs, ARM_r9)},
         { "r10", 4, offsetof(struct pt_regs, ARM_r10)},
         { "fp", 4, offsetof(struct pt_regs, ARM_fp)},
         { "ip", 4, offsetof(struct pt_regs, ARM_ip)},
         { "sp", 4, offsetof(struct pt_regs, ARM_sp)},
         { "lr", 4, offsetof(struct pt_regs, ARM_lr)},
         { "pc", 4, offsetof(struct pt_regs, ARM_pc)},
         { "f0", 12, -1 },
         { "f1", 12, -1 },
         { "f2", 12, -1 },
         { "f3", 12, -1 },
         { "f4", 12, -1 },
         { "f5", 12, -1 },
         { "f6", 12, -1 },
         { "f7", 12, -1 },
         { "fps", 4, -1 },
         { "cpsr", 4, offsetof(struct pt_regs, ARM_cpsr)},
};

Changing gdb to use CPSR as register 16 (not 25) would potentially break Linux's kgdb (and also
*BSD's kgdb). Unless these -1 offsets get handled in a special way and the f<n> registers never
make their way to the register buffer in the 'g'/'G' packets.

I haven't tried to connect to a 32-bit kgdb, so I'm not sure. Could someone confirm?

But if the 'g'/'G' packets do include f<n> entries, then the FPA removal patch will cause issues for kgdb.

There are 3 solutions that I'd like to get feedback on:

(1) - Apply the gdb patch as-is and update kgdb to send XML register descriptions.

gdb has been using XML for target descriptions for a long while now. kgdb would just need to send the
hardcoded XML string. Older kgdb's wouldn't work with newer gdb's. Newer kgdb's would work with both old
and new gdb's.


(2) - Apply the gdb patch as-is and update kgdb to drop the f<n> registers.

This means kgdb needs to be updated to work with a patched/newer gdb. Older gdb's could be used with
older kgdb's. Newer kgdb's would require new gdb's.


(3) - Remove FPA from gdb, but keep a limited-time compatibility layer for gdb 13 (not released yet) and
remove it in gdb 14.

This should give kgdb's enough time to get updated with (1) or (2). Older kgdb's would require older
gdb's (<= 13).

Thoughts?

[1] https://sourceware.org/pipermail/gdb-patches/2022-September/191951.html