[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Weimin Pan
Subject: Re: [PATCH][gnulib] Add the Sframe package
Date: Fri, 18 Nov 2022 15:38:14 -0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 11/17/2022 5:24 PM, Bruno Haible 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?

Yes, I believe this issue has been addressed and resolved.
Yes, the copyright issue has been addressed and resolved.

5) They wanted something to the point: just unwind information, i.e. the
     ability of jumping back the stack frames.  This doesn't include type
     information, the contents of every callee-saved register, etc.
I read the same thing in <https://www.phoronix.com/news/GNU-Binutils-SFrame>:
"callee-saved registers other than FP are not needed for stack unwinding,
  and hence are not included in the .sframe section."
but I don't understand it: If you don't have the contents of the
callee-saved registers, you can perfectly well produce a textual stack trace
but how would you "jump back", in the sense of transferring control,
like longjmp() does?

Sorry, "jumping" back is in the sense of regenerating the stack frame chain,
not transferring of program execution.

    - The *.c and *.h files should be untabified (run 'expand -t 8' on each).
OK, will do.
Two other points:

   * sframe.h should have a pointer to the specification document of Sframe.
     AFAIU, it is
     , right?

OK, will add.

   * sframe-api.h and sframe.c contains both a decoder and an encoder.
     You said that the "main use-case for this format are "online" debugging
     tools like stack tracers". Does an average stack trace require the
     ability to encode Sframe?
     If not, then we should have two Gnulib modules: an sframe-decode and
     an sframe-encode module. The former would be sufficient for stack tracers,
     the latter would only be required for other uses (in gas, for example).

No, the stack tracer doesn't need to encode. It does make logical sense to have 2 separate modules, one for the encoder and the other for the decoder. Will look into it.

You also wrote:
   "the plan is to switch the later to use this gnulib module instead
    in order to minimize external dependencies."
So, you plan to avoid code duplication between
and Gnulib by having binutils import the code from Gnulib?

Yes, that is the goal. But we'd like to keep both options open for now, in case importing
source code from gnulib-tool becomes too complex.

Finally, can you propose a reviewer for this code? Someone who will
try to find mistakes or bugs and who is not a co-author. I am reviewing
most of the Gnulib contributions, but this large contribution is more
than I can easily take on.

Sorry, not familiar with the protocol. You meant someone from Oracle? or from anywhere else will do?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]