- User Since
- Jun 7 2018, 12:06 PM (176 w, 6 d)
Mar 2 2020
Feb 17 2020
@cmatthews can you please land the patch yourself? It seems that I don't have permission. Also, how can I get that permission (does it differ from llvm commit access)?
Feb 14 2020
Abandoned since for now, it will require a lot of changes to the codebase.
Abandoned since the patch is outdated too much.
Apr 27 2019
Apr 22 2019
Oct 29 2018
Oct 28 2018
Here it is:
build/bin/llvm-lit -avv llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test -- Testing: 1 tests, 1 threads -- FAIL: lldb :: tools/lldb-mi/breakpoint/break-insert-enable-pending.test (1 of 1) ******************** TEST 'lldb :: tools/lldb-mi/breakpoint/break-insert-enable-pending.test' FAILED ******************** Script: -- : 'RUN: at line 4'; /home/alexander/workspace/gsoc/build/./bin/clang -o /home/alexander/workspace/gsoc/build/tools/lldb/lit/tools/lldb-mi/breakpoint/Output/break-insert-enable-pending.test.tmp /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/inputs/break-insert-pending.c -g : 'RUN: at line 5'; /home/alexander/workspace/gsoc/build/bin/lldb-mi --synchronous /home/alexander/workspace/gsoc/build/tools/lldb/lit/tools/lldb-mi/breakpoint/Output/break-insert-enable-pending.test.tmp < /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test | /home/alexander/workspace/gsoc/build/bin/FileCheck /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test --dump-input-on-failure -- Exit Code: 1
I ran the test and got a fail:
build/bin/llvm-lit -avv llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test -- Testing: 1 tests, 1 threads -- FAIL: lldb :: tools/lldb-mi/breakpoint/break-insert-enable-pending.test (1 of 1) ******************** TEST 'lldb :: tools/lldb-mi/breakpoint/break-insert-enable-pending.test' FAILED ******************** Script: -- : 'RUN: at line 4'; /home/alexander/workspace/gsoc/build/./bin/clang -o b.exe /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/inputs/break-insert-pending.c -g : 'RUN: at line 5'; /home/alexander/workspace/gsoc/build/bin/lldb-mi --synchronous < /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test | /home/alexander/workspace/gsoc/build/bin/FileCheck /home/alexander/workspace/gsoc/llvm/tools/lldb/lit/tools/lldb-mi/breakpoint/break-insert-enable-pending.test -- Exit Code: 1
Oct 27 2018
Oct 23 2018
I think that it's worth it to rewrite the test with LIT and FileCheck because the python approach has some limitations, e.g. timeouts. You can find examples in lldb/lit/tools/lldb-mi/.
Sep 25 2018
Changed the test to use %python variable instead of python
Changed python version required to use 'pass_fds' argument to 3.2.
I tested this patch with python 2.7 and 3.5.
Removed the shebang line since we call the script via python ... so that line doesn't matter.
Thanks Pavel, I fixed it here https://reviews.llvm.org/D52498.
Sep 24 2018
Reduced timer from 120 to 30 seconds.
If so, we can try to run the script with python2.x. @teemperor can you try to modify target-select-so-path.test this way:
change # RUN: python %p/inputs/target-select-so-path.py "%debugserver" "%lldbmi %t" %s to
# RUN: python2 %p/inputs/target-select-so-path.py "%debugserver" "%lldbmi %t" %s
Sep 22 2018
AFAIR, adding an exit(...) to ConnectToRemote won't solve this problem. The test will still be failing on Arch.
Sep 21 2018
Do you mean ConnectToRemote method from lldb/tools/lldb-server/lldb-gdbserver.cpp?
Sep 20 2018
Thanks to @tatyana-krasnukha for the idea about a timer. Added a timer to target-select-so-path test.
Can you provide some logs? For example, you might be able to run this test (llvm-lit -a -vv .../target-select-so-path.test) and kill lldb-mi and filecheck processes if they hang. Also, information about which processes hang would be useful too (lldb-mi or filecheck or maybe both).
I found out that the reason of hanging of the test suite was in incorrect usage of Filecheck and lldb-mi processes in target-select-so-path.test. Current patch has been tested on CentOS 7.
Sep 17 2018
It seems reasonable, I'll look at this.
Sep 15 2018
Sep 14 2018
I've created this revision to be sure that you don't think that this approach is some kind of hack.
Sep 7 2018
Sep 3 2018
Aug 9 2018
I think those options don't fit. I'm looking for behavior like this:
~/workspace/gsoc/build/bin/lldb-server gdbserver --pipe 1 localhost:0 36251
Here lldb-server prints out the port number it is listening on and continues running.
It seems that target-select-so-path.test hangs on macOS. Thanks to @t.p.northover for noting this.
Aug 7 2018
Sure, will do it.
Splitted the patch into two parts: this part with the new API and another one with re-implementing of target-select command.
The second part will be committed separately.
Aug 1 2018
@clayborg can you explain what are you worry about because I don't completely understand you? As I said, all lldb-mi commands print their result to STDOUT, AFAIK, an IDE should parse it and then show in a GUI.
Jul 31 2018
Changed the order of if statements to follow llvm coding standards.
Made error handling more meaningful: added different error messages for cases - empty <from> path and empty <to> path.
Added converting from const char * to ConstString, documented new API.
So, do you have any thoughts about this approach letting the debugserver choose a tcp port and patch overall?
Jul 30 2018
Jul 26 2018
It seems that it's impossible to get HandleProcessEventStateSuspended called on Linux, so I've copied code of this patch into
HandleProcessEventStateStopped to check new output.
Now tcp port is choosing by debugserver.
Jul 25 2018
Moved test from bash to python, removed unnecessary Target::AppendImageSearchPath.
Thanks, I used this lldb-server gdbserver --pipe 0 localhost:0 and got a port chosen by debugserver. But to let lldb-mi know about this port we need an additional script, is python a good choice for that?
packages/Python/lldbsuite/test/tools/lldb-mi/signal/TestMiSignal.py test contains port = 12000 + random.randint(0, 3999).
What do you think about running tests with a hardcoded port number(as it's done in a web-services). Doing this, we get rid of additional scripts and os-specific things. AFAIK, debugserver even has its own default port.
Jul 24 2018
Jul 23 2018
You mean that it's unreasonable to provide such an output to stdout since MI clients are text redactors, IDE and not people?
Another approach is to implement SBTargetSettings' functionality such as serialization inside lldb_private TargetProperties class and then just add an API to the SBTarget. For example:
Jul 21 2018
Jul 19 2018
Converted data-info-line python test to a lit one.
Jul 13 2018
@stella.stamenova Done in r337064.