Re: [PATCH][gnulib] Add the Sframe package

[Jeffrey Walton]

On Thu, Nov 17, 2022 at 8:24 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Weimin Pan wrote:
> > We came to design the SFrame format (The S stands for `simple') due to some
> > concrete requirements of a very big program that ships its own "online"
> > stack tracer and unwinder to handle error conditions:
> >
> > 1) They wanted something simple to decode and simple to compute.  This
> >     is in contrast with DWARF/eh_frame that, generally, requires
> >     executing DWARF expressions and therefore the maintenance of a small
> >     stack machine.
> >
> > 2) They wanted the unwind info to be fast to decode and to compute.
> >
> > 3) They wanted the unwind info to be as compact as possible, of course
> >     maintaining a good trade-off vs. simplicity.
> >
> > 4) They wanted something that wouldn't be stripped out of the
> >     executables or shared objects, even maybe as a mistake.
>
> Thanks for the explanations.
>
> > Now, both libbacktrace and libunwind use eh_frame or DWARF as an
> > underlying format from which to extract the unwind info.  We could (and
> > have considered) adding support for SFrame as well to these libraries,
> > but that is orthogonal to adding the modules (definition of the stored
> > format data structures, and convenience encoders/decoders) to gnulib:
> > the applications using the modules will most likely implement its own
> > stack tracer and debug infrastructure.
>
> I agree that it is orthogonal. Since you wrote that one of the goals was
> "to minimize external dependencies", it makes sense to make the code
> available outside of libbacktrace and libunwind, and Gnulib seems an
> appropriate place.
>
> Anyone has an objection to including this in Gnulib?

I don't think it's a good idea to subsume libbacktrace and libunwind
into Gnulib.

First, from another project's point of view, the dependency has not
changed. A dependency still exists. It has just moved around.

Second, I'm guessing other projects may want libbacktrace or libunwind
without the Gnulib dependency. Gnulib is non-trivial to incorporate
into a project. That's a lot of extra maintenance costs for other
projects.

Third, libbacktrace and libunwind are extra maintenance for the Gnulib
folks. It is an extra drain on your limited development cycles.

Finally, libunwind has some troubles on non-Linux platforms. I'm
pretty sure MacPorts is still waiting for a libunwind that works with
modern Clang and C++. I don't think it's fair to the Gnulib folks to
inherit problems like that.

Jeff