remote/2454: GDB sets register 29 on i386 upon stop for no known reason

[lkundrak at v3 dot sk]

>Number:         2454
>Category:       remote
>Synopsis:       GDB sets register 29 on i386 upon stop for no known reason
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 06 07:48:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     lkundrak@v3.sk
>Release:        gdb-6.8
>Organization:
>Environment:
Linux localhost.localdomain 2.6.25-8.fc9.i686 #1 SMP Wed Apr 23 03:56:19 EDT 2008 i686 athlon i386 GNU/Linux
This GDB was configured as "i386-redhat-linux-gnu".

Reproduced with 6.8 with lot of Red Hat patches in Fedora
Also happens to branch of gdb-6.7.50 with python support, without any additional patches
>Description:
This happens upon stop on a breakpoint:

Packet received: T054:e47d0600;5:f87d0600;8:39610900;
Sending packet: $g#67...Ack
Packet received: 405303000000000000000000a05f0900e47d0600f87d060000000000405303003961090006000000080000001000000010000000100000001000000010000000
Sending packet: $P8=38610900#60...Ack
Packet received: OK
Packet P (set-register) is supported
Sending packet: $P29=ffffffff#28...Ack
Packet received: E01
Remote failure reply: E01
(gdb)

My GDB stub returns E01 because register that is attempted to be set -- 29 -- is more than is known about; 16. "info registers" also outputs just 16 registers.

If I ignore the command, and send "OK" instead of "E01", it seems to have no impact at all.

I am wonering whether problem may lay in my remote GDB stub (that is based on one shipped with GDB) or if that's GDB's problem and if backtrace from GDB from function that sends the P command might be helpful?
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: