Mapping symbol optimization: implicit one at section beginning
Fangrui Song
i@maskray.me
Mon Jul 29 16:51:32 GMT 2024
On Mon, Jul 29, 2024 at 1:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 29.07.2024 09:55, Fangrui Song wrote:
> > On Mon, Jul 22, 2024 at 11:24 PM Jan Beulich <jbeulich@suse.com> wrote:
> >> On 22.07.2024 20:37, Fangrui Song wrote:
> >>> I have written a detailed analysis at
> >>> https://maskray.me/blog/2024-07-21-mapping-symbols-rethinking-for-efficiency
> >>> and proposed an alternative scheme to address the size concern:
> >>>
> >>> * Text sections: Assume an implicit $x at offset 0. Add an ending $x
> >>> if the final data isn't instructions.
> >>> * Non-text sections: Assume an implicit $d at offset 0. Add an ending
> >>> $d only if the final data isn't data commands.
> >>>
> >>> This approach eliminates most mapping symbols while ensuring correct
> >>> disassembly. Here is an illustrated assembler example:
> >>>
> >>> .section .text.f0,"ax"
> >>> ret
> >>> // emit $d
> >>> .long 42
> >>> // emit $x. Without this, .text.f1 might be interpreted as data.
> >>
> >> I don't understand this. Whether such a $x would apply to ...
> >>
> >>> .section .text.f1,"ax"
> >>> ret
> >>
> >> ... the section following in source code is entirely unknown until
> >> linking time. And that $x doesn't help ...
> >
> > Thanks for the response!
> >
> > The $x works for the common case where this text section is followed
> > by another text section (instead of data section) that starts with
> > instructions.
>
> Yet then a proposal like this wants to work not just in the common case,
> don't you agree? Unless it was behind a default-off command line option.
>
> Jan
The assembler option --optimize-mapsyms is intended to be default-off.
Users that care about both relocatable file and image file sizes can
use this option when they are certain the scenarios that could lead to
inaccurate state information don't bother them.
Yes, there is a risk, but a significant portion of users don't care.
More information about the Binutils
mailing list