<div><br><div class="gmail_quote"><div dir="auto">On Mon, Oct 30, 2017 at 5:47 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jingham added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D39436#911305" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39436#911305</a>, @zturner wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D39436#911302" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39436#911302</a>, @hintonda wrote:<br>
><br>
> > In <a href="https://reviews.llvm.org/D39436#911264" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39436#911264</a>, @jingham wrote:<br>
> ><br>
> > > 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.<br>
> ><br>
> ><br>
> > Are you talking about fnmatch?  Is that portable?  If not, i can rewrite it,.<br>
> ><br>
> > > 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.<br>
> > ><br>
> > > 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.<br>
> ><br>
> > 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?<br>
> ><br>
> > 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>
> ><br>
> >   br s -n "DiagnosticsEngine::Report" -f "regex:.*/clang/.*"<br>
> ><br>
><br>
><br>
> 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.<br>
<br>
<br>
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:<br>
<br>
  lldb::SBBreakpoint<br>
  BreakpointCreateBySourceRegex(const char *source_regex,<br>
                                const SBFileSpecList &module_list,<br>
                                const SBFileSpecList &source_file);<br>
<br>
You still get one breakpoint, but a pretty straightforward way of doing it.  That's why I originally suggested adding<br>
<br>
  SBFieSpecList SBTarget::FindFilesMatchingFilenameRegex(const char *regex);</blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Less code in LLDB = less code we have to write tests for</div><div dir="auto"><br></div></div></div>