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

[Jose E. Marchesi]

> 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.

I think there is a misunderstanding here.

We are not suggesting to subsume libbacktrace nor libunwind into Gnulib,
nor to use gnulib in any of these projects.

This is just about adding a module to gnulib to make it easy for
programs to read and write SFrame data.  As explained above, in our
opinion the simple and "online" nature of SFrame unwind info makes it
inconvenient and overkill for programs to rely on an external dependency
just to read (or write) it.