Re: [PATCH v4 10/12] [PowerPC] Add support for EBB and PMU registers

[Pedro Alves <palves@redhat.com>]

On 08/15/2018 01:06 AM, Pedro Franco de Carvalho wrote:
> From: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> 
> This patch adds support for registers of the Event Based Branching and
> Performance Monitoring Units for the powerpc linux native and core
> file targets, and for the powerpc linux server stub.
> 
> All three EBB registers are accessible.  Only a subset of the PMU
> registers can be accessed through ptrace.  Because of this, the PMU
> registers are enumerated individually in gdbarch_tdep, as opposed to
> having a single "have_pmu" flag.  This is intended to make it easier
> to add additional PMU registers in the future, since checking a
> "have_pmu" flag elsewhere in the code would no longer be correct.  The
> tdesc feature is named org.gnu.gdb.power.linux.pmu because of this.
> 
> It's unclear if it makes sense to save and restore these registers
> across function calls, since some of them can be modified
> asynchronously.  They are also not tracked in record-replay mode.
> 
> The kernel can return ENODATA when ptrace is used to get the EBB
> registers, unless a linux performance event that uses EBB is open in
> the inferior.  For this reason, the "fill" functions in the server
> stub for the ebb register sets is not implemented.
> 
> Since gdbserver writes all registers in one go before resuming the
> inferior, this error would not be detected at the time the user tries
> to write to one of the registers on the client side, and gdbserver
> would print out warnings every time it resumes the inferior when no
> ebb performance event is opened, so there is currently no
> straightforward way to handle this case.  This means the ebb registers
> in the client-side regcache can become dirty when the user tries to
> write to them, until the inferior is resumed and stopped again.

Should we make gdbserver flush the regcache after handling 'G' and 'P'
packets?

> 
> Another limitation for the ebb registers is that traceframes don't
> record if registers are available or not, so if these registers are
> collected when a tracepoint is hit and the inferior has no ebb event
> opened, the user will see zero values for all of them, instead of the
> usual <unavailable>.

That'd be nice to fix somehow, at some point.

Thanks,
Pedro Alves