Re: [PATCH 00/12] Regset rework preparations part 2

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Tue, May 27 2014, Yao Qi wrote:

> On 05/27/2014 12:36 AM, Andreas Arnez wrote:
>> This part adds a collect_regset method to all Linux regsets where it
>> had been missing.  This is necessary, but not sufficient, to make the
>> "gcore" command multi-arch capable for the affected targets.  When
>> this part is approved, I can provide a follow-on patch set that fills
>> the remaining gaps to multi-arch capable core file handling for all
>> Linux targets.
>
> Your multi-arch core file handling patches can justify the changes in
> this series.  You don't have to post them, but descriptions on how
> multi-arch core file handling needs such regset interface are useful.

OK, let's try.  The following description applies to GNU/Linux targets:

1. What's needed for multi-arch capable "gcore" functionality?

With the current implementation (see linux_make_corefile_notes_1()), the
gdbarch field 'core_regset_sections' must be set; it specifies the names
and sizes of the corefile register note sections to be written.  In
addition, the gdbarch method 'regset_from_core_section' must assign a
regset structure to each of the 'core_regset_sections'.  And all the
returned regsets must contain platform-independent 'collect_regset'
methods.

  1a. What if a target does not fulfil these requirements?

  If 'core_regset_sections' is missing, the current implementation falls
  back to the (deprecated) target method 'make_corefile_notes',
  implemented for generic GNU/Linux targets by
  linux_nat_make_corefile_notes().  This invokes the native-dependent
  fill_gregset() and fill_fpregset() global functions, or (if available)
  uses the 'collect_regset' methods for each of the regsets associated
  with ".reg" and ".reg2".  In the latter case the sizes of the register
  note sections are derived from the type definitions 'gregset_t' and
  'fpregset_t' in the native-dependent system header files.

2. What's needed for multi-arch capable core file reading?

As above, the gdbarch method 'regset_from_core_section' must be set.
The 'core_regset_sections' list is optional, and if not set, is assumed
to consist of ".reg" and ".reg2".  The register note sizes are retrieved
from the core file.  Each of the regsets returned by
'regset_from_core_section' must have a platform-independent
'supply_regset' method.

  2a. What if a target does not fulfil these requirements?

  If 'regset_from_core_section' is missing, the current code falls back
  to the 'core_read_registers' method from the core_fns object that has
  been registered by deprecated_add_core_fns().  This
  'core_read_register' method then calls one of the native-dependent
  global functions supply_gregset() or supply_fpregset(), as
  appropriate.

(4) What does the series at hand provide, and how about the follow-on
    series?

This series defines 'collect_regset' methods and, where missing, also
the 'supply_regset' methods and 'regset_from_core_section'.  Since it
does not set 'core_regset_sections', "gcore" still falls back to the
native-dependent approach, but should at least use the new
'collect_regset' methods.  Core file *reading* should be made multi-arch
capable with this series already.

My follow-on series merges 'core_regset_sections' with
'regset_from_core_section' and defines the merged method for all
GNU/Linux targets.