[Binutils] Generate invalid zero words in function #41
Comments
|
I cannot reproduce it. Note that AOSC is applying a bunch of patches onto GCC 13 (and maybe Binutils, I've not checked their Binutils repo). With vanilla GCC 13.2.0 and With vanilla GCC 13.2.0 and With GCC 14 (r14-8422 + some patches I've mentioned at loongson-community/areweloongyet#16 (comment)): Is there an assembly output from AOSC GCC? |
|
Cannot reproduce with almost-up-to-date snapshot of gcc and binutils-2.42 on Gentoo: |
|
Assembly and compiled object can be found at test.tar.gz Assembly of test: $ objdump -dwr test.o
000000000000006c <test>:
6c: 02ffc063 addi.d $sp, $sp, -16
70: 29c02061 st.d $ra, $sp, 8
0000000000000074 <L0^A>:
74: 44000c80 bnez $a0, 12 # 80 <.L5> 74: R_LARCH_B21 .L5
78: 60002005 bgtz $a1, 32 # 98 <L0^A> 78: R_LARCH_B16 .L13
7c: 00000000 .word 0x00000000
0000000000000080 <.L5>:
80: 1a000004 pcalau12i $a0, 0 80: R_LARCH_PCALA_HI20 .LC2
80: R_LARCH_RELAX *ABS*
84: 02c00084 addi.d $a0, $a0, 0 84: R_LARCH_PCALA_LO12 .LC2
84: R_LARCH_RELAX *ABS*
88: 54000000 bl 0 # 88 <.L5+0x8> 88: R_LARCH_B26 puts
8c: 28c02061 ld.d $ra, $sp, 8
0000000000000090 <L0^A>:
90: 02c04063 addi.d $sp, $sp, 16
0000000000000094 <L0^A>:
94: 50000000 b 0 # 94 <L0^A> 94: R_LARCH_B26 d
0000000000000098 <L0^A>:
98: 54000000 bl 0 # 98 <L0^A> 98: R_LARCH_B26 c
9c: 1a000004 pcalau12i $a0, 0 9c: R_LARCH_PCALA_HI20 .LC2
9c: R_LARCH_RELAX *ABS*
a0: 02c00084 addi.d $a0, $a0, 0 a0: R_LARCH_PCALA_LO12 .LC2
a0: R_LARCH_RELAX *ABS*
a4: 54000000 bl 0 # a4 <L0^A+0xc> a4: R_LARCH_B26 puts
a8: 28c02061 ld.d $ra, $sp, 8
00000000000000ac <L0^A>:
ac: 02c04063 addi.d $sp, $sp, 16
b0: 50000000 b 0 # b0 <L0^A+0x4> b0: R_LARCH_B26 d |
|
The problem still persists using binutils master (commit 44c91f530fc9acc3a535953696d49633e5a7e24a) |
|
Minimal reproducer: .section .text,"ax",@progbits
.align 2
.align 5
.globl a
.type a, @function
a:
.align 4,54525952,4 |
|
I see: in binutils 2.42, for if (arg >= 0)
fill_len = 1;
else
fill_len = -arg;
if (fill_len <= 1)
{
char fill_char = 0;
fill_char = fill;
do_align (align, &fill_char, fill_len, max);
}However, in binutils 2.41, The number was written by gcc, see gcc-mirror/gcc@b20c7ee. |
|
So the answer is: binutils 2.42 assumes gcc with gcc-mirror/gcc@b20c7ee applied. |
|
So it now seems making sense to backport b20c7ee066cb7d952fa193972e8bc6362c6e4063 to GCC 12 and 13. And still Binutils should reject |
Seems fine to me.
Given the form of the now-problematic |
We may special case the 2nd operand of .align and handle it properly if it's the NOP encoding. But why not just support 3-operand .align unconditionally (with any 2nd operand)? I don't think it's always nonsense if the user wants to fill the alignment padding with a different instruction: at least a different "do nothing" instruction like And for things like However doing that will need a revision of ABI. Current (2.30) wording indeed only allows NOP:
|
Aww. Indeed this would need attention from the Loongson teams if such an improvement is to be made; but in order to additionally stuff a 4-byte second expression into the reloc addend, the expressible range of the third expression must be reduced. I don't think this would create any serious problem though, because I expect large "maximum skip"'s (larger than e.g. 16 bits) to be practically non-existent. (See GAS doc on |
|
Given we're little-endian throughout, if we just assume that very large maximum-skip values do not exist, the following change would be backwards-compatible (read: no real-world breakage expected): -The lowest 8 bits are used to represent the first expression, other bits are used to represent the third expression.
+The lowest 8 bits are used to represent the first expression, the bits 8 to 31 inclusive the third expression, and the higher 32 bits the second expression.
+ If the bitfield for the second expression reads as zero, it is to be treated as a NOP (0x03400000).This is all assuming ELF64. |
|
No, op2 is not needed to be encoded in the reloc. The instructions are already in the binary section and R_LARCH_ALIGN just delete some (or all) of them. We just need to make the assembler stuff |
|
GCC change backporting proposal: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html |
Compile and link the following code:
Using binutils 2.42 and gcc 13.2.0 from AOSC OS:
gcc -O2 test.c -o testGenerates invalid
0x00000000instruction intest:Which can lead to SIGILL:
$ ./test 0 0 fish: Job 1, './test' terminated by signal SIGILL (Illegal instruction)CC @xry111
The text was updated successfully, but these errors were encountered: