Explicit ./configure flags for capstone and oprofile

[orlitzky]

Description

Hello, we've noticed on Gentoo that some of our users are winding up with capstone and oprofile linked into their PHP builds "accidentally." These are used for JIT debugging, and if the configure script finds them available, it sets HAVE_CAPSTONE or HAVE_OPROFILE respectively, and prepares the build system to link with the corresponding library.

We have a big wiki page explaining why this can lead to problems, but I can sum it up in a sentence or two: sometimes, users have capstone or oprofile installed for some other reason, and not because they want to use it with PHP. If that reason changes and if the user decides to uninstall capstone (for example), doing so will break PHP if PHP was linked against capstone. Essentially the problem is that the user won't know that PHP picked up capstone or oprofile as runtime dependencies.

To fix this, the usual solution is to add explicit configure flags like --with-capstone and --with-oprofile. (Our package manager can then track the dependencies.) These features are at least nominally optional, since PHP can build without them. My main question is, does anything bad happen if someone then tries to set opcache.jit_debug to a value that uses capstone or oprofile? If not, do you foresee any other problems that I've overlooked? I've never personally debugged the JIT so I'm in over my head here.

paging @dstogov and @shqking who I see have done related work

PHP Version

git master

Operating System

No response

[iluuu1994]

My main question is, does anything bad happen if someone then tries to set opcache.jit_debug to a value that uses capstone or oprofile?

I don't think so. Your suggestion to make this flag opt-in seems reasonable.

[dstogov]

Yeah, It make sense to add --with-capstone in master branch, allow building php without disassembler, and may be completely remove oprofile and bundled libudix86.

[orlitzky]

I started work on this at #10918:

• The capstone flag was easy. I made it disabled by default because that seems to be the most common (rather than e.g. defaulting to autodetect), but I'd be happy to change it.
• I'm not 100% sure if I removed oprofile correctly, but it looked easy to do so, since everything was behind HAVE_OPROFILE or had "oprofile" in the filename.
• I haven't touched libudis86 yet because it looks a bit more complicated. In zend_jit_disasm.c, for example, the udis86 stuff is behind ZEND_JIT_TARGET_X86 and that sounds important. I'm happy to work on this though if you can give me some pointers for how to go about it.

[orlitzky]

The PR fixed the immediate problem, so I'll close this. We can do libudis86 later -- feel free to ping me about it.