From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id B3D8E3858D28 for ; Mon, 19 Jun 2023 07:14:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B3D8E3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2b4725e9917so14511501fa.2 for ; Mon, 19 Jun 2023 00:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687158892; x=1689750892; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=55zR0gNEx0N4wIbMgkPBPENUFwkEsEJuZ7vSU7qttcc=; b=SMMOye4MakDQ+4P8giq0THsKWOgN3zxzvHP6YmEOyb7gO+x3fjNkBiHk4YYPvlssIQ jPZZFh8pXU4TN8H0GuHMM1Gjo8Vcu1DnMW6ehbEq8/60dKOuTipV6ltRmpBuzWT1/EQY WOoN1dZ2EA7aohFrSWKhIbDYCZdS+acA1tKpwdx0lCBOKfkq3NGm3iohYWk1Bg8WfuKs J3SjddvedFYcW6oX5K8p1SG+Ef4nuw3stzpDqxiKXw1OsDUfCf27oUsX9Wm/FctQK1c8 uYDlE/mPQ2SPH4eLOqisXNNeXQgGLi4LI2UjRTREgNjvCaUMUXgtqdAlz62t/VOsL4NY gCTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687158892; x=1689750892; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=55zR0gNEx0N4wIbMgkPBPENUFwkEsEJuZ7vSU7qttcc=; b=Tf6atWTDmCfrifgsFj7KSus92/s98oX42/eYZcCFnWgzaDw2WSuZdaVt0yxjVoKw3W 7i8TKvtWLhNeMbUBU8YJu6Duw54GESB/syLEIpNSMNV7xlY6qLQTXcMBFVDVnn6uJ6+E fJ2QSrAH4V5PC0cjMzWI4WCYoqonh7oHU07rruueAll9h2bKcD6UfNk0f+PIimrOn0xV 7S+JI+1c5BsDgaLgsrIqow7ijIiJfsIqrDh8yP4aQVZ+CpGKrcuQjSllV2TVQK1EvseR zqwdfb4H2NSKaHH/xfmNoTOTqhixPojZlA0AUvTfxoezZzXds+TLwI3VFwZ1xkAtg18W mPJA== X-Gm-Message-State: AC+VfDyQpZQeYHkv0NyjmeFYHzWt21GSZxLkGq01I3poe7qfFZ+dKQKX LJLqyqm/ChiSAzo73FKypTGYIdUD0kVuDBbK+pZAM8L5/6A2Uw== X-Google-Smtp-Source: ACHHUZ5WDPpAEMqmnONJw9wxBmilKr4JeHb6/ZhecQZqf35dMnk3/7YTaOvGHLIOolwgJhJzqCPvZO+gnqS2Uh1l4TA= X-Received: by 2002:a2e:9918:0:b0:2b4:7dc4:151 with SMTP id v24-20020a2e9918000000b002b47dc40151mr593493lji.27.1687158892245; Mon, 19 Jun 2023 00:14:52 -0700 (PDT) MIME-Version: 1.0 From: Alexandru Onea Date: Mon, 19 Jun 2023 10:14:41 +0300 Message-ID: Subject: arm-none-eabi-as: what decides .text section alignment/padding? To: binutils@sourceware.org Content-Type: multipart/alternative; boundary="00000000000073b92c05fe764aa7" X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,HTML_OBFUSCATE_05_10,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000073b92c05fe764aa7 Content-Type: text/plain; charset="UTF-8" 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? Regards, Alexandru N. Onea --00000000000073b92c05fe764aa7--