Created attachment 14281 [details]
ltrans assembler listing that exhibits the problem

When LTO is enabled then it's possible for gcc to generate a jump table where the table data is the last thing in its executable section. (i.e. all of the jump table entries point to offsets earlier in the section, and no other instructions appear after it.)

On ARM thumb (min 2 byte instructions), if a jump table with single byte entries has an odd number of entries then the section ends at an odd numbered offset.

If also generating DWARF debug info, it appears the check in gas/dwarf2db.c scale_addr_delta() will then fail with "unaligned opcodes detected in executable segment".

However, the assembly listing is otherwise correct.

I ran across this in the MicroPython project, with a code snippet in objint_mpz.c:315 as follows:

...
        switch (op) {
            case MP_BINARY_OP_LESS:
                return mp_obj_new_bool(cmp < 0);
            case MP_BINARY_OP_MORE:
                return mp_obj_new_bool(cmp > 0);
            case MP_BINARY_OP_LESS_EQUAL:
                return mp_obj_new_bool(cmp <= 0);
            case MP_BINARY_OP_MORE_EQUAL:
                return mp_obj_new_bool(cmp >= 0);
            case MP_BINARY_OP_EQUAL:
                return mp_obj_new_bool(cmp == 0);

            default:
                return MP_OBJ_NULL; // op not supported
        }
    }


With -Os and no LTO, gcc 12.1 generates a jump table, and emits more assembly after it:

...
        .loc 1 315 9 view .LVU1204
        bl      __gnu_thumb1_case_uqi
.L105:
        .byte   (.L109-.L105)/2
        .byte   (.L108-.L105)/2
        .byte   (.L107-.L105)/2
        .byte   (.L106-.L105)/2
        .byte   (.L104-.L105)/2
        .p2align 1
.L109:
        .loc 1 317 17 is_stmt 1 view .LVU1205
.LVL211:
.LBB240:
.LBI237:
        .loc 3 781 24 view .LVU1206
.LBB239:
        .loc 3 782 5 view .LVU1207
        .loc 3 782 30 is_stmt 0 view .LVU1208
        cmp     r3, #0
        blt     .LCB2415
        b       .L70    @long jump
...

With LTO enabled, the local translations further optimise and rearrange until the jump table appears at the end of the executable listing for the enclosing function and section:

...
.LBB303:
	.loc 2 315 9 is_stmt 1 view .LVU1105
	ldr	r2, [sp, #16]
	cmp	r2, #4
	bhi	.L13
	movs	r0, r2
	bl	__gnu_thumb1_case_sqi
.L111:
	.byte	(.L109-.L111)/2
	.byte	(.L108-.L111)/2
	.byte	(.L118-.L111)/2
	.byte	(.L106-.L111)/2
	.byte	(.L104-.L111)/2
.LBE303:
	.cfi_endproc
.LFE0:
        .size   mp_obj_int_binary_op, .-mp_obj_int_binary_op
        .text
.Letext0:
        .file 10 "<built-in>"
        .section        .debug_info,"",%progbits
...

As a result, the executable section ends with an odd length, and linking fails due to the assembler DWARF generation error:

build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.s: Assembler messages:
build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.s: Error: unaligned opcodes detected in executable segment
make[1]: *** [/tmp/ccfzQYxO.mk:3866: build-NUCLEO_F091RC/firmware.elf.ltrans1932.ltrans.o] Error 1

Manually running "arm-none-eabi-as firmware.elf.ltrans1932.ltrans.s" produces the same error, and inserting a padding ".byte 0" in the listing after the jump table will fix the error.

It might be the case that this is gcc's fault for generating an executable section with an odd length, but given the table is the last thing in the section it seems reasonable not to pad it.

Indeed, if "-g" isn't passed to the compiler then the assembler produces valid binary code and everything works, it's only DWARF generation which fails.

I am wondering if a suitable patch would be to ignore this check if there are no additional opcodes following the odd offset, i.e. ignore the failure condition if it's positioned at the end of a section. If so, I'm happy to try and write that patch. However, I'm not very familiar with gas or DWARF so I'm guessing it might be much more complex than this!

Looks like I can only attach one file, so rather than an archive I've attached the ltrans assembler listing which exhibits the issue. If it's helpful then I can provide more example files, or write a simpler assembler listing to reproduce.

Thanks in advance for any insights!