[pcre-dev] [PATCH] IBM xlc compatibility, pcretest memory-le…

Góra strony
Delete this message
Autor: Daniel Richard G
Data:  
Dla: pcre-dev
Temat: [pcre-dev] [PATCH] IBM xlc compatibility, pcretest memory-leak fixes
Hello folks,

I've put in some work on PCRE lately, and would like to submit my changes.
They largely address (1) compatibility with the IBM C compiler (xlc), and
(2) memory leaks in the pcretest test driver.

Everything is in the attached patch, against SVN trunk. A walk-through is
below:


++ RunTest

@ The initial goal here was to quell the "illegal option" error message
from older diff(1) programs; the restructuring of the conditional is a
parallel to my changes to RunGrepTest

++ pcre_jit_compile.c

@ This comment is intended to help folks who are led to that
SLJIT_MALLOC() by Valgrind. It certainly would have helped me, as
pcretest was doing the clear-the-PCRE_EXTRA_EXECUTABLE_JIT-flag thing!

++ sljit/sljitNativePPC_common.c

@ Allow this file to be compiled by IBM's xlc compiler, which specifically
supports GCC asm syntax, but does not define __GNUC__. This support can
be switched off with -qnoasm, however...

    http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruoptasm.htm


... so give a more helpful error in that case.

Use __asm__ instead of plain "asm", as the latter can be de-recognized as
a keyword with -qnokeyword=asm, and so the former is more robust:

    http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruoptkey.htm


Also, I encountered a mysterious assembly error when building with -O3
and -qfuncsect:

--------8<--------
libtool: compile:  /usr/vac/bin/xlc_r -DHAVE_CONFIG_H -I. -I/srcdir/pcre-8.30 -O3 -q64 -qfuncsect -c -M
/srcdir/pcre-8.30/pcre_jit_compile.c  -DPIC -o pcre_jit_compile.o
"/srcdir/pcre-8.30/sljit/sljitNativePPC_common.c", line 42.2: 1506-948 (W) #warning "This file may fail to compile if -qfuncsect is
used"
Assembler:
pcre_jit_compile.s: line 59973: undefined symbol "S.8704.IPRA._sljit_emit_cmp"
pcre_jit_compile.s: line 59973: illegal expression
pcre_jit_compile.s: line 59988: undefined symbol "S.8705.IPRA._compile_xclass_hotpath"
pcre_jit_compile.s: line 59988: illegal expression
pcre_jit_compile.s: line 59991: undefined symbol "S.8706.IPRA._compile_char1_hotpath"
pcre_jit_compile.s: line 59991: illegal expression
pcre_jit_compile.s: line 60000: undefined symbol "S.8707.IPRA._compile_iterator_hotpath"
pcre_jit_compile.s: line 60000: illegal expression
    1500-067: (S) asm statement generates errors in assembler output.
1586-346 (U) An error occurred during code generation.  The code generation return code was 1.
make: The error code from the last command is 1.


Stop.
make: The error code from the last command is 2.
-------->8--------

(I was using a handful of other options as well, but they had no bearing
on this failure mode.)

This error appears to be due to the inline assembly of ppc_cache_flush(),
because if I comment out the asm statement, the error goes away.

Removing -qfuncsect allows the source to compile, asm and all, so I added
a #warning for folks using the IBM compiler to help them diagnose the
problem.

@ Quelled a warning about converting a function pointer to void*

++ sljit/sljitNativePPC_64.c

@ Allow compilation with the IBM compiler and use __asm__ instead of "asm"

++ sljit/sljitConfigInternal.h

@ The IBM compiler does define __powerpc__, but not __powerpc64__, even in
64-bit mode. It does, however, define _ARCH_PPC and _ARCH_PPC64:

    http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/topic/com.ibm.xlcpp8a.doc/compiler/ref/ruoptarc.htm


++ pcretest.c

@ There were a few "if (re != NULL) ..." bits below this, and I thought,
this is silly---just check whether "re" is NULL right after the
new_malloc() call, and bail out if it is

@ "re" was being leaked

@ new_free(re) unconditionally, because we know it's not NULL

@ "re" and "f" were being leaked

@ extra->executable_jit was being leaked because an existing pcre_extra
object with JIT data would enter this block, then have its
PCRE_EXTRA_EXECUTABLE_JIT cleared, and then there was no way to
subsequently tell whether extra->executable_jit was a valid pointer or not.

I resolved this just by calling PCRE_FREE_STUDY() and allocating a new
pcre_extra object every time. (Maybe there would be a use for a
pcre_clear_study() routine, that does everything pcre_free_study() does
except for the final free().)

@ dfa_workspace was being leaked

++ autogen.sh

@ test(1) a.k.a. "[" has "=" as an operator, not "=="

++ RunGrepTest

@ Rewrote the diff check. Again, the initial goal was to quash the error
message printed by older diff programs that don't do -u. The secondary
goal was to simplify the nested shell conditionals into something more
elegant; here, I've implemented a progression from the least-desirable
diff invocation to the most. Subjectively, I think this is cleaner.


Comments and critique welcome,


--Daniel


--
Daniel Richard G. || danielg@??? || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/