Re: [lldb-dev] New build machine in the cluster lldb-amd64-ninja-netbsd8
Indeed, master restart is needed every time you update the zorg repository.
cheers,
pl
On 28 April 2017 at 03:40, Kamil Rytarowski wrote:
> On 24.04.2017 11:42, Pavel Labath wrote:
>>
>>
>> On 22 April 2017 at 23:57, Kamil Rytarowski via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>
>> Hello,
>>
>> I'm in process of attaching new build machine lldb-amd64-ninja-netbsd8.
>>
>> It will run prerelease of NetBSD/amd64 8.0 (as of today 7.99.70) with
>> the GNU toolchain.
>>
>> Once the new one setup will be in operation, I will upgrade the old one
>> to 7.99.70 (& retain the same name), switch the to the staging cluster
>> http://lab.llvm.org:8014/ and turn on execution of tests.
>>
>> Am I right that in order to turn tests I need to switch "runTest=False"
>> to "runTest=True" in buildbot/osuosl/master/config/builders.py?
>>
>>
>> Affirmative.
>>
>> As you are using the "scripted" build factory, you'll also need to
>> create a test_cfg.json in your scripts folder on the build slave, which
>> describes the kind of tests you want to run:
>> For example, the linux build bot has this in the file:
>> {
>> "test1": "local,clang-3.5,i386",
>> "test2": "local,clang-3.5,x86_64",
>> "test3": "local,totclang,i386",
>> "test4": "local,totclang,x86_64",
>> "test5": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,i386",
>> "test6": "local,/lldb-buildbot/bin/gcc-4.9.2/bin/gcc,x86_64"
>> }
>> but a single test line would probably be enough for you.
>> Then, the master will invoke a script "test.sh" with the test config
>> argument: (e.g., ./test.sh local,clang-3.5,i386) and your script should
>> run the tests.
>>
>> let me know if you run into problems,
>> pl
>
> lldb-amd64-ninja-netbsd8 [kernel ABI version 7.99.70] is up and running
>
> lldb-amd64-ninja-netbsd7 has been upgraded to 7.99.70 and restarted
>
> I switched the old machine to the staging buildfarm, set runTest=True in
> buildbot/osuosl/master/config/builders.py and added the following
> test_cfg.json:
>
> $ cat ./build/build/test_cfg.json
> {
> "test1": "local,gcc,x86_64",
> }
>
> As of now it does not attempt to run the regression tests. Perhaps we
> need to restart buildmaster configuration? I will ask Galina for it.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
On 27 April 2017 at 19:12, Jim Ingham wrote: > Interesting. Do you have to catch this information as the JIT modules get > loaded, or can you recover the data after-the-fact? For most uses, I don't > think you need to track JIT modules as they are loaded, but it would be good > enough to refresh the list on stop. > > Jim Well, you need to know that the library got loaded so you can decide whether you want to set a breakpoint there before it gets a chance to execute. It's the same thing as the dynamic linker rendezvous breakpoint, only for jitted code. **I suppose** delay the lookup until the first breakpoint gets set by the user, as that is the first time we will need that information, but I guess we don't have the ability to express that now. FWIW, the jit interface can be disabled by a setting (plugin.jit-loader.gdb.enable-jit-breakpoint). pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
On 27 April 2017 at 00:12, Scott Smith via lldb-dev wrote: > After a dealing with a bunch of microoptimizations, I'm back to > parallelizing loading of shared modules. My naive approach was to just > create a new thread per shared library. I have a feeling some users may not > like that; I think I read an email from someone who has thousands of shared > libraries. That's a lot of threads :-) > > The problem is loading a shared library can cause downstream parallelization > through TaskPool. I can't then also have the loading of a shared library > itself go through TaskPool, as that could cause a deadlock - if all the > worker threads are waiting on work that TaskPool needs to run on a worker > thread then nothing will happen. > > Three possible solutions: > > 1. Remove the notion of a single global TaskPool, but instead have a static > pool at each callsite that wants it. That way multiple paths into the same > code would share the same pool, but different places in the code would have > their own pool. > I looked at this option in the past and this was my preferred solution. My suggestion would be to have two task pools. One for low-level parallelism, which spawns std::thread::hardware_concurrency() threads, and another one for higher level tasks, which can only spawn a smaller number of threads (the algorithm for the exact number TBD). The high-level threads can access to low-level ones, but not the other way around, which guarantees progress. I propose to hardcode 2 pools, as I don't want to make it easy for people to create additional ones -- I think we should be having this discussion every time someone tries to add one, and have a very good justification for it (FWIW, I think your justification is good in this case, and I am grateful that you are pursuing this). pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] I'm going to break the xcode build
Hello all, I'd like to submit D32434 soon, which adds a dependency on yaml2obj, which I use to test elf file parsing code. This will break the xcode build as it does not provide path to the yaml2obj binary to the unit tests. As far as I can tell, fixing the build should be easy and amounts to adding -DYAML2OBJ=/path/to/yaml2obj to the xcode project config for compiling unit tests, and you can even do it ahead of time to avoid breakage. If there are any issues with this, please let me know sooner rather than later. cheers, pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parallelizing loading of shared libraries
Hmmm ok, I don't like hard coding pools. Your idea about limiting the number of high level threads gave me an idea: 1. System has one high level TaskPool. 2. TaskPools have up to one child and one parent (the parent for the high level TaskPool = nullptr). 3. When a worker starts up for a given TaskPool, it ensures a single child exists. 4. There is a thread local variable that indicates which TaskPool that thread enqueues into (via AddTask). If that variable is nullptr, then it is the high level TaskPool.Threads that are not workers enqueue into this TaskPool. If the thread is a worker thread, then the variable points to the worker's child. 5. When creating a thread in a TaskPool, it's thread count AND the thread count of the parent, grandparent, etc are incremented. 6. In the main worker loop, if there is no more work to do, OR the thread count is too high, the worker "promotes" itself. Promotion means: a. decrement the thread count for the current task pool b. if there is no parent, exit; otherwise, become a worker for the parent task pool (and update the thread local TaskPool enqueue pointer). The main points are: 1. We don't hard code the number of task pools; the code automatically uses the fewest number of taskpools needed regardless of the number of places in the code that want task pools. 2. When the child taskpools are busy, parent taskpools reduce their number of workers over time to reduce oversubscription. You can fiddle with the # of allowed threads per level; for example, if you take into account number the height of the pool, and the number of child threads, then you could allocate each level 1/2 of the number of threads as the level below it, unless the level below wasn't using all the threads; then the steady state would be 2 * cores, rather than height * cores. I think that it probably overkill though. On Fri, Apr 28, 2017 at 4:37 AM, Pavel Labath wrote: > On 27 April 2017 at 00:12, Scott Smith via lldb-dev > wrote: > > After a dealing with a bunch of microoptimizations, I'm back to > > parallelizing loading of shared modules. My naive approach was to just > > create a new thread per shared library. I have a feeling some users may > not > > like that; I think I read an email from someone who has thousands of > shared > > libraries. That's a lot of threads :-) > > > > The problem is loading a shared library can cause downstream > parallelization > > through TaskPool. I can't then also have the loading of a shared library > > itself go through TaskPool, as that could cause a deadlock - if all the > > worker threads are waiting on work that TaskPool needs to run on a worker > > thread then nothing will happen. > > > > Three possible solutions: > > > > 1. Remove the notion of a single global TaskPool, but instead have a > static > > pool at each callsite that wants it. That way multiple paths into the > same > > code would share the same pool, but different places in the code would > have > > their own pool. > > > > I looked at this option in the past and this was my preferred > solution. My suggestion would be to have two task pools. One for > low-level parallelism, which spawns > std::thread::hardware_concurrency() threads, and another one for > higher level tasks, which can only spawn a smaller number of threads > (the algorithm for the exact number TBD). The high-level threads can > access to low-level ones, but not the other way around, which > guarantees progress. > > I propose to hardcode 2 pools, as I don't want to make it easy for > people to create additional ones -- I think we should be having this > discussion every time someone tries to add one, and have a very good > justification for it (FWIW, I think your justification is good in this > case, and I am grateful that you are pursuing this). > > pl > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] remote server crash -> lldb waits forever in accept()
Hi Chris, Pavel,
I've got a problem launching the hexagon simulator from lldb. It's launched
the same way that debugserver/lldb-server is launched, with reverse connect
on a TCP socket. The user can modify the simulator command line (using
target.run-args), and can easily give a set of options that the simulator
can't handle. In this case the simulator quits before connecting to lldb,
and lldb will wait forever for the connection, since TCPSocket::Accept has
no timeout.
Currently I have a select call before the accept, to make sure there is
activity on the socket. This doesn't feel right with the new changes using
MainLoop, so I wanted to see what the list thinks. I believe it will happen
any time that debugserver/lldb-server quits or crashes before connecting.
That should be easy to test.
This is what I use, right before the call to accept_loop.Run in
TCPSocket::Accept:
NativeSocket accept_socket = -1;
fd_set readset;
FD_ZERO(&readset);
for (auto socket : m_listen_sockets) {
auto fd = socket.first;
FD_SET(fd, &readset);
if (fd > accept_socket)
accept_socket = fd;
}
struct timeval timeout = {10, 0};
int result = ::select(accept_socket + 1, &readset, NULL, NULL,
&timeout);
if (result == 0) {
printf("error: timeout waiting for remote server to connect!\n");
error.SetErrorString("timeout waiting for remote server to connect");
return error;
} else if (result < 0) {
printf("error: remote server does not exist!\n");
SetLastError(error);
return error;
}
Any thoughts this issue?
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] remote server crash -> lldb waits forever in accept()
Seems to me a better UI would be to make ^C interrupt this wait. That seems to
me better than putting in some arbitrary timeout.
Jim
> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
> wrote:
>
> Hi Chris, Pavel,
>
> I've got a problem launching the hexagon simulator from lldb. It's launched
> the same way that debugserver/lldb-server is launched, with reverse connect
> on a TCP socket. The user can modify the simulator command line (using
> target.run-args), and can easily give a set of options that the simulator
> can't handle. In this case the simulator quits before connecting to lldb,
> and lldb will wait forever for the connection, since TCPSocket::Accept has
> no timeout.
>
> Currently I have a select call before the accept, to make sure there is
> activity on the socket. This doesn't feel right with the new changes using
> MainLoop, so I wanted to see what the list thinks. I believe it will happen
> any time that debugserver/lldb-server quits or crashes before connecting.
> That should be easy to test.
>
> This is what I use, right before the call to accept_loop.Run in
> TCPSocket::Accept:
>
>NativeSocket accept_socket = -1;
>fd_set readset;
>FD_ZERO(&readset);
>for (auto socket : m_listen_sockets) {
> auto fd = socket.first;
> FD_SET(fd, &readset);
> if (fd > accept_socket)
>accept_socket = fd;
>}
>struct timeval timeout = {10, 0};
>int result = ::select(accept_socket + 1, &readset, NULL, NULL,
> &timeout);
>if (result == 0) {
> printf("error: timeout waiting for remote server to connect!\n");
> error.SetErrorString("timeout waiting for remote server to connect");
> return error;
>} else if (result < 0) {
> printf("error: remote server does not exist!\n");
> SetLastError(error);
> return error;
>}
>
>
> Any thoughts this issue?
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> ___
> 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] remote server crash -> lldb waits forever in accept()
Ultimately I think the solution here is two changes
(1) We should add a timeout to MainLoop so that it doesn't wait forever unless
we really want to wait forever.
(2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
kevent, so we should probably set that up too.
-Chris
> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev
> wrote:
>
> Seems to me a better UI would be to make ^C interrupt this wait. That seems
> to me better than putting in some arbitrary timeout.
>
> Jim
>
>> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
>> wrote:
>>
>> Hi Chris, Pavel,
>>
>> I've got a problem launching the hexagon simulator from lldb. It's launched
>> the same way that debugserver/lldb-server is launched, with reverse connect
>> on a TCP socket. The user can modify the simulator command line (using
>> target.run-args), and can easily give a set of options that the simulator
>> can't handle. In this case the simulator quits before connecting to lldb,
>> and lldb will wait forever for the connection, since TCPSocket::Accept has
>> no timeout.
>>
>> Currently I have a select call before the accept, to make sure there is
>> activity on the socket. This doesn't feel right with the new changes using
>> MainLoop, so I wanted to see what the list thinks. I believe it will happen
>> any time that debugserver/lldb-server quits or crashes before connecting.
>> That should be easy to test.
>>
>> This is what I use, right before the call to accept_loop.Run in
>> TCPSocket::Accept:
>>
>> NativeSocket accept_socket = -1;
>> fd_set readset;
>> FD_ZERO(&readset);
>> for (auto socket : m_listen_sockets) {
>> auto fd = socket.first;
>> FD_SET(fd, &readset);
>> if (fd > accept_socket)
>> accept_socket = fd;
>> }
>> struct timeval timeout = {10, 0};
>> int result = ::select(accept_socket + 1, &readset, NULL, NULL,
>> &timeout);
>> if (result == 0) {
>> printf("error: timeout waiting for remote server to connect!\n");
>> error.SetErrorString("timeout waiting for remote server to connect");
>> return error;
>> } else if (result < 0) {
>> printf("error: remote server does not exist!\n");
>> SetLastError(error);
>> return error;
>> }
>>
>>
>> Any thoughts this issue?
>>
>> Ted
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> ___
>> 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
[lldb-dev] Unable to build LLDB 4.0 on Debian Linux
Hi,
I am having a problem building the 4.0 release branch of LLDB on Debian
Stretch. Cmake returns the following fault:
-- LLDB version: 4.0.0
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.4")
-- Performing Test HAVE_PROCESS_VM_READV
-- Performing Test HAVE_PROCESS_VM_READV - Success
-- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
-- Looking for __GLIBCXX__
-- Looking for __GLIBCXX__ - found
-- Performing Test LLDB_USING_LIBSTDCXX_4_9
-- Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success
-- Looking for backtrace
-- Looking for backtrace - not found
-- Could NOT find Backtrace (missing: Backtrace_LIBRARY)
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.13")
-- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10")
-- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED
-- Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success
-- Symbols (liblldb): exporting all symbols from the lldb namespace
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
Backtrace_LIBRARY (ADVANCED)
linked by target "liblldb" in directory clang-4.0/tools/lldb/source/API
linked by target "LLDBBreakpointTests" in directory
clang-4.0/tools/lldb/unittests/Breakpoint
linked by target "LLDBCoreTests" in directory
clang-4.0/tools/lldb/unittests/Core
linked by target "EditlineTests" in directory
clang-4.0/tools/lldb/unittests/Editline
linked by target "ExpressionTests" in directory
clang-4.0/tools/lldb/unittests/Expression
linked by target "HostTests" in directory
clang-4.0/tools/lldb/unittests/Host
linked by target "InterpreterTests" in directory
clang-4.0/tools/lldb/unittests/Interpreter
linked by target "LanguageCPlusPlusTests" in directory
clang-4.0/tools/lldb/unittests/Language/CPlusPlus
linked by target "LLDBPlatformTests" in directory
clang-4.0/tools/lldb/unittests/Platform
linked by target "ProcessGdbRemoteTests" in directory
clang-4.0/tools/lldb/unittests/Process/gdb-remote
linked by target "LLDBMinidumpTests" in directory
clang-4.0/tools/lldb/unittests/Process/minidump
linked by target "ScriptInterpreterPythonTests" in directory
clang-4.0/tools/lldb/unittests/ScriptInterpreter/Python
linked by target "SymbolTests" in directory
clang-4.0/tools/lldb/unittests/Symbol
linked by target "SymbolFileDWARFTests" in directory
clang-4.0/tools/lldb/unittests/SymbolFile/DWARF
linked by target "UnwindAssemblyx86Tests" in directory
clang-4.0/tools/lldb/unittests/UnwindAssembly/x86
linked by target "UtilityTests" in directory
clang-4.0/tools/lldb/unittests/Utility
-- Configuring incomplete, errors occurred!
See also "build-4.0/bootstrap/CMakeFiles/CMakeOutput.log".
See also "build-4.0/bootstrap/CMakeFiles/CMakeError.log".
The output from CMakeError.log is:
Determining if the backtrace exist failed with the following output:
Change Dir: build-4.0/bootstrap/CMakeFiles/CMakeTmp
Run Build Command:"build-4.0/bin/ninja" "cmTC_1e735"
[1/2] Building C object CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
FAILED: CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
/usr/bin/cc-fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment -Werror
-Werror=date-time -ffunction-sections -fdata-sections -o
CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o -c
build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c
build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function
‘main’:
build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:11: error: ISO
C forbids conversion of function pointer to object pointer type
[-Werror=pedantic]
return ((int*)(&backtrace))[argc];
^
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.
File build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include
int main(int argc, char** argv)
{
(void)argv;
#ifndef backtrace
return ((int*)(&backtrace))[argc];
#else
(void)argc;
return 0;
#endif
}
It seems that the detection routine is invalid. The gcc in use is 6.3.0.
Anyone any idea how to fix / work around this problem?
Many thanks,
Andy
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] remote server crash -> lldb waits forever in accept()
(1) is okay, except pretty much every time so far I've ever said "operation X
can't possibly take more than N seconds" somebody finds a case in which that
assumption was wrong. So you end up having to make the timeouts so long they
look like stalls anyway... An explicit cancellation gesture is better if
supportable.
Jim
> On Apr 28, 2017, at 2:20 PM, Chris Bieneman wrote:
>
> Ultimately I think the solution here is two changes
>
> (1) We should add a timeout to MainLoop so that it doesn't wait forever
> unless we really want to wait forever.
> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
> kevent, so we should probably set that up too.
>
> -Chris
>
>
>> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev
>> wrote:
>>
>> Seems to me a better UI would be to make ^C interrupt this wait. That seems
>> to me better than putting in some arbitrary timeout.
>>
>> Jim
>>
>>> On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
>>> wrote:
>>>
>>> Hi Chris, Pavel,
>>>
>>> I've got a problem launching the hexagon simulator from lldb. It's launched
>>> the same way that debugserver/lldb-server is launched, with reverse connect
>>> on a TCP socket. The user can modify the simulator command line (using
>>> target.run-args), and can easily give a set of options that the simulator
>>> can't handle. In this case the simulator quits before connecting to lldb,
>>> and lldb will wait forever for the connection, since TCPSocket::Accept has
>>> no timeout.
>>>
>>> Currently I have a select call before the accept, to make sure there is
>>> activity on the socket. This doesn't feel right with the new changes using
>>> MainLoop, so I wanted to see what the list thinks. I believe it will happen
>>> any time that debugserver/lldb-server quits or crashes before connecting.
>>> That should be easy to test.
>>>
>>> This is what I use, right before the call to accept_loop.Run in
>>> TCPSocket::Accept:
>>>
>>> NativeSocket accept_socket = -1;
>>> fd_set readset;
>>> FD_ZERO(&readset);
>>> for (auto socket : m_listen_sockets) {
>>>auto fd = socket.first;
>>>FD_SET(fd, &readset);
>>>if (fd > accept_socket)
>>> accept_socket = fd;
>>> }
>>> struct timeval timeout = {10, 0};
>>> int result = ::select(accept_socket + 1, &readset, NULL, NULL,
>>> &timeout);
>>> if (result == 0) {
>>>printf("error: timeout waiting for remote server to connect!\n");
>>>error.SetErrorString("timeout waiting for remote server to connect");
>>>return error;
>>> } else if (result < 0) {
>>>printf("error: remote server does not exist!\n");
>>>SetLastError(error);
>>>return error;
>>> }
>>>
>>>
>>> Any thoughts this issue?
>>>
>>> Ted
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>>> Linux Foundation Collaborative Project
>>>
>>>
>>>
>>> ___
>>> 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] remote server crash -> lldb waits forever in accept()
I think in the common case of listening for a remote connection infinite (or
very very long) timeout with signal interrupt is the preferred approach. There
are other situations where we use SelectHelper with smaller timeouts, and I
think ultimately we should replace SelectHelper with MainLoop because they do
basically the same thing.
-Chris
> On Apr 28, 2017, at 2:53 PM, Jim Ingham wrote:
>
> (1) is okay, except pretty much every time so far I've ever said "operation X
> can't possibly take more than N seconds" somebody finds a case in which that
> assumption was wrong. So you end up having to make the timeouts so long they
> look like stalls anyway... An explicit cancellation gesture is better if
> supportable.
>
> Jim
>
>> On Apr 28, 2017, at 2:20 PM, Chris Bieneman wrote:
>>
>> Ultimately I think the solution here is two changes
>>
>> (1) We should add a timeout to MainLoop so that it doesn't wait forever
>> unless we really want to wait forever.
>> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect, or
>> kevent, so we should probably set that up too.
>>
>> -Chris
>>
>>
>>> On Apr 28, 2017, at 11:06 AM, Jim Ingham via lldb-dev
>>> wrote:
>>>
>>> Seems to me a better UI would be to make ^C interrupt this wait. That
>>> seems to me better than putting in some arbitrary timeout.
>>>
>>> Jim
>>>
On Apr 28, 2017, at 10:21 AM, Ted Woodward via lldb-dev
wrote:
Hi Chris, Pavel,
I've got a problem launching the hexagon simulator from lldb. It's launched
the same way that debugserver/lldb-server is launched, with reverse connect
on a TCP socket. The user can modify the simulator command line (using
target.run-args), and can easily give a set of options that the simulator
can't handle. In this case the simulator quits before connecting to lldb,
and lldb will wait forever for the connection, since TCPSocket::Accept has
no timeout.
Currently I have a select call before the accept, to make sure there is
activity on the socket. This doesn't feel right with the new changes using
MainLoop, so I wanted to see what the list thinks. I believe it will happen
any time that debugserver/lldb-server quits or crashes before connecting.
That should be easy to test.
This is what I use, right before the call to accept_loop.Run in
TCPSocket::Accept:
NativeSocket accept_socket = -1;
fd_set readset;
FD_ZERO(&readset);
for (auto socket : m_listen_sockets) {
auto fd = socket.first;
FD_SET(fd, &readset);
if (fd > accept_socket)
accept_socket = fd;
}
struct timeval timeout = {10, 0};
int result = ::select(accept_socket + 1, &readset, NULL, NULL,
&timeout);
if (result == 0) {
printf("error: timeout waiting for remote server to connect!\n");
error.SetErrorString("timeout waiting for remote server to connect");
return error;
} else if (result < 0) {
printf("error: remote server does not exist!\n");
SetLastError(error);
return error;
}
Any thoughts this issue?
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
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] remote server crash -> lldb waits forever in accept()
MainLoop was meant to be a general event multiplexer. One of those
events can certainly be "a certain amount of time expiring".
So, you could write something like:
loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() });
which would translate to an appropriate timeout argument to ppoll.
>>> (2) MainLoop can exit on sigint for any platform that has ppoll, pselect,
>>> or kevent, so we should probably set that up too.
Listening for signals is very complicated in multithreaded programs. I
am not sure about the situation with kevent, but I am sure the ppoll
based version will not work reliably for this.
Then there is also the problem of installing a signal handler in a
shared library (liblldb), which can conflict with whatever is the host
program doing.
I would love to have this functionality, as I think it's badly needed
in a lot of places, but I think it needs to be done the long way round
and have a sort of an Interrupt function on the SBAPI level (maybe the
existing SBDebugger.DispatchInputInterrupt would be enough, although I
am not convinced of the signal-safety of that function), which would
then trigger an exit from the main loop where necessary. lldb and
other host programs could then install their own sigint handlers (lldb
already does btw), and call this function when appropriate.
Let me throw another option out there:
if lldb-server fails to start because of a borked command line you
should be able to detect this (waitpid). So then again you are in the
business of multiplexing two events (accept() and waitpid()) and you
don't need timeouts. (It will be tricky to multiplex waitpid properly
without installing a SIGCHLD handler though).
On 28 April 2017 at 23:17, Chris Bieneman via lldb-dev
wrote:
> I think in the common case of listening for a remote connection infinite (or
> very very long) timeout with signal interrupt is the preferred approach.
> There are other situations where we use SelectHelper with smaller timeouts,
> and I think ultimately we should replace SelectHelper with MainLoop because
> they do basically the same thing.
+100
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] remote server crash -> lldb waits forever in accept()
> On Apr 28, 2017, at 4:04 PM, Pavel Labath wrote:
>
> MainLoop was meant to be a general event multiplexer. One of those
> events can certainly be "a certain amount of time expiring".
> So, you could write something like:
> loop.RegisterAlarm(seconds(N), [&] { loop.RequestTermination() });
> which would translate to an appropriate timeout argument to ppoll.
>
>
(2) MainLoop can exit on sigint for any platform that has ppoll, pselect,
or kevent, so we should probably set that up too.
> Listening for signals is very complicated in multithreaded programs. I
> am not sure about the situation with kevent, but I am sure the ppoll
> based version will not work reliably for this.
> Then there is also the problem of installing a signal handler in a
> shared library (liblldb), which can conflict with whatever is the host
> program doing.
>
> I would love to have this functionality, as I think it's badly needed
> in a lot of places, but I think it needs to be done the long way round
> and have a sort of an Interrupt function on the SBAPI level (maybe the
> existing SBDebugger.DispatchInputInterrupt would be enough, although I
> am not convinced of the signal-safety of that function), which would
> then trigger an exit from the main loop where necessary. lldb and
> other host programs could then install their own sigint handlers (lldb
> already does btw), and call this function when appropriate.
>
Yes, this is certainly the right way to do it. That's how the lldb driver does
things. If we run into troubles with this doing more work than it should in
the signal handler, we can make something cleverer. But the set of things that
are in theory signal safe is a small subset of the set of things that are in
practice are signal safe. When I last worked on gdbtk (that was way back in
the day), it used to do all the updates of the GUI in a SIGALRM handler. That
should never have worked in theory yet in practice it worked just fine.
>
> Let me throw another option out there:
> if lldb-server fails to start because of a borked command line you
> should be able to detect this (waitpid). So then again you are in the
> business of multiplexing two events (accept() and waitpid()) and you
> don't need timeouts. (It will be tricky to multiplex waitpid properly
> without installing a SIGCHLD handler though).
>
You can do this with kqueues on systems that support them.
Jim
>
> On 28 April 2017 at 23:17, Chris Bieneman via lldb-dev
> wrote:
>> I think in the common case of listening for a remote connection infinite (or
>> very very long) timeout with signal interrupt is the preferred approach.
>> There are other situations where we use SelectHelper with smaller timeouts,
>> and I think ultimately we should replace SelectHelper with MainLoop because
>> they do basically the same thing.
>
> +100
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Renaming lldb_private::Error
I have a patch locally that renames lldb_private::Error to lldb_private::LLDBError. As you might expect, this is a pretty large patch so I don't plan to put it up for review, but since it's kind of a fundamental class I figured I should at least start a discussion. The primary motivation for this is to enable cleaner interop between lldb's Error class and llvm::Error. Currently there is an ambiguity between the two. Obviously they are scoped in different namespaces, but it's still confusing when looking at code to see such similarly named classes. There are a number of advantages to llvm::Error over lldb Error which I'm happy to elaborate on if anyone needs some clarification (I've also cc'ed lang on here, who wrote the original llvm Error implementation). Long term I would eventually like to deprecate lldb's Error class entirely, and switch entirely to llvm::Error. An intermediate transition phase would likely involve making something like LLDBWrapError which interoperates with llvm::Error and wraps an lldb_private::LLDBError. For now though, I'm only proposing a very simple rename with minimal invasiveness. Comments? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
