GDB trunk has a test failure on ARM,

   FAIL: gdb.base/gcore.exp: corefile restored general registers

In short, this failure is caused by output of 'info registers' before
coredump doesn't match output of 'info registers' when corefole is
loaded again, there are mainly two differences, [1] and [2].

Output before coredump,
r0             0x12008  73736^M
r1             0xbea1f0c0       -1096683328^M
[...]
sp             0xbea1f0a4       0xbea1f0a4^M
lr             0x849b   33947^M
pc             0x83fc   0x83fc <terminal_func+4>^M
cpsr           0x20000030       536870960^M

Output when corefile is loaded,
r0             0x12008  73736^M
r1             0xbea1f0c0       3198283968^M  // <---- [1]
[...]
sp             0xbea1f0a4       0xbea1f0a4^M
lr             0x849b   33947^M
pc             0x83fc   0x83fc <terminal_func+4>^M
fps            0x727a622f       1920623151^M  // <---- [2]
cpsr           0x20000030       536870960^M

The difference [1] is caused by different register types, uint32 vs.
int32.  In tdesc, the type of general register is "int", while in
arm_register_type, it is regarded as builtin_uint32.  This can be fixed
when register type is handled in a consistent way (in reg_type.patch).

The difference [2] is about displaying "fps" in output of "info
registers".  In default_register_reggroup_p, the group of register is
determined by the type of register, which is not very precise.  FPS
should be in float group, but its type is INT.  This can be fixed by
defining ARM's own register_reggroup_p to override
default_register_reggroup_p (in arm_fps_group.patch).

Regression tested with combination of
"\{-mthumb,-marm\}\{-fstack-protector,-fno-stack-protector}\{-march=armv7-a,-march=armv5t\}".

OK for mainline?

-- 
Yao (齐尧)