Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run dotest.py in bare board like ARM or other non-x86 architecture?

2017-10-24 Thread cui bixiong via lldb-dev
Hi

sorry, i'm confuse, in my mind, lldb-server maybe like gdb-server,
running on Linux-like platform  listening RSP command which send form gdb
and use ptrace syscall to debug which you want to debug program

is it support remote download to batch mode run all testsuite?
certainly i think reset baseboard is very important feature too,  but in
lldb-server maybe not support currently i guess.

Best Regards
--cuibixiong

On Mon, Oct 23, 2017 at 11:06 PM, Greg Clayton  wrote:

>
> > On Oct 22, 2017, at 6:21 AM, cuibixiong via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi
> >
> >   did anyone konw LLDB support lldb + openocd to run dotest.py in
> bare board like ARM or other non-x86 architecture?
>
> We run the test suite on iOS devices using the platform stuff. This
> requires a running lldb-server on the remote system, so we only have the
> test suite running when we have the lldb-server running in platform mode on
> the other side. For this to work with baseboards, we would need the JTAG
> box to respond to many GDB remote protocol packets that "lldb-server
> platform" implements. I am sure for baseboards the test suite would need to
> be modified. A few ideas there:
> - Have the test suite watch for a triple with no os (like
> "arm64-none-none") and have it go into a baseboard mode
> - Many tests that might rely on writing to files, reading from files for
> stdin, and others, would need to be skipped in this mode
> - Any tests that build and debug shared libraries would either need to be
> modified to build multiple static binaries or skipped
> - We might need to make a Bareboard platform and would load the ELF files
> into memory instead of copying them over like the current platforms do
>
> So there would be quite a lot of modifications required to get the test
> suite running. We will be happy to help you if you choose to try this.
>
> Greg Clayton
>
> >
> > Best Regards
> > —cuibixiong
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 35053] New: lldb-server fails to link on linux - undefined reference to 'pthread_atfork'

2017-10-24 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=35053

Bug ID: 35053
   Summary: lldb-server fails to link on linux  - undefined
reference to 'pthread_atfork'
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: sylves...@debian.org
CC: lab...@google.com, llvm-b...@lists.llvm.org

Seems to be caused by r316368

../../../../lib/liblldbUtility.a(Log.cpp.o):Log.cpp:function
lldb_private::Log::Initialize(): error: undefined reference to 'pthread_atfork'

adding the -lpthread after the list of static libs fixed the issue.

Building with -DLLVM_LINK_LLVM_DYLIB=ON & -DLLVM_BUILD_LLVM_DYLIB=ON

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] did anyone konw LLDB support lldb + openocd to run dotest.py in bare board like ARM or other non-x86 architecture?

2017-10-24 Thread Greg Clayton via lldb-dev

> On Oct 24, 2017, at 12:02 AM, cui bixiong  wrote:
> 
> Hi
> 
> sorry, i'm confuse, in my mind, lldb-server maybe like gdb-server, 
> running on Linux-like platform  listening RSP command which send form gdb and 
> use ptrace syscall to debug which you want to debug program
> 
> is it support remote download to batch mode run all testsuite? certainly 
> i think reset baseboard is very important feature too,  but in lldb-server 
> maybe not support currently i guess.

