Re: kgdb replacing newline with CRLF in custom query response

[Omar Sandoval <osandov@osandov.com>]

On Thu, Nov 07, 2024 at 05:08:58PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Thu, Nov 7, 2024 at 2:23 PM Omar Sandoval <osandov@osandov.com> wrote:
> >
> > Hi everyone,
> >
> > Amal is working on adding a custom query packet to kgdb for getting the
> > kernel's vmcoreinfo. The rationale and details are available here:
> > https://github.com/osandov/drgn/wiki/GDB-Remote-Protocol-proposal:-linux.vmcoreinfo-query-packet
> >
> > vmcoreinfo is about 3kB, so we were hoping to avoid hex-encoding the
> > response and doubling the time it takes to transmit over a slow serial
> > connection. Instead, we were hoping to use the escaped binary format,
> > which escapes the characters #$}* and leaves other bytes untouched.
> >
> > We ran into a problem, though: vmcoreinfo contains newline characters,
> > which the serial core replaces with CRLF; see commit c7d44a02ac60
> > ("serial_core: Commonalize crlf when working w/ a non open console
> > port").
> 
> FWIW, the problem predates that commit, but that commit at least moved
> it to be someplace common. Before that some serial drivers were
> hardcoding it... ;-)
> 
> 
> > This effectively corrupts the data and causes a checksum
> > mismatch.
> >
> > We'd love some input on how to work around this, especially from the
> > kgdb maintainers. Here are a few options, in descending order of my
> > preference:
> >
> > 1. Disable the LF -> CRLF replacement while sending binary data.
> > 2. Escape the newlines using some other custom scheme.
> > 3. Give up and hex-encode the response.
> 
> I haven't tried prototyping it, but what about moving the LR -> CRLF
> code to kdb_msg_write(). It would be really easy to do this in the
> case where we're doing "dbg_io_ops->write_char()" since we're already
> processing character at a time. It would be harder to do this when
> also sending the output to the various console, but may not _too_
> hard? You could loop searching for "\n" and send all the characters
> before the "\n", then send a "\r", then send the "\n" and all the
> characters up to the next "\n".
> 
> If you did this then you'd lose the "\n" to "\r\n" combination in the
> gdb stub, but _probably_ that doesn't matter?

That sounds reasonable. I was concerned whether this would affect
anything else using the ->poll_put_char() tty operation, but kgdb seems
to be the only user, does that sound right?

Thanks for the quick response!

Omar