[Dwarf-discuss] Proposal: Clarify DWARF Address Range Overlap Rules
Ron Brender
ron.brender@gmail.com
Thu Dec 12 19:25:24 GMT 2024
>The current DWARF 5 specification's statement in Section 2.17.3 (p. 53,
line 15) that "Bounded range entries in a range list may not >overlap" is
overly restrictive and doesn't reflect valid cases where identical code
sequences are merged. The specification needs to >differentiate between
valid identical overlaps and invalid partial overlaps, both within range
lists and between different >`DW_TAG_subprogram` entries.
Rather than claim that the specification is "overly restrictive" it seems
to me that the linker has simply failed to complete its job which should
include rewriting the range lists to properly satisfy the spec. From the
few examples that David has shown, this will have the added benefit of
saving space by reducing the number of bounded range entries. If two
entries totally overlap then only one is needed--so keep one and delete the
other. If two entries have a partial overlap then again only one is
needed--so update one to have a lower bound that is the min of the two
originals and an upper bound that is the max of the two, and delete the
other.
It seems ironic to me that a linker would go to a lot of trouble to save
code space across multiple modules and then ignore potential resulting
DWARF description space savings. If the linker would just finish its job,
then no spec change need be contemplated.
Ron
On Wed, Dec 11, 2024 at 7:59 PM Alex via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> # Clarification of Address Range Overlap Rules for Functions and Basic
> Blocks
>
> ## Background
>
> Modern compiler optimizations and linker features can result in functions
> or basic blocks sharing the same address ranges in the final binary. Two
> common cases are:
>
> 1. Identical Code Folding (ICF) at link time, where identical functions
> are merged to reduce code size
> 2. Basic block section optimizations (e.g., `-fbasic-block-sections=all`),
> where basic blocks from different functions may be reordered and identical
> blocks merged
>
> The current DWARF 5 specification's statement in Section 2.17.3 (p. 53,
> line 15) that "Bounded range entries in a range list may not overlap" is
> overly restrictive and doesn't reflect valid cases where identical code
> sequences are merged. The specification needs to differentiate between
> valid identical overlaps and invalid partial overlaps, both within range
> lists and between different `DW_TAG_subprogram` entries.
>
> ## Overview
>
> This proposal seeks to:
>
> 1. Correct and clarify the rules regarding overlapping ranges within a
> single range list
> 2. Clarify rules for overlapping function ranges specified via
> DW_AT_low_pc/DW_AT_high_pc
> 3. Address the validity of identical overlapping ranges resulting from
> code merging optimizations
>
> ## Proposed Changes
>
> In Section 2.17 (Location Descriptions), replace the text on p. 53, line
> 15:
>
> From:
> ```
> Bounded range entries in a range list may not overlap. There is no
> requirement that the entries be ordered in any particular way.
> ```
>
> To:
> ```
> Bounded range entries in a range list must not partially overlap. However,
> range entries may
> be exactly identical (having the same low and high PC values), which
> commonly occurs when
> compiler or linker optimizations merge identical code sequences. A partial
> overlap occurs
> when two ranges share some but not all addresses. There is no requirement
> that the entries
> be ordered in any particular way.
>
>
> Similarly, when ranges are specified using DW_AT_low_pc and DW_AT_high_pc
> attributes,
> multiple debugging information entries (such as DW_TAG_subprogram entries)
> may specify
> identical ranges when they represent code that has been merged by
> optimizations. However,
> partial overlaps between ranges are not permitted, as this would create
> ambiguity in
> determining which code sequence is being executed at a given address.
> ```
>
> ## Dependencies
>
> None
>
> ## References
>
> 1. LLVM Pull Request demonstrating the need for this clarification (+
> additional discussion):
> https://github.com/llvm/llvm-project/pull/117952
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20241212/f10185bc/attachment-0001.htm>
More information about the Dwarf-discuss
mailing list