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

Indu Bhagat
2025-02-06T01:11:18Z

On 2/4/25 4:57 PM, Josh Poimboeuf wrote:
> On Thu, Jan 30, 2025 at 01:39:52PM -0800, Indu Bhagat wrote:
>> On 1/28/25 6:02 PM, Josh Poimboeuf wrote:
>>> However, if we're going that route, we might want to even consider a
>>> completely revamped data layout. For example:
>>>
>>> One insight is that the vast majority of (cfa, fp, ra) tuples aren't
>>> unique. They could be deduped by storing the unique tuples in a
>>> standalone 'fre_data' array which is referenced by another
>>> address-specific array.
>>>
>>> struct fre_data {
>>> s8|s16|s32 cfa, fp, ra;
>>> u8 info;
>>> };
>>> struct fre_data fre_data[num_fre_data];
>>>
>>
>> We had the same observation at the time of SFrame V1. And this method of
>> compaction (deduped tuples) was brain-stormed a bit. Back then, the costs
>> were thought to be:
>> - more work at build time.
>> - an additional data access once the FRE is found (as there is
>> indirection).
>>
>> So it was really compaction at the costs above. We did steer towards
>> simplicity and the SFrame FRE is what it stands today.
>>
>> The difference in the pros and cons now from then:
>> - pros: helps mitigate unaligned accesses
>> - cons: interferes slightly with the design goal of efficient addition and
>> removal of stack trace information per function for JIT. Think "removal" as
>> the set of actions necessary for addressing fragmentation in SFrame section
>> data in JIT usecase.
>
> If fre_data[] is allowed to have duplicates then the deduping could be
> optional.
>
>>> 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.
>>
>> Splitting out information (start_address) to an FDE (as done in V1/V2) has
>> the benefit that a job like relocating information is proportional to
>> O(NumFunctions).
>>
>> In the case above, IIUC, where the proposal puts start_address in the FRE,
>> these costs will be (much) higher.
>
> I'm not sure I follow, is this referring to the link-time work of
> sorting things?
>

I meant the work of tracking the start address of each function. This
could be done at link-time as is done in most cases.

But also depending on the case : e.g., kernel module loader will need to
apply these relocations in the .rela.sframe section...

If the granularity is finer than a function, more number of relocations
will need to be applied.

>> In addition, not being able to identify stack trace information per function
>> will affect the JIT usecase. We need to able to mark stack trace
>> information stale for functions in JIT environment.
>
> Maybe, though it's hard to really say how any of these changes would
> affect JIT without knowing what those interfaces are going to look like.
>