[Lldb-commits] [PATCH] D37930: Use ThreadLauncher to launch TaskPool threads

tberghammer accepted this revision. tberghammer added a comment. Looks good Comment at: source/Utility/TaskPool.cpp:61 +lldb_private::ThreadLauncher::LaunchThread("task-pool.worker", WorkerPtr, + this, nullptr, 8 * 1024 * 1024)

[Lldb-commits] [lldb] r313525 - Fix Linux remote debugging after r313442

Author: tberghammer Date: Mon Sep 18 03:24:48 2017 New Revision: 313525 URL: http://llvm.org/viewvc/llvm-project?rev=313525=rev Log: Fix Linux remote debugging after r313442 On Linux lldb-server sends an OK response to qfThreadInfo if no process is started yet. I don't know why would LLDB issue

Re: [Lldb-commits] [lldb] r313442 - Fix compatibility with OpenOCD debug stub.

Hi Vadim, This change broke remote debugging on Linux and Android as for some reason LLDB sends a qfThreadInfo on those platforms before starting a process (not sure why, will investigate when I have a bit more time) and lldb-server sends an OK response to it. After your change it will generate a

Re: [Lldb-commits] [lldb] r313437 - Check availability of accept4 in C++ instad of C code.

What difference does this make? On Fri, Sep 15, 2017 at 8:00 PM Eugene Zemtsov via lldb-commits < lldb-commits@lists.llvm.org> wrote: > Author: eugene > Date: Fri Sep 15 19:58:49 2017 > New Revision: 313437 > > URL: http://llvm.org/viewvc/llvm-project?rev=313437=rev > Log: > Check availability

[Lldb-commits] [lldb] r313539 - Revert "Use ThreadLauncher to launch TaskPool threads"

Author: fjricci Date: Mon Sep 18 08:43:59 2017 New Revision: 313539 URL: http://llvm.org/viewvc/llvm-project?rev=313539=rev Log: Revert "Use ThreadLauncher to launch TaskPool threads" This reverts commit r313537 because it fails to link on linux buildbots Modified:

[Lldb-commits] [PATCH] D37934: Fix compatibility with OpenOCD debug stub.

clayborg added a comment. If we get a response of "l" for the "qfThreadInfo", it might be worth trying to send a "https://reviews.llvm.org/H1; packet (select thread ID 1 for subsequent continues and steps) to see if the server knows about thread 1 before proceeding? This patch also broke other

[Lldb-commits] [PATCH] D33213: Use socketpair on all Unix platforms

clayborg accepted this revision. clayborg added a comment. This should be good to go. Watch the buildbots for failures. https://reviews.llvm.org/D33213 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D37930: Use ThreadLauncher to launch TaskPool threads

This revision was automatically updated to reflect the committed changes. Closed by commit rL313537: Use ThreadLauncher to launch TaskPool threads (authored by fjricci). Changed prior to commit: https://reviews.llvm.org/D37930?vs=115484=115658#toc Repository: rL LLVM

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

clayborg added a comment. The default return value of WillResume should be no error. Sorry for not catching this. The core file Process subclasses will need to override this manually. Repository: rL LLVM https://reviews.llvm.org/D37651 ___

[Lldb-commits] [lldb] r313537 - Use ThreadLauncher to launch TaskPool threads

Author: fjricci Date: Mon Sep 18 08:18:48 2017 New Revision: 313537 URL: http://llvm.org/viewvc/llvm-project?rev=313537=rev Log: Use ThreadLauncher to launch TaskPool threads Summary: This allows for the stack size to be configured, which isn't possible with std::thread. Prevents overflowing the

[Lldb-commits] [PATCH] D37930: Use ThreadLauncher to launch TaskPool threads

fjricci reopened this revision. fjricci added a comment. This revision is now accepted and ready to land. Is ThreadLauncher unavailable in this code for some reason? The link failed on linux buildbots (building lldb on Darwin was fine locally):

[Lldb-commits] [lldb] r313540 - Revert "Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)"

Author: amccarth Date: Mon Sep 18 08:59:44 2017 New Revision: 313540 URL: http://llvm.org/viewvc/llvm-project?rev=313540=rev Log: Revert "Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)" Broke Windows and FreeBSD (at least). This reverts commit

Re: [Lldb-commits] [lldb] r313442 - Fix compatibility with OpenOCD debug stub.

That is the reason I asked for the patch to verify "l" was the only thing received before it goes and makes up a fake thread ID... > On Sep 18, 2017, at 4:44 AM, Tamas Berghammer via lldb-commits > wrote: > > Hi Vadim, > > This change broke remote debugging on

Re: [Lldb-commits] [lldb] r313437 - Check availability of accept4 in C++ instad of C code.

In GNU C Library, accept4 is guarded by __USE_GNU macro. Whether this macro is defined or not can depend on the compiler and its arguments for C and C++. LLDB uses accept4 in C++ code thus it makes sense to test availability of this function in C++ mode. On Mon, Sep 18, 2017 at 9:58 AM, Stephane

[Lldb-commits] [PATCH] D37934: Fix compatibility with OpenOCD debug stub.

