Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
c1dff715 |
| 28-Nov-2024 |
Pavel Labath <pavel@labath.sk> |
[lldb] Remove child_process_inherit from the socket classes (#117699)
It's never set to true. Also, using inheritable FDs in a multithreaded
process pretty much guarantees descriptor leaks. It's be
[lldb] Remove child_process_inherit from the socket classes (#117699)
It's never set to true. Also, using inheritable FDs in a multithreaded
process pretty much guarantees descriptor leaks. It's better to
explicitly pass a specific FD to a specific subprocess, which we already
mostly can do using the ProcessLaunchInfo FileActions.
show more ...
|
Revision tags: llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
98b419ca |
| 17-Oct-2024 |
Pavel Labath <pavel@labath.sk> |
[lldb] Don't exit the main loop when in runs out of things to listen on (#112565)
This behavior made sense in the beginning as the class was completely
single threaded, so if the source count ever
[lldb] Don't exit the main loop when in runs out of things to listen on (#112565)
This behavior made sense in the beginning as the class was completely
single threaded, so if the source count ever reached zero, there was no
way to add new ones. In https://reviews.llvm.org/D131160, the class
gained the ability to add events (callbacks) from other threads, which
means that is no longer the case (and indeed, one possible use case for
this class -- acting as a sort of arbiter for multiple threads wanting
to run code while making sure it runs serially -- has this class sit in
an empty Run call most of the time). I'm not aware of us having a use
for such a thing right now, but one of my tests in another patch turned
into something similar by accident.
Another problem with the current approach is that, in a
distributed/dynamic setup (multiple things using the main loop without a
clear coordinator), one can never be sure whether unregistering a
specific event will terminate the loop (it depends on whether there are
other listeners). We had this problem in lldb-platform.cpp, where we had
to add an additional layer of synchronization to avoid premature
termination. We can remove this if we can rely on the loop terminating
only when we tell it to.
show more ...
|
Revision tags: llvmorg-19.1.2 |
|
#
000e790b |
| 03-Oct-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[lldb] Fixed IPv6 host formatting in #104238 (#111033)
This patch fixes the following problems
https://lab.llvm.org/buildbot/#/builders/162/builds/7720
|
#
2e893124 |
| 03-Oct-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[lldb] Removed gdbserver ports map from lldb-server (#104238)
Listen to gdbserver-port, accept the connection and run `lldb-server gdbserver --fd` on all platforms.
Parameters --min-gdbserver-port
[lldb] Removed gdbserver ports map from lldb-server (#104238)
Listen to gdbserver-port, accept the connection and run `lldb-server gdbserver --fd` on all platforms.
Parameters --min-gdbserver-port and --max-gdbserver-port are deprecated now.
This is the part 2 of #101283.
Fixes #97537.
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
0642cd76 |
| 27-Aug-2024 |
Adrian Prantl <aprantl@apple.com> |
[lldb] Turn lldb_private::Status into a value type. (#106163)
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
ant
[lldb] Turn lldb_private::Status into a value type. (#106163)
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.
This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()
Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form
` ResultTy DoFoo(Status& error)
`
to
` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?
The interesting changes are in Status.h and Status.cpp, all other
changes are mostly
` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.
show more ...
|
#
06ccd32b |
| 26-Aug-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[lldb][NFC] Moved the SharedSocket class to Socket.* (#104787)
This is the prerequisite for #104238.
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
82ee31f7 |
| 12-Aug-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[lldb] Updated lldb-server to spawn the child process and share socket (#101283)
`lldb-server platform --server` works on Windows now w/o multithreading.
The rest functionality remains unchanged.
[lldb] Updated lldb-server to spawn the child process and share socket (#101283)
`lldb-server platform --server` works on Windows now w/o multithreading.
The rest functionality remains unchanged.
Fixes #90923, fixes #56346.
This is the part 1 of the replacement of #100670.
In the part 2 I plan to switch `lldb-server gdbserver` to use `--fd` and
listen a common gdb port for all gdbserver connections. Then we can
remove gdb port mapping to fiх #97537.
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
d097f430 |
| 18-Jul-2024 |
Dmitry Vasilyev <dvassiliev@accesssoftek.com> |
[lldb] Fixed the error `unable to launch a GDB server` in API tests (#98833)
TestPlatformLaunchGDBServer.py runs `ldb-server` w/o parameters
`--min-gdbserver-port`, `--max-gdbserver-port` or `--gdb
[lldb] Fixed the error `unable to launch a GDB server` in API tests (#98833)
TestPlatformLaunchGDBServer.py runs `ldb-server` w/o parameters
`--min-gdbserver-port`, `--max-gdbserver-port` or `--gdbserver-port`. So
`gdbserver_portmap` is empty and
`gdbserver_portmap.GetNextAvailablePort()` will return 0. Do not call
`portmap_for_child.AllowPort(0)` in this case. Otherwise
`portmap_for_child.GetNextAvailablePort()` will allocate and never free
the port 0 and next call `portmap_for_child.GetNextAvailablePort()` will
fail.
Added few asserts in `GDBRemoteCommunicationServerPlatform::PortMap` to
avoid such issue in the future.
This patch fixes a bug added in #88845. The behaviour is very close to
#97537 w/o parameters `--min-gdbserver-port`, `--max-gdbserver-port` and
`--gdbserver-port`.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
#
6aed0ab6 |
| 07-May-2024 |
Anthony Ha <anthonyha96@gmail.com> |
[lldb] Have lldb-server assign ports to children in platform mode (#88845)
Fixes #47549
`lldb-server`'s platform mode seems to have an issue with its
`--min-gdbserver-port` `--max-gdbserver-port
[lldb] Have lldb-server assign ports to children in platform mode (#88845)
Fixes #47549
`lldb-server`'s platform mode seems to have an issue with its
`--min-gdbserver-port` `--max-gdbserver-port` flags (and probably the
`--gdbserver-port` flag, but I didn't test it).
How the platform code seems to work is that it listens on a port, and
whenever there's an incoming connection, it forks the process to handle
the connection. To handle the port flags, the main process uses an
instance of the helper class
`GDBRemoteCommunicationServerPlatform::PortMap`, that can be configured
and track usages of ports. The child process handling the platform
connection, can then use the port map to allocate a port for the
gdb-server connection it will make (this is another process it spawns).
However, in the current code, this works only once. After the first
connection is handled by forking a child process, the main platform
listener code loops around, and then 'forgets' about the port map. This
is because this code:
```cpp
GDBRemoteCommunicationServerPlatform platform(
acceptor_up->GetSocketProtocol(), acceptor_up->GetSocketScheme());
if (!gdbserver_portmap.empty()) {
platform.SetPortMap(std::move(gdbserver_portmap));
}
```
is within the connection listening loop. This results in the
`gdbserver_portmap` being moved into the platform object at the
beginning of the first iteration of the loop, but on the second
iteration, after the first fork, the next instance of the platform
object will not have its platform port mapped.
The result of this bug is that subsequent connections to the platform,
when spawning the gdb-remote connection, will be supplied a random port
- which isn't bounded by the `--min-gdbserver-port` and
`--max-gdbserver--port` parameters passed in by the user.
This PR fixes this issue by having the port map be maintained by the
parent platform listener process. On connection, the listener allocates
a single available port from the port map, associates the child process
pid with the port, and lets the connection handling child use that
single port number.
Additionally, when cleaning up child processes, the main listener
process tracks the child that exited to deallocate the previously
associated port, so it can be reused for a new connection.
show more ...
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
2a579db3 |
| 03-Jul-2023 |
Haojian Wu <hokein.wu@gmail.com> |
[lldb] Replace llvm::writeFileAtomically with llvm::writeToOutput API.
Differential Revision: https://reviews.llvm.org/D154329
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
2fe83274 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
f190ce62 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optiona
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
343523d0 |
| 05-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[lldb] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of ma
[lldb] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
529a3d87 |
| 26-Jul-2022 |
Greg Clayton <gclayton@fb.com> |
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildb
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.
The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130549
show more ...
|
#
1b4b12a3 |
| 23-Jul-2022 |
Nico Weber <thakis@chromium.org> |
Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups
This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.
It broke
Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups
This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.
It broke the build on Windows, see comments on https://reviews.llvm.org/D130309
It also reverts these follow-ups:
Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14.
Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24.
Revert "Cache the value for absolute path in FileSpec." This reverts commit dabe877248b85b34878e75d5510339325ee087d0.
show more ...
|
#
9429b67b |
| 21-Jul-2022 |
Greg Clayton <gclayton@fb.com> |
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
The FileSpect APIs allow users to modify instance variables directly by getting a non const ref
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130309
show more ...
|
#
68793919 |
| 24-Jun-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Replace Host::SystemLog with Debugger::Report{Error,Warning}
As it exists today, Host::SystemLog is used exclusively for error reporting. With the introduction of diagnostic events, we have a
[lldb] Replace Host::SystemLog with Debugger::Report{Error,Warning}
As it exists today, Host::SystemLog is used exclusively for error reporting. With the introduction of diagnostic events, we have a better way of reporting those. Instead of printing directly to stderr, these messages now get printed to the debugger's error stream (when using the default event handler). Alternatively, if someone is listening for these events, they can decide how to display them, for example in the context of an IDE such as Xcode.
This change also means we no longer write these messages to the system log on Darwin. As far as I know, nobody is relying on this, but I think this is something we could add to the diagnostic event mechanism.
Differential revision: https://reviews.llvm.org/D128480
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
165545c7 |
| 24-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/gdb-remote] Ignore spurious ACK packets
Although I cannot find any mention of this in the specification, both gdb and lldb agree on sending an initial + packet after establishing the connectio
[lldb/gdb-remote] Ignore spurious ACK packets
Although I cannot find any mention of this in the specification, both gdb and lldb agree on sending an initial + packet after establishing the connection.
OTOH, gdbserver and lldb-server behavior is subtly different. While lldb-server *expects* the initial ack, and drops the connection if it is not received, gdbserver will just ignore a spurious ack at _any_ point in the connection.
This patch changes lldb's behavior to match that of gdb. An ACK packet is ignored at any point in the connection (except when expecting an ACK packet, of course). This is inline with the "be strict in what you generate, and lenient in what you accept" philosophy, and also enables us to remove some special cases from the server code. I've extended the same handling to NAK (-) packets, mainly because I don't see a reason to treat them differently here.
(The background here is that we had a stub which was sending spurious + packets. This bug has since been fixed, but I think this change makes sense nonetheless.)
Differential Revision: https://reviews.llvm.org/D114520
show more ...
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3 |
|
#
bbcb4d6b |
| 02-Sep-2021 |
Raphael Isemann <teemperor@gmail.com> |
Revert "[lldb server] Tidy up LLDB server return codes and associated tests"
This reverts commit e387c8c413e2127bc93950fb6d786290237b4a9f. The TestErrorMessages.test is failing on the Linux bots.
|
#
e387c8c4 |
| 02-Sep-2021 |
Sebastian Schwartz <saschwartz@fb.com> |
[lldb server] Tidy up LLDB server return codes and associated tests
This diff modifies the LLDB server return codes to more accurately reflect usage error paths. Specifically we always propagate the
[lldb server] Tidy up LLDB server return codes and associated tests
This diff modifies the LLDB server return codes to more accurately reflect usage error paths. Specifically we always propagate the return codes from the main entrypoints into GDB remote LLDB server, and platform LLDB server. This way, the top-level caller of LLDB server will be able to correctly check whether the executable exited with or without an error.
We additionally modify and extend the associated shell unit tests to expect nonzero return codes on error conditions.
Test Plan: LLDB tests pass:
``` ninja check-lldb ```
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D108351
show more ...
|
Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
#
76e47d48 |
| 26-May-2021 |
Raphael Isemann <teemperor@gmail.com> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
984e2f44 |
| 29-Mar-2021 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Prints error using WithColor::error in lldb-platform
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
a7f8d96b |
| 24-Nov-2020 |
David Spickett <david.spickett@linaro.org> |
[lldb] Use llvm::Optional for port in LaunchGDBServer
Previously we used UINT16_MAX to mean no port/no specifc port. This leads to confusion because 65535 is a valid port number.
Instead use an opt
[lldb] Use llvm::Optional for port in LaunchGDBServer
Previously we used UINT16_MAX to mean no port/no specifc port. This leads to confusion because 65535 is a valid port number.
Instead use an optional. If you want a specific port call LaunchGDBServer as normal, otherwise pass an empty optional and it will be set to the port that gets chosen. (or left empty in the case where we fail to find a port)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92035
show more ...
|
#
98e87f76 |
| 17-Nov-2020 |
David Spickett <david.spickett@linaro.org> |
[lldb] Error when there are no ports to launch a gdbserver on
Previously if you did: $ lldb-server platform --server <...> --min-gdbserver-port 12346 --max-gdbserver-port 12347 (meaning only use por
[lldb] Error when there are no ports to launch a gdbserver on
Previously if you did: $ lldb-server platform --server <...> --min-gdbserver-port 12346 --max-gdbserver-port 12347 (meaning only use port 12346 for gdbservers)
Then tried to launch two gdbservers on the same connection, the second one would return port 65535. Which is a real port number but it actually means lldb-server didn't find one it was allowed to use.
send packet: $qLaunchGDBServer;<...> read packet: $pid:1919;port:12346;#c0 <...> send packet: $qLaunchGDBServer;<...> read packet: $pid:1927;port:65535;#c7
This situation should be an error even if port 65535 does happen to be available on the current machine.
To fix this make PortMap it's own class within GDBRemoteCommunicationServerPlatform.
This almost the same as the old typedef but for GetNextAvailablePort() returning an llvm::Expected. This means we have to handle not finding a port, by returning an error packet.
Also add unit tests for this new PortMap class.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91634
show more ...
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2 |
|
#
c57ea1b4 |
| 17-Aug-2020 |
Raphael Isemann <teemperor@gmail.com> |
[lldb] Get lldb-server platform's --socket-file working again
`lldb-server platform --socket-file /any/path` currently always fails to create the socket file. This stopped working after D67424 whic
[lldb] Get lldb-server platform's --socket-file working again
`lldb-server platform --socket-file /any/path` currently always fails to create the socket file. This stopped working after D67424 which changed the input variables of `writeFileAtomically` slightly. We're expected to pass in a temporary path template (`/tmp/foo-%%%%%`) and the final path we want to write. Instead we currently pass in the never set `temp_file_path` as the temporary path (which will make this function always fail) and pass in the temp_file_spec's path as the final path (which is actually the template path such as `/tmp/foo-%%%%%`) instead of the actual path we want to write (e.g. `/tmp/foo`).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85890
show more ...
|