I added -g option in aarch64-none-elf-as command to compile a file vector.s. This file is the exception vector for arm64 machine (see Table 4 in ). Before the -g option, there was no problem, but with -g option, I see this error message:

aarch64/shared/vectors.s: Error: unaligned opcodes detected in executable segment

The whole vector table should be aligned by 0x800 and each entry should be aligned by 0x80 by the aarch64 architecture. And I don't think the debug information is inserted in the code area (by the way, the code sits in the section "vectors").
I tried to see what instructions are misaligned by this -g option and checked the assembler's options by aarch-none-elf-as --help but couldn't find any option that's likely to show this misalignment information. Is there any option that prints the addresses of instruction? (Because it errors out during the assembly, I cannot see the final map file or do objdump for the generated binary file.)
aarch64-none-elf-as --version shows

GNU assembler (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14)) 2.37.20220122

ADD : I made a reproducible simplest example from this. The reduced vectors.s file is like this. (only two vector entries).

        .section vectors, "ax", %progbits
        .global  vector_table

        .balign 0x800
vector_table:
curr_el_sp0_sync:
        b       curr_el_sp0_sync_vector
        adr     x0, 1f
        bl      print
        b       terminate
1:      .asciz "Unexpected exception: curr_el_sp0_sync\n"

        .balign 0x80
curr_el_sp0_irq:
        b       curr_el_sp0_irq_vector
        adr     x0, 1f
        bl      print
        b       terminate
1:      .asciz "Unexpected exception: curr_el_sp0_irq\n"

        .balign 0x80
print:
        ret
terminate:
        ret
        .balign 0x4
fail_str:       .asciz "** TEST FAILED**\n\004"
        .end

The command for assembling this file is like this (without -g option) and it assembles the code ok(produces vectors.o).

aarch64-none-elf-as -march=armv8.4-a+crc aarch64/shared/vectors.s -o aarch64/shared/vectors.o

The command with -g optino is like this (produces forementioned error).

aarch64-none-elf-as -march=armv8.4-a+crc aarch64/shared/vectors.s -g -o aarch64/shared/vectors.o

I added -g option in aarch64-none-elf-as command to compile a file vector.s. This file is the exception vector for arm64 machine (see Table 4 in https://developer.arm.com/documentation/102412/0103/Handling-exceptions/Taking-an-exception ). Before the -g option, there was no problem, but with -g option, I see this error message:

aarch64/shared/vectors.s: Error: unaligned opcodes detected in executable segment

The whole vector table should be aligned by 0x800 and each entry should be aligned by 0x80 by the aarch64 architecture. And I don't think the debug information is inserted in the code area (by the way, the code sits in the section "vectors").
I tried to see what instructions are misaligned by this -g option and checked the assembler's options by aarch-none-elf-as --help but couldn't find any option that's likely to show this misalignment information. Is there any option that prints the addresses of instruction? (Because it errors out during the assembly, I cannot see the final map file or do objdump for the generated binary file.)
aarch64-none-elf-as --version shows

GNU assembler (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14)) 2.37.20220122

ADD : I made a reproducible simplest example from this. The reduced vectors.s file is like this. (only two vector entries).

        .section vectors, "ax", %progbits
        .global  vector_table

        .balign 0x800
vector_table:
curr_el_sp0_sync:
        b       curr_el_sp0_sync_vector
        adr     x0, 1f
        bl      print
        b       terminate
1:      .asciz "Unexpected exception: curr_el_sp0_sync\n"

        .balign 0x80
curr_el_sp0_irq:
        b       curr_el_sp0_irq_vector
        adr     x0, 1f
        bl      print
        b       terminate
1:      .asciz "Unexpected exception: curr_el_sp0_irq\n"

        .balign 0x80
print:
        ret
terminate:
        ret
        .balign 0x4
fail_str:       .asciz "** TEST FAILED**\n\004"
        .end

The command for assembling this file is like this (without -g option) and it assembles the code ok(produces vectors.o).

aarch64-none-elf-as -march=armv8.4-a+crc aarch64/shared/vectors.s -o aarch64/shared/vectors.o

The command with -g optino is like this (produces forementioned error).

aarch64-none-elf-as -march=armv8.4-a+crc aarch64/shared/vectors.s -g -o aarch64/shared/vectors.o

• assembly
• arm
• domain-driven-design
• arm64

• 2 I think you need to add more context. What system is this? Can you use something like make V=1 to see the command line to the assembler. It may simply be that you have called the wrong assembler. At least we don't know. I can not see code in the link provided. A minimal sample on godbolt would easily allow anyone to answer. – artless-noise-bye-due2AI Commented Feb 7 at 15:11
• 1 Please provide your code or a minimal reproducible example to make this question answeable. – fuz Commented Feb 7 at 16:59
• -g does not misalign anything, it's just a side effect that during debug info generation the misalignment is detected. It is likely still there in the non-debug version. Also note there is -Z option to get an object file but as I said, I doubt that would help you because it should be the same as without -g. What could help you is debugging or patching gas. Or posting a minimal reproducible example :) – Jester Commented Feb 7 at 18:10
• You could see if the assembler is able to create a listing file (aarch-none-elf-as -a). – Nate Eldredge Commented Feb 8 at 1:42
• 2 I try the same with aarch64-linux-gnu-as -march=armv8.4-a+crc test.s -o test.o and no issue with -g. Using Ubuntu-24.04 binutils gas. There is no issue. -Z is useful and -mverbose-error. Where did aarch64-none-elf-as come from? – artless-noise-bye-due2AI Commented Feb 8 at 16:45

1 Answer 1

I found if I insert

.balign 0x80

before the last

.end  

line, the error goes out. Probably the debug information had been inserted right after the code area and messed something up. So I'm making the debug information start in an aligned boundary.(??) And this works for original non-simplified code and now I can debug step-by-step through the assembly code!