Re: AVX and unavailable registers, fix system-gcore.exp

[Pedro Alves <palves at redhat dot com>]

On 02/27/2012 06:04 PM, H.J. Lu wrote:
> On Thu, Jan 26, 2012 at 11:07 AM, Pedro Alves <palves@redhat.com> wrote:

>> 2012-01-26  Pedro Alves  <palves@redhat.com>
>>
>>        * i387-tdep.c (i387_supply_xsave): If we have an xsave buffer, and
>>        the register state is clear, supply explicit zero, instead of
>>        marking the register unavailable.
> 
> This fixes 7.3/7.4 regression:
> 
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=13766

Thanks for confirming.  Since you agree with the patch, I'll check it in in
a few days unless I hear otherwise.  I'll post a separate RFC patch proposing
to remove the NULL REGS handling:

>> I have a doubt in the xsave-in-corefile support bits.  There's code in place to
>> handle a NULL regs (as in no xsave contents to work with), so I'm handling it
>> as presently:
>>
>>
>> +
>> +     Note however, the case when REGS is NULL is a different case.
>> +     That case means we do not have access to the x87 states, so we
>> +     should mark the registers as unavailable (by supplying NULL).  */
>> +
>> but I can't figure out how would we ever get a NULL REGS there.  Is there a
>> convoluted path I missed?  amd64-linux-tdep.c unconditionally installs
>> amd64_linux_regset_sections as gdbarch_core_regset_sections
>> callback, and this includes the .reg-xstate section.
>> However, corelow.c:get_core_register_section bails early if
>> a section is not found in the core, never reaching regset->supply_regset
>> with a NULL `contents'.

>> +  const gdb_byte zero[MAX_REGISTER_SIZE] = { 0 };
> 
> Shouldn't it be static since it is never modified?

I'll do that change.

-- 
Pedro Alves