tatyana-krasnukha added a comment. This obvious solution works well for me and seems safe. auto isEmptyList = response.IsNormalResponse() && response.GetStringRef() == "l"; if ((response.IsUnsupportedResponse() || isEmptyList) ... Repository: rL LLVM https://reviews.llvm.org/D37934

[Lldb-commits] [PATCH] D33213: Use socketpair on all Unix platforms

jingham added a comment. Pavel & Eugene haven't marked it accepted yet, but from the comments is looks like they are both okay with the change. So it looks to me like everything is done but checking the code in. If you have checkin privileges, then just check it in and as Greg says keep an

[Lldb-commits] [PATCH] D33213: Use socketpair on all Unix platforms

eugene accepted this revision. eugene added a comment. I did mark it Accepted. https://reviews.llvm.org/D33213 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D37930: Use ThreadLauncher to launch TaskPool threads

fjricci updated this revision to Diff 115691. fjricci added a comment. Herald added subscribers: JDevlieghere, mgorny. Move TaskPool from Utility to Host https://reviews.llvm.org/D37930 Files: include/lldb/Host/TaskPool.h include/lldb/Utility/TaskPool.h lldb.xcodeproj/project.pbxproj

[Lldb-commits] [PATCH] D37934: Fix compatibility with OpenOCD debug stub.

clayborg added a comment. I like the solution detailed above by tatyana-krasnukha Repository: rL LLVM https://reviews.llvm.org/D37934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D37934: Fix compatibility with OpenOCD debug stub.

vadimcn added a comment. Sorry, for not catching this regression! I've checked that attaching to a standard gdbserver still worked, but was not aware of the other scenarios. Does lldb-server return 'OK' string in response to 'qfThreadInfo'? According to this

Re: [Lldb-commits] [lldb] r313442 - Fix compatibility with OpenOCD debug stub.

Yes, this works for OpenOCD as well. Thanks! On Mon, Sep 18, 2017 at 4:44 AM, Tamas Berghammer wrote: > Hi Vadim, > > This change broke remote debugging on Linux and Android as for some reason > LLDB sends a qfThreadInfo on those platforms before starting a process (not

[Lldb-commits] [PATCH] D37934: Fix compatibility with OpenOCD debug stub.

vadimcn added a comment. Maybe LLDB should use `qAttached` to determine if there's an active process? OpenOCD seems to implement that one correctly. Repository: rL LLVM

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

lemo added inline comments. Comment at: source/Interpreter/CommandInterpreter.cpp:2708-2710 +const char *data = str.data(); +size_t size = str.size(); +while (size > 0 && !WasInterrupted()) { lemo wrote: > lemo wrote: > > clayborg wrote: > > > Since

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

zturner added inline comments. Comment at: source/Interpreter/CommandInterpreter.cpp:2708-2710 +const char *data = str.data(); +size_t size = str.size(); +while (size > 0 && !WasInterrupted()) { lemo wrote: > lemo wrote: > > lemo wrote: > > >

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

It's a good question - here's a two part answer: 1. The actual printing of the output is the longest blocking in many cases (as mentioned in the description: the actual data gathering for "target module dump symtab" can take 1-2sec, but printing it can take 20min. For quick experiment, try dis -p

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

jingham added a comment. In the original discussion of this feature (it was on the mailing list), it sounded like the specific cast that motivated Leonard in adding this feature was when there's a command that's in the process of generating tons of output, and you want to interrupt the tons

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

jingham added a comment. And in general, interruption should be as responsive as you can make it. When I tell lldb to "Stop right now" it really should do as close as possible to "stop right now". Not, :-"excuse me I have 10 more pages of output to dump". It's not uncommon to dump some

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

lemo updated this revision to Diff 115732. lemo added a comment. Fixed the FreeBSD/Windows break : the intention was to keep Process::WillResume() and Process::DoResume() "in-sync", but this had the unfortunate consequence of breaking Process sub-classes which don't override WillResume(). The

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

lemo added inline comments. Comment at: source/Interpreter/CommandInterpreter.cpp:2708-2710 +const char *data = str.data(); +size_t size = str.size(); +while (size > 0 && !WasInterrupted()) { lemo wrote: > clayborg wrote: > > Since we are using

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

On Mon, Sep 18, 2017 at 3:13 PM Leonard Mosescu wrote: > It's a good question - here's a two part answer: > > 1. The actual printing of the output is the longest blocking in many cases > (as mentioned in the description: the actual data gathering for "target > module dump

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

clayborg added a comment. ok. Then back to the "can we use StringRef"? We might be able to check if the second.data() is NULL? It might be NULL if the string doesn't end with a newline. It it does, it might be empty but contain a pointer to the '\0' byte? https://reviews.llvm.org/D37923

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

Looking at line_iterator, it seems to be designed to work with MemoryBuffer, which in turn seems specialized for dealing with file content (so while it may be possible to force init a MemoryBuffer from a StringRef it seems a bit awkward to me). Also, line_iterator has extra stuff which we don't

[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

clayborg added a comment. Looks fine. https://reviews.llvm.org/D37651 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

Hi Greg, are you referring to the manual line splitting vs. using StringRef::split()? This is how it's documented: /// Split into two substrings around the first occurrence of a separator /// character. /// /// If \p Separator is in the string, then the result is a pair (LHS, RHS) /// such that