This is an archive of the discontinued LLVM Phabricator instance.

[lldb-server] Report launch error in vRun packets
ClosedPublic

Authored by labath on Sep 6 2022, 6:44 AM.

Details

Summary

Uses our existing "error string" extension to provide a better
indication of why the launch failed (the client does not make use of the
error yet).

Also, fix the way we obtain the launch error message (make sure we read
the whole message, and skip trailing garbage), and reduce the size of
TestLldbGdbServer by splitting some tests into a separate file.

Diff Detail

Event Timeline

labath created this revision.Sep 6 2022, 6:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 6 2022, 6:44 AM
labath requested review of this revision.Sep 6 2022, 6:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 6 2022, 6:44 AM
labath updated this revision to Diff 458172.Sep 6 2022, 7:34 AM

Add windows error msg

mgorny added inline comments.Sep 6 2022, 8:33 AM
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
19

Since we no longer support Python 2, I'd rather prefer to work towards removing seven rather than making more use of it.

labath added inline comments.Sep 6 2022, 9:18 AM
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
19

Is the problem with the name/location of the function or the functionality (string/byte conversion) itself?
Because, if it's the first, then that could easily be solved by renaming the module (now or later), but in order to avoid elaborate casts we'd have to make all code be byte/string correct. This is not a problem here (because of the fixed strings), but it becomes one once you start working with things that aren't necessarily valid utf8 strings.

mgorny accepted this revision.Sep 6 2022, 9:46 AM
mgorny added inline comments.
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
19

Ok, I suppose this makes sense given how LLDB's Python API is screwed up :-(.

This revision is now accepted and ready to land.Sep 6 2022, 9:46 AM
rupprecht requested changes to this revision.Sep 6 2022, 12:45 PM
rupprecht added inline comments.
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
293

IIUC, this will overrun the buffer if there are >1000 bytes to read; whereas previously we just wouldn't have read everything.

Should each loop iteration grow the buffer by a certain amount? Otherwise I think we need to remove the loop.

This revision now requires changes to proceed.Sep 6 2022, 12:45 PM
labath updated this revision to Diff 458405.Sep 7 2022, 3:22 AM

dynamically resize error buffer

labath added inline comments.Sep 7 2022, 3:34 AM
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
293

It won't overrun because I am passing the remaining part of the buffer as the size argument. However, I am not totally sure what would happen if we actually filled the buffer (and size becomes zero). That won't happen right now because the error string is coming from ExitWithError (line 50) and its length is limited by the longest errno message. That said, the dynamical resize is quite simple in this case, so I might as well do it.

lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
19

Just to clarify, I would like if we used the byte/string separation more (and I started that when I refactored the gdb server test harness), but it's fairly tricky because we're often working with things (e.g. memory contents, or stdout) that can represent arbitrary data in general, but which usually (for our own convenience and sanity) contain simple ASCII strings. So we have a problem where the API (and here I just mean the gdbserver test API, which we can change) really wants us to use bytes, but the the most natural way to write the test is with strings. I haven't come up with a solution to that yet.

labath updated this revision to Diff 458408.Sep 7 2022, 3:36 AM

Use pos instead of the previous size in the resize expression.

mgorny added inline comments.Sep 7 2022, 4:04 AM
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
19

Yeah, I know. On the plus side, as long as we're dealing with plain ASCII, using bytes is relatively easy and most of the string-like functionality just works. You just have to remember that you want to use byte-strings ;-).

rupprecht accepted this revision.Sep 7 2022, 1:08 PM
rupprecht added inline comments.
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
293

Thanks! I still think it's good to be dynamic in case this assumption changes one day, and the error string ends up being longer than 1000 bytes.

This revision is now accepted and ready to land.Sep 7 2022, 1:08 PM
This revision was automatically updated to reflect the committed changes.