From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 76C5539B586A; Wed, 21 Apr 2021 19:54:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76C5539B586A From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/27681] FAIL: gdb.base/help.exp: apropos \(print[^[ bsiedf\".-]\) (timeout) Date: Wed, 21 Apr 2021 19:54:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 19:54:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27681 --- Comment #27 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3Dff5075202958= f78e1a0bb77405e19c347d1d0bbd commit ff5075202958f78e1a0bb77405e19c347d1d0bbd Author: Tom de Vries Date: Wed Apr 21 21:54:03 2021 +0200 [gdb/build] Hardcode --with-included-regex Currently gdb has a configure option: ... $ ./src/gdb/configure --help ... --without-included-regex don't use included regex; this is the default= on systems with version 2 of the GNU C library (= use with caution on other system) ... The configure option controls config.h macro USE_INCLUDED_REGEX, which = is used in gdb/gdb_regex.h to choose between: - using regex from libiberty (which is included in the binutils-gdb.git repo, hence the 'included' in USE_INCLUDED_REGEX), or - using regex.h. In the former case, the symbol regcomp is remapped to a symbol xregcomp, which is then provided by libiberty. In the latter case, the symbol regcomp is resolved at runtime, usually binding to libc. However, there is no mechanism in place to enforce this. PR27681 is an example of where that causes problems. On openSUSE Tumbleweed, the ncurses package got the --with-pcre2 configure switch enabled, and solved the resulting dependencies using: ... $ cat /usr/lib64/libncursesw.so /* GNU ld script */ -INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl)) +INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl -lpcre2-posix -lpcre2-8)) ... This lead to regcomp being bound to libpcre2-posix instead of libc. This causes problems in several ways: - by compiling using regex.h, we've already chosen a specific regex_t implementation, and the one from pcre2-posix is not the same. - in gdb_regex.c we use GNU regex function re_search, which pcre2-posix doesn't provide, so while regcomp binds to pcre2-posix, re_search bin= ds to libc. A note on the latter: it's actually a bug to compile a regex using regc= omp and then pass it to re_search. The GNU regex interface requires one to use re_compile_pattern or re_compile_fastmap. But as long we're using one = of the GNU regex incarnations in gnulib, glibc or libiberty, we get away with this. The PR could be fixed by adding -lc in a specific position in the link line, to force regcomp to be bound to glibc. But this solution was considered in the discussion in the PR as being brittle, and possibly causing prob= lems elsewhere. Another solution offered was to restrict regex usage to posix, and no longer use the GNU regex API. This however could mean having to reproduce som= e of that functionality locally, which would mean maintaining the same functionality in more than one place. The solution chosen here, is to hardcode --with-included-regex, that is, using libiberty. The option of using glibc for regex was introduced because glibc became= the authorative source for GNU regex, so it offered the possibility to link against a more up-to-date regex version. In that aspect, this patch is a step back. But we have the option of u= sing a more up-to-date regex version as a follow-up step: by using the regex f= rom gnulib. Tested on x86_64-linux. gdb/ChangeLog: 2021-04-21 Tom de Vries PR build/27681 * configure.ac: Remove --without-included-regex/--with-included-regex. * config.in: Regenerate. * configure: Regenerate. * gdb_regex.h: Assume USE_INCLUDED_REGEX is defined. --=20 You are receiving this mail because: You are on the CC list for the bug.=