[Lldb-commits] [PATCH] D39436: Add regex support to file (-f) and module (-s) breakpoint options.

[Zachary Turner via lldb-commits]

On Mon, Oct 30, 2017 at 5:47 PM Jim Ingham via Phabricator <
reviews at reviews.llvm.org> wrote:

> jingham added a comment.
>
> In https://reviews.llvm.org/D39436#911305, @zturner wrote:
>
> > In https://reviews.llvm.org/D39436#911302, @hintonda wrote:
> >
> > > In https://reviews.llvm.org/D39436#911264, @jingham wrote:
> > >
> > > > Zachary's suggestion is better than adding regex patterns to
> FileSpec, but I still don't like the idea of encoding option types in the
> option values.
> > >
> > >
> > > Are you talking about fnmatch?  Is that portable?  If not, i can
> rewrite it,.
> > >
> > > > Moreover, this doesn't really apply to the main use of -f - file &
> line breakpoints.  The only plausible use for a source file filter for file
> & line breakpoints is when you want to restrict breaking on inlined code to
> a subset of the files that inline it.  But in that case you would want a
> separate option, since you need to specify the inlined file = with the -f
> option - and the inlining files - with some other option.
> > > >
> > > > Wouldn't it be better to add a --source-file-regex option, pick some
> free single letter, and use that if you want to provide a pattern for the
> "-p" breakpoint option.  Then we could also use it when specifying some
> other file filter.
> > >
> > > This is valid for all breakpoints, not just those created via the '-p'
> option.  I can gen up patch that add `--source-file-regex` to all
> breakpoints, but I also want to use it from python, so that api change
> might be problematic -- can we add additional default parameters without
> breaking ABI?
> > >
> > > Btw, here's an example of how I want to use it -- cuts time to create
> breakpoint by over half, from 15 seconds down to 7 -- which makes my
> clangdiag module load much faster:
> > >
> > >   br s -n "DiagnosticsEngine::Report" -f "regex:.*/clang/.*"
> > >
> >
> >
> > Since you already have a python module and are creating the breakpoints
> from inside of python, couldn't you just walk the directory tree yourself
> creating breakpoints manually on each file that matches the regex?  It
> seems like one of those things that would get used once in a blue moon, and
> in my experience it's not worth adding the maintenance burden to the larger
> project for an option that someone is going to use once every couple of
> years, especially when you could just bake the logic into your application.
>
>
> You wouldn't have to do quite that much work, you'd just have to scan the
> directory tree and make up an SBFileSpecList of the files you find, then
> use:
>
>   lldb::SBBreakpoint
>   BreakpointCreateBySourceRegex(const char *source_regex,
>                                 const SBFileSpecList &module_list,
>                                 const SBFileSpecList &source_file);
>
> You still get one breakpoint, but a pretty straightforward way of doing
> it.  That's why I originally suggested adding
>
>   SBFieSpecList SBTarget::FindFilesMatchingFilenameRegex(const char
> *regex);


That would work, but what’s the advantage to putting it in the sb api?  I
think we should keep the api minimal, in this case especially, it doesn’t
even have access to any information that the script doesn’t already have,
so seems like it should just be there.

Less code in LLDB = less code we have to write tests for
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171031/ce34f218/attachment-0001.html>