Feature request: gas .prefalign directive for body-size-dependent function alignment
Fangrui Song
i@maskray.me
Tue Mar 24 06:26:11 GMT 2026
On Mon, Mar 23, 2026 at 8:35 PM Hans-Peter Nilsson <hp@bitrange.com> wrote:
>
> On Mon, 23 Mar 2026, Fangrui Song wrote:
> > On Mon, Mar 23, 2026 at 12:08?AM Jan Beulich <jbeulich@suse.com> wrote:
> > >
> > > On 21.03.2026 23:09, Fangrui Song wrote:
> > > > On Wed, Mar 11, 2026 at 6:58?PM Fangrui Song <i@maskray.me> wrote:
> > > > .prefalign 4, end, 0001
> > > > .prefalign 4, end, 00010203
> > >
> > > For these last two, how would the parser know how many bytes there are per
> > > padding token? Surely not number of digits in source?
> > >
> > > Jan
> >
> > Intuitively, just count the number of bytes represented by the hex
> > pairs (xxd -p style)...
> >
> > 00 => 1 filler byte. The filler is 000000...
> > 0001 => 2 filler bytes. The filler is 000100010001...
> > 00010203 => 4 filler bytes.
> >
> > The nop keyword means nop filler ("nop" is not matched by [0-9a-fA-F]+).
I have never encountered a use case that requires the fill value to be
an expression (just use the C preprocessor if you have such a use
case!), so I suggested hex pairs...
> Pleeease use regular syntax, not some new special format.
> Like, not:
>
> > > > .prefalign 4, end, 0001
>
> But instead:
> .prefalign 4, end, 2, 1
> same as:
> .prefalign 4, end, 0x2, 0x1
>
> Not:
> > > > .prefalign 4, end, 00010203
>
> But instead:
> .prefalign 4, end, 4, 0x010203
> same as:
> .prefalign 4, end, 0x4, 0x00010203
>
> ...and maybe, if the last operande doesn't parse as a number,
> then try parsing it an instruction.
But if there is a preference for len+fill_value representation, then let's use
.perfalign <log2_align>, <end_sym>, <fill_exp> [, <fill_len>]
.perfalign <log2_align>, <end_sym>, nop
fill_len, if omitted, defaults to 1 to make the common zero-filler
easier to write.
> PS. I use .p2alignw for a conceptually similar effect in the gcc
> CRIS port to handle an errata making sure the multiply insn is
> not the last insn on a cache-line (32 bytes):
>
> ...
> .p2alignw 5,050f,2
> muls.d $r11,$r10
>
> where 0x050f is, as you might guess, a 2-byte nop insn.
>
> brgds, H-P
More information about the Binutils
mailing list