Page MenuHomePhabricator

Modify split CallSiteRanges to use correct lengths

Authored by modimo on Oct 9 2020, 6:46 PM.



In D73739 @MaskRay pointed out that the lengths for CallSiteRanges in .gcc_except_table are not quite correct if blocks are outlined or using basic-block-sections. At runtime this is fine because the .eh_frame data will limit a function to a particular LSDA entry so that even though the longer length allows buffer-overflow the code length in .eh_frame acts as a back-stop.

However, in post-binary analysis tools (e.g. BOLT) that may only parse the .gcc_except_table section having these lengths be incorrect will result in a buffer overflow when using this field to read forward.

There's no binary cost for making these labels correct and leads to smaller offsets which compress better leading to very minor metadata size reduction.

ninja check

Diff Detail

Event Timeline

modimo created this revision.Oct 9 2020, 6:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 9 2020, 6:46 PM
modimo requested review of this revision.Oct 9 2020, 6:46 PM
modimo updated this revision to Diff 297377.Oct 9 2020, 6:48 PM

Remove useless "if"

modimo edited the summary of this revision. (Show Details)Oct 9 2020, 6:49 PM

Unfortunately this does not work. The idea of D73739 is that all call site tables share the same action table. For each call site table, the action record offset of any call site entry is related to action_table_end. All call site tables need to share the same action_table_end. The weird thing is that call site tables will appear to be overlapping because action_table_end is also used to compute the size of a call site table.

modimo abandoned this revision.Oct 12 2020, 12:42 PM

@MaskRay Ah the action table start is inferred as the end of the CST. Saves a pointer but shackles the implementation. These tables will be fairly small (effectively 1 entry per "catch" in a function) and not all CST would need a corresponding action table (only those inside "try" do) so duplicating them is not as far-fetched as it would initially sound.

For my purposes though, the CST entries are guaranteed to be inclusive to the end of the function. Thus, at binary analysis level I can infer the end of the CST from the .eh_frame function length that points me there.