[PATCH,V1 00/14] Definition and support for SFrame unwind format

Nick Clifton nickc@redhat.com
Fri Sep 30 09:12:31 GMT 2022


Hi Indu,

> The format specification document still mains a TODO at this time. I plan to
> resume working on this after I have tackled the task of SFrame generation for
> PLT/veneers in aarch64.

I am concerned about this.  If you do not have a specification then it is going
to be hard to get the format adopted by third parties.  I assume that you would
like tools such as LLVM to support the format, as well as projects like the
Linux kernel.  Maybe other commercial interests or academic endeavours.  None of
them are going to take the format seriously if there isn't a specification.


> The format is supported on AMD64 and AARCH64 ABIs only.

This is sad and a little bit surprising.  I would have at least expected to see
the x86_64 architecture listed as well, and ideally I would like to see a whole
lot more.  I do hope that your plans including writing a "How to extended the
SFrame specification/implementation to support a new architecture" document.


> The information stored
> in the .sframe section is a subset of what .eh_frame can convey: .eh_frame can
> convey how to resurrect all callee-saved registers, if need be; but .sframe
> does not.

Is it possible to convert existing .eh_frame sections into equivalent .sframe
sections ?

Cheers
   Nick



More information about the Binutils mailing list