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>
index | next in thread | previous in thread | raw e-mail
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?home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180608162701.GA65388>