Re: [HACKERS] Runtime Partition Pruning

Hi,

On 2019-05-25 00:42:39 +0200, Tomas Vondra wrote:
> On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote:
> > On 2019-05-24 12:08:57 -0400, Tom Lane wrote:
> > > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > The basic problem with backtrace() is that it
> > > only knows about global functions, and so reports call sites in static
> > > functions as if they were in whatever global function physically precedes
> > > the static one.
> >
> > Does that depend on whether the program was compiled with
> > -fno-omit-frame-pointer? At least some distros now compile with frame
> > pointers enabled, to get reasonably fast perf profiles (at a basically
> > immeasurable slowdown, on modern-ish CPUs).
> >
>
> I doubt that, because if that was the case we'd not be able to get
> accurate profiles from perf, no? And AFAICS that's not the case,
> irrespectedly of whether -fno-omit-frame-pointer is used.

I can't parse this. With perf you can get accurate call-graph profiles
if you either use -fno-omit-frame-pointer, to force frame pointers to be
present (so the call graph can cheaply be assembled during profiling),
or with dwarf (the entire stack is saved, and then dwarf is unwinding at
perf report time - very large), or with lbr (CPU saves traces of
branches taken, enabling call graphs to be computed, but it needs they're not
very deep).

> > > I think doing materially better requires depending on
> > > debug symbols, which (at least in the Red Hat world) aren't going to
> > > be there in a typical production situation.
> >
> > It's still a lot easier to install debug symbols than to attach a
> > debugger and get a backtrace that way. Especially when the problem is
> > hard to reproduce.
> >
>
> Right. Debugger requires interaction with a running process, while
> having it integrated would make that unnecessary.
>
> But I think Peter also suggested this might require the ability to
> selectively enable the backtraces, and I think he's right. I doubt we
> want to log them for every log message, right?

Well, I think that if we had PANIC, SIGSEGV/BUS most FATALs covered,
we'd be off to a very good start. I'm not sure it's wise to give users
control over the computation of stack computations.

Greetings,

Andres Freund