On 4/13/23 9:30 AM, Josh Poimboeuf wrote:
On Thu, Apr 13, 2023 at 09:59:31AM -0500, Madhavan T. Venkataraman wrote:
On 4/12/23 10:52, Josh Poimboeuf wrote:
On Wed, Apr 12, 2023 at 09:50:23AM -0500, Madhavan T. Venkataraman wrote:
I read through the SFrame spec file briefly. It looks like I can easily adapt my
version 1 of the livepatch patchset which was based on DWARF to SFrame. If the compiler
folks agree to properly support and maintain SFrame, then I could send the next version
of the patchset based on SFrame.
But I kinda need a clear path forward before I implement anything. I request the arm64
folks to comment on the above approach. Would it be useful to initiate an email discussion
with the compiler folks on what they plan to do to support SFrame? Or, should this all
happen face to face in some forum like LPC?
SFrame is basically a simplified version of DWARF unwind, using it as an
input to objtool is going to have the same issues I mentioned below (and
as was discussed with your v1).
Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks
can provide the feature with a reliability guarantee. DWARF is too complex.
I don't see what the complexity (or lack thereof) of the unwinding data
format has to do with it. The unreliability comes from the underlying
data source, not the formatting of the data.
What I meant is - if SFrame is implemented by simply extracting unwind info from
DWARF data and placing it in a separate section (as it is probably implemented now),
then what you say is totally true. But if the compiler folks agree to make SFrame reliable,
then either they have to make DWARF reliable. Or, they have to implement SFrame as a
separate feature and make it reliable. The former is tough to do as DWARF has a lot of complexity.
The latter is a lot easier to do.
SFrame stack trace data is generated by the GNU assembler, by using the
.cfi_* asm directives embedded by the compiler. So, it is true that the
source of EH_Frame info and SFrame stack trace data is the same.
That said, yes, if you see bugs/inconsistencies in SFrame/EH_Frame info,
please file the issue(s).
[ adding linux-toolchains ]
I don't think ensuring reliability is an easy task, regardless of the
complexity of the unwinding format.
Whether it's SFrame or DWARF/eh_frame, the question would be how to
ensure it's always reliable for a compiler "power user" like the kernel
which has many edge cases (including lots of inline asm which the
compiler has no visibility to) and which uses unwinding for more than
just debugging.
It would need some kind of black-box testing on a complex code base.
(hint: kind of like what objtool already does today)
