Re: [PATCH][gdb/build] Hardcode --with-included-regex

[tdevries <tdevries@suse.de>]

On 2021-04-19 21:47, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> A note on the latter: it's actually a bug to compile a regex
> using regcomp and
> Tom> then pass it to re_search.  The GNU regex interface requires one 
> to use
> Tom> re_compile_pattern or re_compile_fastmap.  But as long we're
> using one of the
> Tom> GNU regex incarnations in gnulib, glibc or libiberty, we get away
> with this.
> 
> Tom> The PR could be fixed by adding -lc in a specific position in the
> link line,
> Tom> to force regcomp to be bound to glibc.  But this solution was 
> considered
> Tom> in the discussion in the PR as being brittle, and possibly causing 
> problems
> Tom> elsewhere.
> 
> Tom> Another solution offered was to restrict regex usage to posix,
> and no longer
> Tom> use the GNU regex API.  This however could mean having to 
> reproduce some of
> Tom> that functionality locally, which would mean maintaining the same
> Tom> functionality in more than one place.
> 
> Just to be clear, using the GNU extensions isn't currently done, I
> think.

In gdb_regex.{c,h}, we have compiled_regex::search, which uses GNU regex 
function re_search.  The functionality is actually used, removing it 
breaks the gdb build.

So I don't quite understand your remark.

Thanks,
- Tom

>  I'd like to use them so GDB can avoid copying some strings to
> ensure they are \0-terminated; but this isn't done at the moment.
> 
> So, it would also be equivalent, right now, to switch GDB to conform to
> POSIX here.
> 
> Personally I'm fine with just requiring the libiberty regexp.
> That said we should probably see if there are differing opinions, or
> some reason to keep the flag.
> 
> thanks,
> Tom