Therefore, is it that the only difference between the two cases shown in my example boils down to whether the assembler sees an instruction or not? I understand it as follows: Case A: .text section with no instruction within, the assembler says "this monkey asks me to put data in a .text section, whatever, maybe where he comes from .text means something else" Case B: .text section with data and at least one instruction, the assembler says "this monkey now crosses the line, if he wants instructions, I must make sure that at least other .text sections can be merged into it" So does the assembler assume that if there are no instructions in a .text section, maybe it is not actually a .text section in the classical sense? Best regards, Alexandru N. Onea On Mon, 19 Jun 2023 at 16:31, Richard Earnshaw (lists) < Richard.Earnshaw@arm.com> wrote: > On 19/06/2023 08:14, Alexandru Onea via Binutils wrote: > > Hello, community! > > > > I am playing with arm-none-eabi-as trying to understand how it aligns > > sections. I have the following source: > > > > ; source.s > > .text > > .byte 0xff > > .byte 0xff > > .byte 0xff > > > > I am inspecting the resulting object file: > > > > $ arm-none-eabi-as -mthumb -o source.o source.s > > $ arm-none-eabi-readelf -S source.o > > There are 8 section headers, starting at offset 0xec: > > > > Section Headers: > > [Nr] Name Type Addr Off Size ES Flg > Lk Inf Al > > [ 0] NULL 00000000 000000 000000 00 > > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > > 000003 00 AX 0 0 1 > > * [ 2] .data PROGBITS 00000000 000037 000000 00 > > WA 0 0 1 > > [ 3] .bss NOBITS 00000000 000037 000000 00 WA > 0 0 1 > > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 > 0 0 1 > > [ 5] .symtab SYMTAB 00000000 00004c 000060 10 > 6 6 4 > > [ 6] .strtab STRTAB 00000000 0000ac 000004 00 > 0 0 1 > > [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 > 0 0 1 > > > > The .text section is byte-aligned and contains the 3 bytes. > > > > Now, I add an instruction to source.s: > > > > ; source.s > > .text > > .byte 0xff > > nop > > .byte 0xff > > .byte 0xff > > > > Looking into the object file, now all of a sudden the .text section is > > halfword-aligned: > > > > There are 8 section headers, starting at offset 0x114: > > > > Section Headers: > > [Nr] Name Type Addr Off Size ES Flg > Lk Inf Al > > [ 0] NULL 00000000 000000 000000 00 > > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > > 000006 00 AX 0 0 2 > > * [ 2] .data PROGBITS 00000000 00003a 000000 00 > > WA 0 0 1 > > [ 3] .bss NOBITS 00000000 00003a 000000 00 WA > 0 0 1 > > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 > 0 0 1 > > [ 5] .symtab SYMTAB 00000000 000050 000080 10 > 6 8 4 > > [ 6] .strtab STRTAB 00000000 0000d0 000007 00 > 0 0 1 > > [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 > 0 0 1 > > > > What is causing the assembler to decide to pad the section in the second > > case? I am confused because: > > > > 1. if the section is .data then the assembler will not pad it anyway, > > which makes sense, but > > 2. even if the section is .text, the assembler won't pad it unless it > > sees an instruction (I can have as many data directives, the section > won't > > be padded without having also an instruction), and finally > > 3. the nop instruction is definitely not aligned and the assembler > has > > no problem with it, but it still decides to care about section > alignment. > > > > How is the assembler deciding here to align and pad the section? Can I > > force the assembler to not pad the .text section even if I have an > > instruction? > > You've told the assembler to interpret the contents of the source file > as containing thumb instructions. Thumb instructions must be (at least) > two byte aligned (the fact that your source file deliberately misaligns > the instruction is a bug in your code). If the section were not aligned > then the linker would not be able to correctly merge consecutive > sections if you had a mix of data-only text sections (like your first > example) and sections containing code. > > Note that if you had used -marm instead of -mthumb the alignment would > be set to 4 as all 'arm' instructions must be 4-byte aligned. > > R. > >