Date: Fri, 8 Jun 2018 12:27:01 -0400 From: Mark Johnston <markj@freebsd.org> To: Matthew Macy <mmacy@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334827 - in head/sys: amd64/amd64 arm/arm dev/hwpmc i386/i386 kern mips/atheros mips/cavium powerpc/powerpc sys Message-ID: <20180608162701.GA65388@pesky> In-Reply-To: <CAPrugNrHh59QmFPAxhA0OUXnNe38EWqwDF9gFs=PeMB7fbOt-w@mail.gmail.com> References: <201806080458.w584w3rn006318@repo.freebsd.org> <20180608143448.GB57885@pesky> <CAPrugNrHh59QmFPAxhA0OUXnNe38EWqwDF9gFs=PeMB7fbOt-w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 08, 2018 at 09:07:53AM -0700, Matthew Macy wrote: > On Fri, Jun 8, 2018 at 07:35 Mark Johnston <markj@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180608162701.GA65388>