[Bug gas/30851] New: gas arm: Accepts additional operands for `lsr` instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=30851 Bug ID: 30851 Summary: gas arm: Accepts additional operands for `lsr` instruction Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jwlee2217 at softsec dot kaist.ac.kr Target Milestone: --- ``` $ cat examples/bug6_1.s lsr R0, R1, #2, 1 << 4 $ ./arm-linux-gnueabi-as examples/bug6_1.s -o bug6_1.o $ ./arm-linux-gnueabi-objdump -d bug6_1.o bug6_1.o: file format elf32-littlearm Disassembly of section .text: <.text>: 0: e1a00121lsr r0, r1, #2 ``` According to the instruction manual, the `lsr` instruction does not accept four operands. However, it does accept four operands and ignores the last operand. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30850] New: gas arm: Strange behaviors while handling operator `[]`.
https://sourceware.org/bugzilla/show_bug.cgi?id=30850 Bug ID: 30850 Summary: gas arm: Strange behaviors while handling operator `[]`. Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jwlee2217 at softsec dot kaist.ac.kr Target Milestone: --- ``` $ cat examples/bug4_1.s bl [[1]*[[2] ^ 3]] bl ((1)*((2) ^ 3)) $ ./arm-linux-gnueabi-as examples/bug4_1.s -o bug4_1.o $ ./arm-linux-gnueabi-objdump -d bug4_1.o bug4_1.o: file format elf32-littlearm Disassembly of section .text: <.text>: 0: ebfebl 1 <.text+0x1> 4: ebfebl 1 <.text+0x1> ``` It seems that GAS treats brackets ([]) as parentheses (()). Normally, brackets are used to represent memory operands. I wonder if this is the intended behavior of GAS or not. ``` $ cat examples/bug4_2.s bl [R0] $ ./arm-linux-gnueabi-as examples/bug4_2.s -o bug4_2.o $ ./arm-linux-gnueabi-objdump -d bug4_2.o bug4_2.o: file format elf32-littlearm Disassembly of section .text: <.text>: 0: ebfebl 0 $ ./arm-linux-gnueabi-readelf -r bug4_2.o Relocation section '.rel.text' at offset 0xc4 contains 1 entry: Offset InfoTypeSym.Value Sym. Name 061c R_ARM_CALL R0 ``` Another (relevant) doubtful behavior of GAS is if we give a memory operand to `bl` instruction then GAS ignores the bracket and generates a symbol for R0. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30849] New: gas x86-64: Operand size prefix incorrectly parsed as operand in `prefetch` Instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=30849 Bug ID: 30849 Summary: gas x86-64: Operand size prefix incorrectly parsed as operand in `prefetch` Instruction Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jwlee2217 at softsec dot kaist.ac.kr Target Milestone: --- ``` $ cat examples/bug3_1.s .intel_syntax noprefix prefetch WORD PTR [R11] $ ./as examples/bug3_1.s -o bug3_1.o $ ./objdump -d -M intel bug3_1.o bug3_1.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 41 0f 0d 03 prefetch BYTE PTR [r11] ``` It seems GAS ignores memory operand prefixes for Intel `prefetch` instruction. I guess this behavior is because `prefetch` only accepts an 8-bit width memory operand. ``` $ cat examples/bug3_2.s .intel_syntax noprefix prefetch DUMMYDUMMYDUMMY [R11] prefetch [R11] [R11] $ ./as examples/bug3_2.s -o bug3_2.o $ ./objdump -d -M intel bug3_2.o bug3_2.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 41 0f 0d 83 00 00 00prefetch BYTE PTR [r11+0x0] 7: 00 8: 43 0f 0d 04 1b prefetch BYTE PTR [r11+r11*1] $ ./readelf -r bug3_2.o Relocation section '.rela.text' at offset 0xc8 contains 1 entry: Offset Info Type Sym. ValueSym. Name + Addend 0004 0001000b R_X86_64_32S DUMMYDUMMYDUMMY + 0 ``` More interesting behaviors can be observed when we give an arbitrary token instead of a memory operand prefix. If we put a symbol or an additional memory operand, then two memory operands are treated as a single memory operand. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30848] New: gas x86-64: Internal error occurs while handling `bnd`
https://sourceware.org/bugzilla/show_bug.cgi?id=30848 Bug ID: 30848 Summary: gas x86-64: Internal error occurs while handling `bnd` Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jwlee2217 at softsec dot kaist.ac.kr Target Milestone: --- ``` $ cat examples/bug1_1.s .intel_syntax noprefix bnd andn R11, R12, R13 $ ./as examples/bug1_1.s examples/bug1_1.s: Assembler messages: examples/bug1_1.s:2: Error: expecting valid branch instruction after `bnd' examples/bug1_1.s:2: Internal error in output_insn at config/tc-i386.c:9795. Please report this bug. ``` When the bnd prefix is used with non-control-flow instructions, the internal error shown in the example occurs. We can also observe this exception with other instructions, for example, `bnd vxorps xmm0, xmm0, [r13]`. However, not all instructions cause the error. For example, GAS rejects `bnd xor rax, rbx`, without any internal errors. Note that this issue is not intel syntax-specific. This bug can be reproduced using the binutils version 2.41. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #4 from Nelson Chu --- > The --emit-relocs should switch to preserve the original > relocation type, including R_RISCV_CALL_PLT(etc), > R_RISCV_RELAX, and R_RISCV_ALIGN. Looks reasonable, so based on this rule when setting --emit-reloc, 1. R_RISCV_CALL_PLT auipc, [R_RISCV_CALL_PLT][R_RISCV_RELAX] jalr (relax and emit to) -> jal, [R_RISCV_CALL_PLT][R_RISCV_RELAX] 2. R_RISCV_ALIGN .align 3, 6 nops under rvc, [R_RISCV_ALIGN] with addend 6 -> less then 6 nops (may be 0), [R_RISCV_ALIGN] with addend 6 or less? 3. R_RISCV_HI20/LO12 Even not all people like gp relaxation, we still need a rule in GNU ld for --emit-reloc. lui, [R_RISCV_HI20][R_RISCV_RELAX] addi, [R_RISCV_LO12][R_RISCV_RELAX] -> add with gp, [R_RISCV_HI20][R_RISCV_RELAX][R_RISCV_LO12][R_RISCV_RELAX], four relocs point to same instruction? 4, R_RISCV_PCREL_HI20/PCREL_LO12 Likewise, all the four relocs point to the same pcrel_lo instruction. 5. R_RISCV_GOT_HI20/PCREL_LO12 Likewise. 6. ... future relaxations, TLS, ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30840] libiberty build produces errors with CC=clang, unsupported option '-print-multi-os-directory'
https://sourceware.org/bugzilla/show_bug.cgi?id=30840 Andreas K. Huettel changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111406 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #3 from Palmer Dabbelt --- (In reply to Fangrui Song from comment #2) > (In reply to Palmer Dabbelt from comment #1) > > Nelson and I are just chatting about this. It's not intentional, but we > > also don't quite know what the right answer is here: there's some relocs we > > can touch less (like leaving R_RISCV_ALIGN in outputs even after we've > > aligned, for example) but others we'd have to avoid relaxing (like > > R_RISCV_CALL, which requires two instructions). Certainly producing > > binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't > > be producing binaries with it. > > > > So I think we're happy to fix bugs here, but we really need to know what the > > desired output is. > > > > Do you have something more concrete about what you're looking for? > > Thanks for looking into this. My feeling is that --emit-relocs should switch > to preserve the original relocation type, including R_RISCV_CALL_PLT(etc), > R_RISCV_RELAX, and R_RISCV_ALIGN. So we leave the R_RISCV_ALIGN in there and delete the excess bytes until it's aligned? That will result in a subtly different meaning for the output binary, as the alignment will be smaller. Maybe that's fine as the actual target will already be aligned to the originally correct amount, but if something's trying to then do more relaxation after we might have subtle issues. > Analysis tools can check whether R_RISCV_RELAX is present in a section. If > present, they need to do disassembly work to figure out whether a > R_RISCV_CALL_PLT relocations is associated with an un-relaxed code sequence > of a relaxed code sequence. Yes, it may look dirty but I don't think there > is a better way. (x86-32 relocation handling inspects the relocated > relocation as well) Ya, that's ugly -- but if it's the way it's done then maybe that's just the only answer. We could add some sort of R_RISCV_CALL_SHORT type relocation so we can emit a correct relocation for relaxed calls without relying on disassembly hueristics. We could also just stop relaxing calls under --emit-relocs, then we get a correct output binary with the long calls. > FWIW I left a comment on > https://lore.kernel.org/linux-riscv/2023091221.zejmknzcm5mwzzcz@google. > com/T/#t on the only --emit-relocs use I can find, which is relatively new > in the Linux kernel. Thanks, Alex just pointed Nelson and I at it as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30840] libiberty build produces errors with CC=clang, unsupported option '-print-multi-os-directory'
https://sourceware.org/bugzilla/show_bug.cgi?id=30840 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |MOVED --- Comment #1 from Nick Clifton --- Hi Andreas, The libiberty library is maintained by the GCC project not us. (We just make use of it). So please could you refile this bug report here: https://gcc.gnu.org/bugzilla/enter_bug.cgi Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 --- Comment #15 from Nick Clifton --- I should note however that we do not normally make further releases from a branch unless there is an important bug that needs to be fixed. Given that it is possible to work around this build problem, I would not say that it qualifies as being important enough to warrant a 2.41.1 release. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 --- Comment #14 from Nick Clifton --- (In reply to Tom Tromey from comment #12) > (In reply to vvinayag from comment #11) > > (In reply to Tom Tromey from comment #10) > > > I backed out the offending patch. > > > > Is it possible to backport the revert to binutils-2_41-branch? We are using > > binutils-2_41-branch, and it is not building for the reasons mentioned > > above. > > I don't know binutils policy about this, but if it is OK, I can > do the work if needed. [Sorry - not paying attention here]. The policy is that it is OK to backport patches to the branch once a release has been made. Hence it is totally OK for you to go ahead and backport your patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #2 from Fangrui Song --- (In reply to Palmer Dabbelt from comment #1) > Nelson and I are just chatting about this. It's not intentional, but we > also don't quite know what the right answer is here: there's some relocs we > can touch less (like leaving R_RISCV_ALIGN in outputs even after we've > aligned, for example) but others we'd have to avoid relaxing (like > R_RISCV_CALL, which requires two instructions). Certainly producing > binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't > be producing binaries with it. > > So I think we're happy to fix bugs here, but we really need to know what the > desired output is. > > Do you have something more concrete about what you're looking for? Thanks for looking into this. My feeling is that --emit-relocs should switch to preserve the original relocation type, including R_RISCV_CALL_PLT(etc), R_RISCV_RELAX, and R_RISCV_ALIGN. Analysis tools can check whether R_RISCV_RELAX is present in a section. If present, they need to do disassembly work to figure out whether a R_RISCV_CALL_PLT relocations is associated with an un-relaxed code sequence of a relaxed code sequence. Yes, it may look dirty but I don't think there is a better way. (x86-32 relocation handling inspects the relocated relocation as well) FWIW I left a comment on https://lore.kernel.org/linux-riscv/2023091221.zejmknzcm5mwz...@google.com/T/#t on the only --emit-relocs use I can find, which is relatively new in the Linux kernel. -- You are receiving this mail because: You are on the CC list for the bug.
