Each label address used, adds 24 bytes more (plus 8 bytes (totalling 32 bytes)) to the .o file'-CodePudding

In my FASM project (Object), I'm trying to create a jump-table and I use dq for each jump address but there is a problem!
For each dq .jmp1 (jump address definition), 24 bytes more (plus 8 bytes for .jmp1 address (totalling 32 bytes)) will be added to my final .o file's total size!
What is that extra 24 bytes? Is there any way to avoid it? This happens only in object file, not in executable!

Instead of 8 bytes for each jump address, it defines 32 bytes! What is the problem?

format ELF64

section '.text'

func:
        lea     rax, [8*rax .jmp_table]

 .jmp1:

 .jmp_table:
        dq .jmp1 ; 8 bytes   24 bytes !!! (to .o total size)
        dq .jmp1 ; 8 bytes   24 bytes !!! (to .o total size)

But when I create an executable, each dq takes only 8 bytes (what I expect) ...

format ELF64 EXECUTABLE

segment readable executable

func:
        lea     rax, [8*rax .jmp_table]

 .jmp1:

 .jmp_table:
        dq .jmp1 ; 8-BYTE, no extra 24 bytes to .o total size
        dq .jmp1 ; 8-BYTE, no extra 24 bytes to .o total size

CodePudding user response：

Remember that a .o file is not just a flat image of the code and data you assembled; it also contains metadata, such as relocations.

Since dq .jmp1 references a symbol whose absolute address will not be known until after linking, it requires a relocation entry. The link above shows that ELF on x86-64 uses Elf64_Rela relocation entries, which are 24 bytes. So the 8 bytes of actual data, plus 24 bytes of metadata, accounts exactly for the 32-byte increase in file size. (It could be more or less in other instances, e.g. perhaps due to padding for alignment requirements.)

Once linking is complete, the relocation metadata is not included in the executable, so the executable size increased only by the size of the actual data.

So what you're seeing is completely normal and there is nothing to avoid. The jump table entries will in fact occupy 8 bytes in program memory, and the arithmetic of your lea rax, [8*rax .jmp_table] remains correct.