Re: instrumentation, was Re: core dump analysis

[Finn Thain <fthain@linux-m68k.org>]

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.