[lldb-dev] What's the best way to use "--all-files" option from python?
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Wed Oct 25 11:11:37 PDT 2017
> On Oct 25, 2017, at 9:41 AM, Greg Clayton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>
> Are glob characters legal file characters on any systems? If so we can't do the auto detect where we override the meaning of -f. If not, then we can. We could add a --glob option that goes along with the -f option if glob characters are valid file system characters.
>
> There are a few breakpoint options that aren't available via the lldb::SB API layer. Not skipping the prologue for breakpoints by name and regex is one of them.
>
> It would be nice to follow other examples where we make a options class that has nice defaults and get sent to each breakpoint kind.
>
> The current API is:
>
> lldb::SBBreakpoint BreakpointCreateByName(const char *symbol_name,
> const char *module_name = nullptr);
>
> // This version uses name_type_mask = eFunctionNameTypeAuto
> lldb::SBBreakpoint
> BreakpointCreateByName(const char *symbol_name,
> const SBFileSpecList &module_list,
> const SBFileSpecList &comp_unit_list);
>
> With a breakpoint options class we would add:
>
> lldb::SBBreakpoint
> BreakpointCreateByName(const char *symbol_name,
> lldb::SBBreakpointOptions &options);
>
>
> Then we can make SBBreakpointOptions be able to set any kinds of filters we want.
>
> The missing things that come to mind are:
> - don't skip prologue
> - don't set inlined breakpoints (concrete only) (this is missing in the command line interface as well)
> - limiting to certain files or shared libraries (only available on some SBTarget::BreakpointCreateXXX() functions)
> - thread specific settings
> - hit count
> - skip count
> - setting condition on breakpoint right away instead of making another API call
I have no problem with this in general, but I don't want to have a single options class.
I want to keep the distinction between "things you can pass to a breakpoint that change what locations are set" and "things that you can pass to the breakpoint that change what you do when you hit a breakpoint". First off, keeping them separate avoid any confusion about what you can & can't change. You get read-only access to a breakpoint's setting options (maybe call these SBBreakpointSetOptions). But you get read-write access to the normal options, for instance.
So in the list above, the first 5 options can be done when setting breakpoints, but effect what locations you chose so currently can't be done after the fact. And even if we start allowing them after the fact they should stay separate because they add or remove locations, so are a very different kind of setting than the current SBBreakpointOptions. The last three are SBBreakpointOptions.
In this context, we'd add a "RestrictFilePattern" option. In the case of symbol name breakpoints it would restrict you to that symbol in this source file. In the source regex case we could use it as well as a list (sometimes a pattern is more annoying to generate than a list so we'd want both.) Even for file & line breakpoints, you want to say "set the breakpoint on the instances of SomeHeader.h, line 20 inlined INTO SomeFile.cpp". So it could have that meaning.
Doing this would mean we'd have to add one more API to all the setters,
BreakpointCreateByName(const char *symbol_name,
lldb::SBBreakpointSetOptions &set_options,
lldb::SBBreakpointOptions &options);
But that seems to me still a fairly natural API, and maintains an important distinction.
Note, that on the SBBreakpointOptions front, I recently added the ability to make a set of "breakpoint reactions" independently of any breakpoint, and then applying them to breakpoints either before or after they've been made. That seems to me a useful feature. That's what the "breakpoint names configure" command I recently added does. With it you can do:
(lldb) breakpoint name configure -c "something == something_else" -C "bt" -C "frame var" MyOptions
(lldb) break set -f whatever -l 5 -N MyOptions
and it picks up the options from MyOptions. You can even play around with the sets live, changing the configuration of MyOptions changes the behavior of the breakpoints using the name. Part of the reason for doing this is that it provides a venue for us to publicize any fancy breakpoint commands and other stop reactions we can come up with, because we can make them built in lldb names, they will show up in "breakpoint name list" - the names can have help strings so we can explain what they do...
But the setting options are a different. You can see passing the same file restrict or shlib restrict list as you make them, but if you were to change it after the fact it would have a very different effect, changing where the stops are made, than do what we currently call the options do.
Jim
>
>> On Oct 25, 2017, at 6:15 AM, Don Hinton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> I'd also like to include the path in the pattern, e.g., -f "*/clang/*", which would cut the number of files examined by about half for my use case.
>>
>>
>>
>> On Tue, Oct 24, 2017 at 7:24 PM, Zachary Turner <zturner at google.com> wrote:
>> Pass a pattern to the -f option.
>>
>> On Tue, Oct 24, 2017 at 7:18 PM Don Hinton <hintonda at gmail.com> wrote:
>> Do you mean just pass a pattern to the -f option or FileSpec?
>>
>> On Tue, Oct 24, 2017 at 6:50 PM, Zachary Turner <zturner at google.com> wrote:
>> It might be worth brainstorming if there’s ways to do this that are both intuitive and don’t require more options. As a command line user, I really value my keystrokes.
>>
>> One idea would be to use a syntax that matches that of the ‘-name’ option to the standard ‘find’ utility. This way filename pattern matching would work in a way familiar to almost everyone, no sb api options would need to be added.
>>
>>
>>
>> On Mon, Oct 23, 2017 at 6:25 PM Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> Yeah, that would be easy to implement from the command line, maybe add a --file-is-regex flag or something.
>>
>> From the SB API it would be better to have something like:
>>
>> SBFileList SBTarget.GetFileListMatchingRegex("regex")
>>
>> Please file an enhancement request for these of hack'em in if you're so motivated.
>>
>> Jim
>>
>>
>> > On Oct 23, 2017, at 6:13 PM, Don Hinton <hintonda at gmail.com> wrote:
>> >
>> > Ah, great, thanks. I just figured the default was the same for both.
>> >
>> > Just wish I could use a regex for the filename as well, which would cut down the number of files about about half.
>> >
>> > thanks again...
>> > don
>> >
>> > On Mon, Oct 23, 2017 at 6:02 PM, Jim Ingham <jingham at apple.com> wrote:
>> > Just pass an invalid FileSpec for the source file spec, like:
>> >
>> > lldb.target.BreakpointCreateBySourceRegex("printf", lldb.SBFileSpec())
>> >
>> > and it acts the same way as the --all-files option. That was pretty non-obvious, I'll update the docs.
>> >
>> > Actually, the thing you CAN'T do is get the command line behavior where lldb uses the "default file" i.e. when you run "break set -p" but don't supply a file or the --all-files option. That seemed to me less useful for a programming interface since the default file is history dependent (it's the file with "main" in it before you run, then it's where you last set a breakpoint, or where you last stopped, etc.) If you needed this behavior it would be better to have the target vend the default file, though right now that's really only maintained by the breakpoint command...
>> >
>> > Jim
>> >
>> >
>> > > On Oct 23, 2017, at 5:31 PM, Don Hinton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> > >
>> > > The only way I've been able to do it is by using the CommandInterpreter, i.e.,
>> > >
>> > > res = lldb.SBCommandReturnObject()
>> > > lldb.debugger.GetCommandInterpreter().HandleCommand('breakpoint set -p "diag::%s" --all-files -N %s' % (name, name), res);
>> > > lldb.debugger.GetCommandInterpreter().HandleCommand('breakpoint disable %s' % name, res);
>> > >
>> > > Is this the best way to do it? Can't seem to figure out how to use SBTarget.BreakpointCreateBySourceRegex() for all files.
>> > >
>> > > thanks...
>> > > don
>> > > _______________________________________________
>> > > lldb-dev mailing list
>> > > lldb-dev at lists.llvm.org
>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> >
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list