Re: [PATCH v2 3/3] [PowerPC] Fix debug register issues in ppc-linux-nat

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Franco de Carvalho wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
> 
> > Can we simply store the installed slots map in here, instead of requiring
> > a whole new per-lwp map in m_installed_hw_bps?
> 
> I had considered doing this, however, low_new_fork needs to copy the
> per-lwp state in case the debug registers are copied across forks, and
> this function is called before the lwp_info object for the new forked
> thread is constructed, which only happens in
> linux_nat_target::follow_fork.

Huh, indeed.  It is strange that linux_handle_extended_wait creates
the new lwp_info for PTRACE_EVENT_CLONE events, but *not* for
PTRACE_EVENT_FORK / PTRACE_EVENT_VFORK.  In the end, maybe everything
would be simpler if we did that ...

But that's probably not something that should hold up this patch,
so I guess I'm fine with the extra list.


> >> +ppc_linux_nat_target::hwdebug_point_cmp
> >> +(const struct ppc_hw_breakpoint &a, const struct ppc_hw_breakpoint &b)
> >
> > You're using this style in a number of places, but I don't think this
> > complies with the GNU coding style ...   (The '(' should not be in the
> > first column.)
> 
> I will change this.  I had done this because even if I broke the line
> after the first argument, the line still had more than the soft limit of
> columns (74):
> 
> ppc_linux_nat_target::hwdebug_point_cmp (const struct ppc_hw_breakpoint &a,
> 					 const struct ppc_hw_breakpoint &b)

As long as it's under 80 columns, I think this should be fine.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com