On 6/27/22 4:47 PM, Indu Bhagat wrote:
> Hi,
> 
> This is version 4 of the previously sent RFC series.
> 
> Initial (V1) posting contains necessary introductions:
> https://sourceware.org/pipermail/binutils/2022-May/120731.html
> V2 posting with some improvements:
> https://sourceware.org/pipermail/binutils/2022-May/120899.html
> V3 posting with further improvements:
> https://sourceware.org/pipermail/binutils/2022-June/121245.html
> 
> The commit log of each patch in the current patch series specifies the changes
> from the version V3 of the respective patch.  Briefly, following are the main
> changes in the current version V4 as compared to V3:
> 
> 1. CTF Frame format can now compactly represent unwind information for regular,
>    repetitive instruction patterns like the plt entries.  This has helped make
>    the size of .ctf_frame more attractive.  [As .ctf_frame encodes a subset of
>    information in .eh_frame, the sizes of .eh_frame will be justifiably higher.]
> 
>    ratio = (.ctf_frame size) / (.eh_frame size + .eh_frame_hdr size)
> 
>    Program   | ratio
>    ----------------
>    addr2line | .76
>    as        | .81
>    elfedit   | .76
>    gdb       | .78
>    gdbserver | .78
>    gprof     | .80
>    ld        | .81
>    nm        | .78
>    objdump   | .81
>    readelf   | .82
>    strings   | .76
>    ar        | .78
>    c++filt   | .75
>    gprofng   | .59
>    ld.bfd    | .81
>    objcopy   | .81
>    ranlib    | .78
>    size      | .76
>    strip     | .81
> 
>    In summary, earlier the CTF Frame unwind information for plt entires looked
>    like follows (in V3).
> 
>    $ readelf --ctf-frame=.ctf_frame testbinary
>    ...
>      func idx [0]: pc = 0x401020, size = 64 bytes
>      STARTPC           CFA       FP        RA
>      0000000000401020  sp+16     u         u
>      0000000000401026  sp+24     u         u
>      0000000000401030  sp+8      u         u
>      000000000040103b  sp+16     u         u
>      0000000000401040  sp+8      u         u
>      000000000040104b  sp+16     u         u
>      0000000000401050  sp+8      u         u
>      000000000040105b  sp+16     u         u
> 
>    Now with the V4 version of the patch series:
> 
>      func idx [0]: pc = 0x401020, size = 16 bytes
>      STARTPC         CFA       FP        RA
>      0000000000401020  sp+16     u         u
>      0000000000401026  sp+24     u         u
> 
>      func idx [1]: pc = 0x401030, size = 48 bytes
>      STARTPC[m]      CFA       FP        RA
>      0000000000000000  sp+8      u         u
>      000000000000000b  sp+16     u         u
> 
> 2. More testcases in libctfframe, further improvements and bugfixes.
> 
> This is a work in progress. In the subsequent iterations of the series,  I plan
> to focus on further testing CTF Frame unwind information for correctness and
> completeness.  We currently have a suite of unwinder tests which are used to
> validate the CTF Frame unwind information in various scenarios on x86_64 and
> aarch64 by unwinding through a variety of call stacks.  We will now work on
> increasing the coverage of those tests and incorporating the testsuite (perhaps
> with libctfbacktrace) in the next patch series.
> 
> That said, CTF Frame support V4 patch series has been regression tested on a
> host of targets with no regressions.
> 
> Important note: libctfframe/configure has NOT been included in the patch
> series, as it causes the size of some patches to go beyond the allowed limit.
> Please regenerate the libctfframe/configure after applying the series.
> 
> Please comment and provide feedback, it will help shape the format.  At this
> time, I really need some inputs on:
> 
> 1. What is a good place for an unwinder based on CTF Frame format ? Currently
> to facilitate discussion, it is presented in a library of its own:
> libctfbacktrace which, in turn, uses the libctfframe library for decoding the
> .ctf_frame section for unwinding.  We brainstormed a bit about the possible
> candidates being libbacktace, libgcc or libunwind ? Are there any
> recommendations ?
>   
> Thanks,
> 
> Indu Bhagat (6):
>    ctf-frame.h: Add CTF Frame format definition
>    gas: add new command line option --gctf-frame
>    gas: generate .ctf_frame
>    bfd: linker: merge .ctf_frame sections
>    readelf/objdump: support for CTF Frame section
>    gdb: sim: buildsystem changes to accommodate libctfframe
> 
> Weimin Pan (2):
>    libctfframe: add the CTF Frame library
>    unwinder: generate backtrace using CTF Frame format
> 

Hello,

Here are two Poke pickles for CTF Frame format (as defined in the V4 
posting of the patch series).

I am adding the two pickles to the libctfframe/ dir for now. I will send 
these to GNU poke for inclusion, meanwhile, sending them here in hope 
they help folks understand the ins and outs of the CTF Frame section:

libctfframe/ctf-frame.pk
libctfframe/ctf-frame-dump.pk

If you want to use these pickles in GNU poke, following is one way to 
use these pickles.

$ objcopy --dump-section .ctf_frame=output_ctf_frame binary
$ poke output_ctf_frame

In the GNU poke program:
(poke) .load pickles/ctf-frame-dump.pk
## for nicely formatted dump in tree mode
(poke) .set omode tree
(poke) var ctf_frame = CTF_Frame_section @ 0#B
(poke) ctf_frame
(poke) ctf_frame_dump_fres (ctf_frame)
(poke) ctf_frame_dump_fdes (ctf_frame)

Then you can use the functions in the ctf-frame-dump.pk pickle or 
inspect the ctf_frame as you please.

Thanks
Indu