svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys

[Mark Johnston]

On Fri, Jun 08, 2018 at 09:07:53AM -0700, Matthew Macy wrote:
> On Fri, Jun 8, 2018 at 07:35 Mark Johnston <markj at freebsd.org> wrote:
> 
> > On Fri, Jun 08, 2018 at 04:58:03AM +0000, Matt Macy wrote:
> > > Author: mmacy
> > > Date: Fri Jun  8 04:58:03 2018
> > > New Revision: 334827
> > > URL: https://svnweb.freebsd.org/changeset/base/334827
> > >
> > > Log:
> > >   hwpmc: simplify calling convention for hwpmc interrupt handling
> > >
> > >   pmc_process_interrupt takes 5 arguments when only 3 are needed.
> > >   cpu is always available in curcpu and inuserspace can always be
> > >   derived from the passed trapframe.
> > >
> > >   While facially a reasonable cleanup this change was motivated
> > >   by the need to workaround a compiler bug.
> >
> > What is the compiler bug? Do you have disassembly of the subroutines in
> > question?
> >
> 
> We talked about this online.

Not in any more detail than is present in the commit message.

> How would that help without engaging in a huge
> diversion in to the toolchain?

If you can provide C code and point to the bug in the disassembly, that
should be enough for an LLVM bug report. I don't think that's a huge
diversion.

> There is nothing wrong with the C code so I
> resorted to a voodoo fix to get hwpmc working again. If you're volunteering
> mjg or I or you can disassemble the code prior to my change.

I'll volunteer to look at the disassembly, sure. "Nothing wrong with the
C code" isn't the bar for claiming a compiler bug though.

The fact that our NMI handler isn't re-entrant can lead to subtle
problems. If while executing the NMI handler we hit a dtrace
probe or DDB breakpoint, the iret executed upon return to the handler
will re-enable NMIs. Then, if a second NMI arrives before the handler
for the first has returned, the trapframe will be clobbered. Did you
rule out an issue like this?