I hit the same problem last week. I ended up blowing away my build
directory, and the problem went away.
Probably a cache issue, but I was unable to reproduce...
On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> The lldb_cmake GreenDragon bot is now fa
>>>> > 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
uot;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
rface 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, tho
'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 mainta
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('br
