================ @@ -1181,6 +1181,30 @@ These packets must be sent _prior_ to sending a "A" packet. a target after making a connection to a GDB server that isn't already connected to an inferior process. +## QSetSTDIOWindowSize:cols=\<N\>;rows=\<N\> + +Set the terminal window size for the inferior's stdio pseudo-terminal prior to +sending an "A" packet. + +When launching a program that uses a pseudo-terminal (PTY) for stdio, this +packet specifies the initial terminal dimensions: +``` +QSetSTDIOWindowSize:cols=<N>;rows=<N> +``` +Both `cols` and `rows` must be non-zero unsigned 16-bit integers. The packet +must be sent _prior_ to sending an "A" packet. On the server side, the +dimensions are applied to the PTY via `TIOCSWINSZ` (POSIX) or the equivalent +platform mechanism (e.g. `ConPTY` resize on Windows). + +The response is either: +* `OK`: dimensions accepted. +* `ENN`: malformed packet or zero value for `cols`/`rows`. ---------------- DavidSpickett wrote:
Should we include in here the possibility that the remote couldn't apply the dimensions? You limit these to 16-bit numbers, which does fit with what I read in https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#cursor-positioning. ``` >>> hex(32767) '0x7fff' ``` And on the Linux side I see unsigned shorts in https://man7.org/linux/man-pages/man2/TIOCSWINSZ.2const.html. So in theory we can always ask for up to 0xffff dimensions, but whether we can expect that to always work, I don't know. Anyway, easy to handle it here with: `ENN`: malformed packet, invalid value for `cols` or `rows`, or the requested dimensions could not be applied. https://github.com/llvm/llvm-project/pull/201141 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
