Re: [testsuite patch] for: [PATCH] [PR corefiles/17808] i386: Fix internal error when prstatus in core file is too big

[Andreas Arnez <arnez@linux.vnet.ibm.com>]

On Fri, Jan 09 2015, Mark Kettenis wrote:

>> Date: Fri, 09 Jan 2015 20:11:04 +0000
>> From: Pedro Alves <palves@redhat.com>
>> 
>> ...
>> I think we're saying the same thing, but what I'm calling "expected",
>> you're calling "maximum".  As in, consider the case where GDB
>> about a regset section that is supposed to have size A.  GDB is taught
>> about this, with "minimum" == A, and "expected/maximum" == A.  Later at
>> some point, a new variant of the machine appears with more registers, and
>> the regset is extended, to size B.  A GDB that only knows about A encounters
>> a core dump with B, and thus issues a warning (which suggests that either
>> more info is available that gdb doesn't grok, or the core is broken), but still
>> presents the A registers to the user.  Later, someone teaches GDB about B
>> registers, and at that point, "minimum" stays A, but "expected/maximum" is
>> set to B.  At some point, if the regset is extended further to C, a GDB
>> that knows about A and B warns when it sees C.  And on and on.  I think
>> we've already seen something like that with the x86 xsave regset?
>
> Yes, the x86 "FPU" register set certainly is an example I had in mind.
> It all started when SSE was introduced.

Right, the floating point register set has grown over time.  The good
thing is that x86 Linux platforms represent the different FPU regset
versions with different target descriptions.  (As determined from a core
file with the core_read_description gdbarch method.)  In this way the
regset size passed to the iterator callback could match the "expected"
size, not just the minimum.  However, the size is currently not
calculated at all for ".reg-xstate".  I think this should be fixed,
probably by using X86_XSTATE_SIZE.