Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading .sframe headers

Josh Poimboeuf <[email protected]>
Newsgroups org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-trace-kernel
Message-ID <20250207211324.jwtyy3z5ud2jwegi@jpoimboe>
On Wed, Feb 05, 2025 at 02:56:36PM +0100, Jens Remus wrote:
> On 29.01.2025 03:02, Josh Poimboeuf wrote:
> 
> > Note FDEs aren't even needed here as the unwinder doesn't need to know
> > when a function begins/ends.  The only info needed by the unwinder is
> > just the fre_data struct.  So a simple binary search of fres[] is all
> > that's really needed.
> 
> In SFrame V2 FDEs specify ranges bound by function start address and
> length.  FREs in contrast specify open ranges bounded by start address.
> Their effect ends either with the next FRE becoming into effect or when
> their FDE range ends.
> This concept enables holes in the .text section which do not have any
> valid FDE/FRE information associated.
> 
> Your proposal lacks some sort of mechanism to replicate those holes.
> It could be FDEs with a flag (or no offsets?) that specifies their
> range has no valid information.

In ORC, a hole is simply specified by an ORC entry (aka "FRE") of type
UNDEFINED.

That could be done here as well: the linker would replace a gap with an
"undefined" FRE which could be identified either by setting a bit in the
FRE header, or by using a special fre_data[] entry.  For example,
fre_data index 0 could just be a placeholder for the undefined FRE type.

-- 
Josh
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.