Re: instrumentation, was Re: core dump analysis

Finn Thain
2023-04-11T05:51:03Z

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Tue, 11 Apr 2023, Michael Schmitz wrote:

> Am 11.04.2023 um 12:20 schrieb Finn Thain:
> > On Sun, 9 Apr 2023, Michael Schmitz wrote:
> >> Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven:
> >>> On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz <wrote:
> >>>> The easiest way to do that is to log all wait and signal syscalls,
> >>>> as well as process exit. That might alter timing if these log
> >>>> messages go to the serial console though. Is that what you have in
> >>>> mind?
> >>>
> >>> Store to RAM, retrieve through a new /proc file?
> >>
> >> Yes, that could be done, though I'd rather avoid duplicating a lot of
> >> the generic message formatting code (printk and friends).
> >>
> >> I'll have a look around ...
> >>
> >
> > A better solution might be be to port the existing instrumentation
> > like ftrace, kprobes, uprobes etc. Might be a lot of work though. I
> > wonder how portable that stuff is.
> >
> > If you use printk, you could probably avoid most of the delays by
> > enabling the dummy console. Then the kernel messages would be
> > collected with dmesg, given a sufficiently large CONFIG_LOG_BUF_SHIFT.
> > But it would be inconvenient to have no serial console available for
> > the usual purposes.
>
> Can we disable the serial console after boot, by registering the dummy
> console? Or will that just log messages to both?
>

I don't know. I'd have to experiment in QEMU or Aranym.