Yes lldb-server does support a full connection to a remote OS. On baseboards 
you are typically debugging the entire OS so lldb-server won't work because you 
have to OS to run it in the background. Supporting the test suite on baseboards 
will take some effort.
> 
> Best Regards
> --cuibixiong
> 
> On Mon, Oct 23, 2017 at 11:06 PM, Greg Clayton  > wrote:
> 
> > On Oct 22, 2017, at 6:21 AM, cuibixiong via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Hi
> >
> >   did anyone konw LLDB support lldb + openocd to run dotest.py in bare 
> > board like ARM or other non-x86 architecture?
> 
> We run the test suite on iOS devices using the platform stuff. This requires 
> a running lldb-server on the remote system, so we only have the test suite 
> running when we have the lldb-server running in platform mode on the other 
> side. For this to work with baseboards, we would need the JTAG box to respond 
> to many GDB remote protocol packets that "lldb-server platform" implements. I 
> am sure for baseboards the test suite would need to be modified. A few ideas 
> there:
> - Have the test suite watch for a triple with no os (like "arm64-none-none") 
> and have it go into a baseboard mode
> - Many tests that might rely on writing to files, reading from files for 
> stdin, and others, would need to be skipped in this mode
> - Any tests that build and debug shared libraries would either need to be 
> modified to build multiple static binaries or skipped
> - We might need to make a Bareboard platform and would load the ELF files 
> into memory instead of copying them over like the current platforms do
> 
> So there would be quite a lot of modifications required to get the test suite 
> running. We will be happy to help you if you choose to try this.
> 
> Greg Clayton
> 
> >
> > Best Regards
> > —cuibixiong
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> > 
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 35053] lldb-server fails to link on linux - undefined reference to 'pthread_atfork'

2017-10-24 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=35053

lab...@google.com changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 35061] New: [lldb] python scripts contain duplicated copies of basic utilities

2017-10-24 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=35061

Bug ID: 35061
   Summary: [lldb] python scripts contain duplicated copies of
basic utilities
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dav...@freebsd.org
CC: llvm-b...@lists.llvm.org

Forked from the mailing list discussion. At least is_exe and which are repeated
many times (some of these  are symlinks).

[davide@cupiditate lldb]$ grep -R 'def is_exe' *
packages/Python/lldbsuite/test/dotest.py:def is_exe(fpath):
packages/Python/lldbsuite/test/lldbtest.py:def is_exe(fpath):
packages/Python/lldbsuite/test/benchmarks/disassembly/TestDisassembly.py:def
is_exe(fpath):
packages/Python/lldbsuite/test/lldbutil.py:def is_exe(fpath):
scripts/Xcode/build-llvm.py:def is_executable(path):
test/testcases/dotest.py:def is_exe(fpath):
test/testcases/lldbtest.py:def is_exe(fpath):
test/testcases/benchmarks/disassembly/TestDisassembly.py:def is_exe(fpath):
test/testcases/lldbutil.py:def is_exe(fpath):
utils/test/llvm-mc-shell.py:def is_exe(fpath):
utils/test/disasm.py:def is_exe(fpath):
utils/test/run-until-faulted.py:def is_exe(fpath):
utils/lui/lldbutil.py:def is_exe(fpath):
[davide@cupiditate lldb]$ grep -R 'def is_exe' * |wc -l
13

We should have a single implementation in utils/ and include it from
everywhere.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] build failure

2017-10-24 Thread via lldb-dev
[ 93%] Linking CXX executable ../../../../bin/lldb-server
../../../../lib/liblldbUtility.a(Log.cpp.o): In function 
`lldb_private::Log::Initialize()':
Log.cpp:(.text._ZN12lldb_private3Log10InitializeEv+0x11): undefined reference 
to `pthread_atfork'
collect2: error: ld returned 1 exit status
make[2]: *** [tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/
build.make:342: bin/lldb-server] Error 1
make[1]: *** [CMakeFiles/Makefile2:82665: tools/lldb/tools/lldb-server/
CMakeFiles/lldb-server.dir/all] Error 2

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] [Bug 35062] New: [META] Many test failures on Fedora 25

2017-10-24 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=35062

Bug ID: 35062
   Summary: [META] Many test failures on Fedora 25
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dav...@freebsd.org
CC: llvm-b...@lists.llvm.org

=
Issue Details
=
FAIL: test_expr_commands_dwarf
(expression_command/radar_9673664/TestExprHelpExamples.py)
FAIL: test_expr_commands_dwo
(expression_command/radar_9673664/TestExprHelpExamples.py)
FAIL: test_expr_commands_gmodules
(expression_command/radar_9673664/TestExprHelpExamples.py)
FAIL: test_more_expr_commands_dwarf (expression_command/test/TestExprs2.py)
FAIL: test_more_expr_commands_dwo (expression_command/test/TestExprs2.py)
FAIL: test_more_expr_commands_gmodules (expression_command/test/TestExprs2.py)
FAIL: test_top_level_expressions_dwarf
(expression_command/top-level/TestTopLevelExprs.py)
FAIL: test_top_level_expressions_dwo
(expression_command/top-level/TestTopLevelExprs.py)
FAIL: test_with_dwarf (lang/cpp/lambdas/TestLambdas.py)
FAIL: test_with_dwo (lang/cpp/lambdas/TestLambdas.py)
FAIL: test_with_gmodules (lang/cpp/lambdas/TestLambdas.py)
UNEXPECTED SUCCESS: test
(functionalities/thread/concurrent_events/n_watch_n_break/TestConcurrentNWatchNBreak.py)
UNEXPECTED SUCCESS: test_dwarf
(functionalities/thread/exit_during_break/TestExitDuringBreak.py)
UNEXPECTED SUCCESS: test_dwo
(functionalities/thread/exit_during_break/TestExitDuringBreak.py)
UNEXPECTED SUCCESS: test_gmodules
(functionalities/thread/exit_during_break/TestExitDuringBreak.py)
UNEXPECTED SUCCESS: test_lldbmi_gdb_set_target_async_off
(tools/lldb-mi/TestMiGdbSetShow.py)
UNEXPECTED SUCCESS: test_lldbmi_process_output
(tools/lldb-mi/syntax/TestMiSyntax.py)
UNEXPECTED SUCCESS: test_lldbmi_settings_set_target_run_args_after
(tools/lldb-mi/interpreter/TestMiInterpreterExec.py)
UNEXPECTED SUCCESS: test_restart_bug
(functionalities/signal/raise/TestRaise.py)
UNEXPECTED SUCCESS: test_with_dwarf (lang/cpp/printf/TestPrintf.py)
UNEXPECTED SUCCESS: test_with_dwo (lang/cpp/printf/TestPrintf.py)
UNEXPECTED SUCCESS: test_with_gmodules (lang/cpp/printf/TestPrintf.py)
TIMEOUT: test_sb_api_listener_event_description_dwo
(api/multithreaded/TestMultithreaded.py)

===
Test Result Summary
===
Test Methods:   2662
Reruns:0
Success:1695
Expected Failure:147
Failure:  11
Error: 0
Exceptional Exit:  0
Unexpected Success:   11
Skip:797
Timeout:   1
Expected Timeout:  0
FAILED: cd /home/davide/work/build-lldb/tools/lldb/test && /usr/bin/python2.7
/home/davide/work/llvm-lldb/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /home/davide/work/build-lldb/bin/lldb -s
/home/davide/work/build-lldb/lldb-test-traces -S nm -u CXXFLAGS -u CFLAGS -C
/home/davide/work/build-lldb/bin/clang-5.0 --env ARCHIVER=/usr/bin/ar --env
OBJCOPY=/usr/bin/objcopy
ninja: build stopped: subcommand failed.


I'll keep this open and then maybe create other bugzilla PRs for specific
issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] What's the best way to use "--all-files" option from python?

2017-10-24 Thread Don Hinton via lldb-dev
Will do...

thanks again...

On Mon, Oct 23, 2017 at 6:25 PM, Jim Ingham  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  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  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@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@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] What's the best way to use "--all-files" option from python?

2017-10-24 Thread Zachary Turner via lldb-dev
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@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  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  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@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@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] What's the best way to use "--all-files" option from python?

2017-10-24 Thread Don Hinton via lldb-dev
Do you mean just pass a pattern to the -f option or FileSpec?

On Tue, Oct 24, 2017 at 6:50 PM, Zachary Turner  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@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  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  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@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@lists.llvm.org
>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> >
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] What's the best way to use "--all-files" option from python?

2017-10-24 Thread Zachary Turner via lldb-dev
Pass a pattern to the -f option.

On Tue, Oct 24, 2017 at 7:18 PM Don Hinton  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 
> 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@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  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  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@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@lists.llvm.org
>>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> >
>>> >
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev