Re: kgdb replacing newline with CRLF in custom query response

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, Nov 7, 2024 at 2:23 PM Omar Sandoval <osandov@xxxxxxxxxxx> 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?

-Doug





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux