We already have the ability to collect the server logs when doing local debugging. This enables
the collection of remote logs as well. This relies on specifying a relative path "server.log" for
LLDB_DEBUGSERVER_LOG_FILE when starting remote platform. Since we always set the platform working
directory to a fresh folder to avoid conflicts, the actual file path will always be different and
we can pick the logs up from there.
Details
Diff Detail
Event Timeline
Looks reasonable.
I added one question on whether we can get a warning on failure to retrieve the server.log file when expecting one and it doesn't show up (perhaps only in verbose mode), which is totally not needed for this patch.
There's also one minor comment fix.
packages/Python/lldbsuite/test/lldbtest.py | ||
---|---|---|
1380 | minor: s/writting/writing/ | |
1385–1386 | It might be nice to get some kind of output (perhaps in verbose mode?) if we're expecting the server.log to be there but we fail to retrieve it. (Just a warning). Does lldb.remote_platform.Get() already do that on a failure? |
packages/Python/lldbsuite/test/lldbtest.py | ||
---|---|---|
1385–1386 | It's not really clear when are we expecting it. A user might choose to enable logging on the remote system, or he may choose not to. Both are valid options, and right now we don't tell the client which one of them is happening. So, unless we introduce another option --enable-server-logging or something, the client has no way of knowing whether server logging is active. Perhaps I could just rephrase the comment to better explain the "best-effort" part? |
packages/Python/lldbsuite/test/lldbtest.py | ||
---|---|---|
1385–1386 | Oh okay - I thought we'd know for sure if the user was trying (or not trying) to log on the remote system. If we don't know, no biggie. I just thought it would be nice to know we didn't get the log when we were expecting it. But if that's not possible, so be it. |
minor: s/writting/writing/