list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: "Carlo Marcelo Arenas Belón" <>
Subject: Re: [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1
Date: Mon, 10 Dec 2018 00:51:01 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Dec 09 2018, Carlo Marcelo Arenas Belón wrote:

[+CC pcre-dev]

> JIT support was added to 8.20 but the interface we rely on is only
> enabled after 8.32 so try to make the message clearer.
> in systems where there are restrictions against creating executable
> pages programatically (like OpenBSD, NetBSD, macOS or seLinux) JIT
> will fail, resulting in a error message to the user.
> Signed-off-by: Carlo Marcelo Arenas Belón <>
> ---
>  Makefile | 12 ++++++------
>  grep.c   |  6 ++++++
>  2 files changed, 12 insertions(+), 6 deletions(-)
> diff --git a/Makefile b/Makefile
> index 1a44c811aa..62b0cb6ee6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -32,14 +32,14 @@ all::
>  # USE_LIBPCRE is a synonym for USE_LIBPCRE2, define USE_LIBPCRE1
>  # instead if you'd like to use the legacy version 1 of the PCRE
>  # library. Support for version 1 will likely be removed in some future
> -# release of Git, as upstream has all but abandoned it.
> +# release of Git, as upstream is focusing all development for new
> +# features in the newer version instead.

I think whatever we do here it makes sense to split this into its own
patch, since it doesn't have to do with this fallback mechanism.

FWIW I was trying to word this in some way that very briefly described
the v1 v.s. v2 situation. Just saying "new features" doesn't quite
capture it, e.g. some bugs in v1 are closed with some resolution like
"this isn't trivial to fix, use v2 instead".

>  # When using USE_LIBPCRE1, define NO_LIBPCRE1_JIT if the PCRE v1
> -# library is compiled without --enable-jit. We will auto-detect
> -# whether the version of the PCRE v1 library in use has JIT support at
> -# all, but we unfortunately can't auto-detect whether JIT support
> -# hasn't been compiled in in an otherwise JIT-supporting version. If
> -# you have link-time errors about a missing `pcre_jit_exec` define
> +# library is newer than 8.32 but compiled without --enable-jit or
> +# you want to disable JIT
> +#
> +# If you have link-time errors about a missing `pcre_jit_exec` define
>  # this, or recompile PCRE v1 with --enable-jit.
>  #
>  # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are
> diff --git a/grep.c b/grep.c
> index 4db1510d16..5ccc0421a1 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -405,6 +405,12 @@ static void compile_pcre1_regexp(struct grep_pat *p, const struct grep_opt *opt)
>  		die("%s", error);
>  #ifdef GIT_PCRE1_USE_JIT
> +	if (p->pcre1_extra_info &&
> +		!(p->pcre1_extra_info->flags & PCRE_EXTRA_EXECUTABLE_JIT)) {
> +		/* JIT failed so fallback to the interpreter */
> +		p->pcre1_jit_on = 0;
> +		return;
> +	}

Obviously this & what you have in 2/2 needs to be fixed in some way.

Is the issue on SELinux, OpenBSD, NetBSD etc. *how* PCRE is creating the
the JIT'd code? I.e. presumably Google Chrome's JIT engine, Java JIT and
the like work on those setup, or not? I.e. is this something upstream
can/is likely to fix eventually?

Are there cases where we can JIT, but fail for some entirely unrelated
reason, and are now hiding the error?

Are we mixing a condition where one some OS's or OS versions this just
won't work at all, and thus maybe should be something turned on in
config.mak.uname, v.s. e.g. SELinux where presumably it'll dynamically

I'm inclined to suggest that we should have another ifdef here for "if
JIT fails I'd like it to die", so that e.g. packages I build (for
internal use) don't silently slow down in the future, only for me to
find some months later that someone enabled an overzealous SELinux
policy and we swept this under the rug.

But maybe that's just dumb for some reason and we always need to do this

  reply	other threads:[~2018-12-09 23:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-09 23:00 [RFC PATCH 0/2] fallback to interpreter if JIT fails with pcre Carlo Marcelo Arenas Belón
2018-12-09 23:00 ` [RFC PATCH 1/2] grep: fallback to interpreter if JIT fails with pcre1 Carlo Marcelo Arenas Belón
2018-12-09 23:51   ` Ævar Arnfjörð Bjarmason [this message]
2018-12-10  0:42     ` brian m. carlson
2018-12-10  1:25       ` Carlo Arenas
2018-12-10  6:42       ` Junio C Hamano
2018-12-10  8:24       ` Ævar Arnfjörð Bjarmason
2018-12-11 20:11         ` Carlo Arenas
2018-12-11 20:51           ` Ævar Arnfjörð Bjarmason
2018-12-10  6:54     ` Junio C Hamano
2018-12-10  6:48   ` Junio C Hamano
2018-12-09 23:00 ` [RFC PATCH 2/2] grep: fallback to interpreter if JIT fails with pcre2 Carlo Marcelo Arenas Belón
2018-12-10  7:00   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).