[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Cary Coutant --- Fixed on trunk. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c83344582375e65643c5efe68b3739e87db482f3 commit c83344582375e65643c5efe68b3739e87db482f3 Author: Cary Coutant Date: Fri Feb 2 17:44:27 2018 -0800 Add support for DWARF-4 line number tables. Reads the maximum_operations_per_instruction field, added in DWARF-4 to the line number program header. gold/ * PR gold/22776 * dwarf_reader.cc (Sized_dwarf_line_info::read_header_prolog): Add support for DWARF-4 line number tables. * dwarf_reader.h (Sized_dwarf_line_info::max_ops_per_insn): New field. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22755] gold test suite failures (gentoo, 2.30)
https://sourceware.org/bugzilla/show_bug.cgi?id=22755 Cary Coutant changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-03 Ever confirmed|0 |1 --- Comment #1 from Cary Coutant --- Can you please attach your copy of gold/config.log? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20402] ld.bfd for emits *_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7 from Alan Modra ---
I'll note that many of the generic linker issues that prevent this bug being
fixed have already been solved, and many targets no longer make symbols like
_DYNAMIC absolute.
So for example, a user script that does something like
.text : { }
my_end_text = .;
will define my_end_text as a section relative symbol rather than absolute as
older linkers did, which is likely what most users want. Users who really do
want absolute symbols defined from dot now need to write
my_end_text = ABSOLUTE (.);
Even so, there will no doubt be projects that break..
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Cary Coutant --- Unfortunately, gold was never taught to read DWARF-4 line number tables, because GCC and gas still always use version 2. Here's what's happening: (1) When reading the line number program header, gold doesn't read the "maximum operations per instruction" field, and instead reads that field as "default is_stmt". (2) The remaining fields of the header are also read offset by one byte, including the standard opcode lengths array, the include directories list, and the file names list. (3) It starts reading the line number program correctly, because it uses the prologue length field from the header to find the beginning. (4) Later, when reading the line number program, when it sees an opcode it doesn't care about (namely, set_prologue_end), it gets a bogus value from the standard opcode lengths table, and skips an LEB128 that really isn't part of that opcode. (5) That screws up the reading of subsequent opcodes, and it reads a data field as if it were an opcode, setting a bogus file number which gets saved as part of a line number table row. (6) Later, when looking up an address, it tries to translate the bogus file number to a file name, and hits the assertion. (Which really shouldn't be an assertion, because this can be caused by bogus input rather than a bug in gold, even though it's really a bug here.) The fix here is to check the line table version number, and read the extra field that was added in DWARF version 4. Since gold doesn't support Itanium (yet), I'll probably just error out if that field is anything other than 1. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 --- Comment #6 from H.J. Lu --- Works with ld. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from H.J. Lu --- Confirmed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 --- Comment #4 from Evgeny Stupachenko --- (In reply to H.J. Lu from comment #2) > Do you have a testcase in C/C++ with clang? Yes. clang test_bad.c -g -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 --- Comment #3 from Evgeny Stupachenko --- Created attachment 10779 --> https://sourceware.org/bugzilla/attachment.cgi?id=10779&action=edit c test reproducer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #10 from Ard Biesheuvel --- (In reply to Renlin Li from comment #9) > (In reply to Peter Smith from comment #5) > > I think that the new error message for R_AARCH64_ABS32 from the linker makes > > some sense if the destination symbol is section relative as there is no > > dynamic relocation supported and truncating a 64-bit address is most likely > > a mistake. > > > > However if the destination symbol is absolute the linker shouldn't make the > > assumption that the symbol is an address so it should resolve the relocation > > at static link-time. > > > > I think the test: > > case BFD_RELOC_AARCH64_16: > > #if ARCH_SIZE == 64 > > case BFD_RELOC_AARCH64_32: > > #endif > > if (bfd_link_pic (info) > > && (sec->flags & SEC_ALLOC) != 0 > > && (sec->flags & SEC_READONLY) != 0) > > ... Give error message > > Should check that the symbol is not absolute as well. > > > > Unfortunately I can't think of a workaround for the case where the value of > > the symbols has to be in the RO-segment. For some reason the check only > > applies in RO sections, which does not make a lot of sense to me as a > > R_AARCH64_ABS32 from a RW section to an address will truncate it in the same > > way as if it were from a RO section. No dynamic relocation is generated for > > either RO or RW so I don't know why the distinction has been made. > > Indeed, for a absolute symbol, the assumption that it represents an address > is not correct. > A check should be added to allow absolute symbol with R_AARCH64_ABS > relocation. > > The condition here is to apply the constrain only in allocatable text or > read-only data section, where I though is more likely to be a place to store > fixed address. > > I will prepare a patch, trying to fix the absolute symbol case. Thank you Renlin. May I kindly suggest that you also look at the other issue, which is related? https://sourceware.org/bugzilla/show_bug.cgi?id=20402 In that case, a runtime relocation is emitted even for SHN_ABS symbols, which means the resulting value becomes dependent on the load address. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-02 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- Do you have a testcase in C/C++ with clang? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22756] Linker relaxation miscalculates symbol addresses on riscv
https://sourceware.org/bugzilla/show_bug.cgi?id=22756 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jim Wilson : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7f02625eb48105e100d2da58091d56978ed041ef commit 7f02625eb48105e100d2da58091d56978ed041ef Author: Jim Wilson Date: Fri Feb 2 12:43:09 2018 -0800 RISC-V: Fix --wrap and relaxation conflict. bfd/ PR ld/22756 * elfnn-riscv.c (riscv_relax_delete_bytes): New parameter link_info. If link_info->wrap_hash, check for a duplicate symbol and ignore. (_bfd_riscv_relax_call, bfd_riscv_relax_lui, _bfd_riscv_relax_tls_le): Pass new argument to riscv_relax_delete_bytes. (_bfd_riscv_relax_align, _bfd_riscv_relax_delete): Likewise. Remove ATTRIBUTE_UNUSED from link_info parameter. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 --- Comment #1 from Evgeny Stupachenko --- Created attachment 10778 --> https://sourceware.org/bugzilla/attachment.cgi?id=10778&action=edit good (without internal error) only 2 bytes difference from bad -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22776] New: internal error in dwarf_reader.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=22776 Bug ID: 22776 Summary: internal error in dwarf_reader.cc Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: evstupac at gmail dot com CC: ian at airs dot com Target Milestone: --- Created attachment 10777 --> https://sourceware.org/bugzilla/attachment.cgi?id=10777&action=edit bad (causing internal error) object file To reproduce: ld.gold test_bad.o /usr/lib64/libc.so.6 ld.gold: internal error in format_file_lineno, at ../../binutils-2.29/gold/dwarf_reader.cc:2249 libc I use: 2.7 compiled by GNU CC version 4.8.5 20150623 (Red Hat 4.8.5-16) on a Linux 3.10.0 system on 2017-06-16 The error was triggered by switching dwarf version from 2 to 4 in llvm compiler (svn r319699 or git a61e335ed0ae118bf3ce579c9b33ea277463bff0). Attached good and bad object files (for Linux) and corresponding readelf. There is only 2 bytes difference between .debug_line sections there. The one that triggers linker internal error is: 0406 instead of 0306 gold linker reads first symbol (04 in bad case) as elfcpp::DW_LNS_set_file (dwarf_reader.cc line 1819) and as elfcpp::DW_LNS_advance_line in good case (03). The debug information is only for 5 files in the test. An attempt to access 6th file causes internal error. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22756] Linker relaxation miscalculates symbol addresses on riscv
https://sourceware.org/bugzilla/show_bug.cgi?id=22756 Jim Wilson changed: What|Removed |Added Assignee|unassigned at sourceware dot org |wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- The problem is with testglue.o, which has both a definition of __wrap_exit, and an undefined reference to exit. With the --wrap option, the later gets renamed to __wrap_exit, and we now have two references to the same symbol in the symbol table, which violates assumptions in the riscv port. Looking at other ports, I see that 3 of them have a solution for this, to check for duplicate symbols and ignore them. The solution is O(N^2) but we only need it when --wrap is used, so perhaps it is OK. I do prefer to use code which is already used in other ports. Although looking closer at the code to support deleting bytes during relaxation, it looks like every port is broken in at least one way. Here is my unverified list: no wrap symbol support and no symbol size support elfxx-mips.c elf32-h8300.c elf32-ip2k.c elf32-m68hc11.c elf32-sh.c no wrap symbol support elfnn-riscv.c elf32-m32c.c elf32-microblaze.c elf32-msp430.c elf32-nds32.c elf32-pru.c elf32-rl78.c elf32-rx.c elf32-v850.c O(N^2) solution to wrap symbols, but no symbol size support elf32-cr16.c elf32-crx.c elf32-ft32.c Maybe worth a meta bug to track? Anyways, I have a patch for elfnn-riscv.c based on the elf32-crx.c support, and will commit soon. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #9 from Renlin Li --- (In reply to Peter Smith from comment #5) > I think that the new error message for R_AARCH64_ABS32 from the linker makes > some sense if the destination symbol is section relative as there is no > dynamic relocation supported and truncating a 64-bit address is most likely > a mistake. > > However if the destination symbol is absolute the linker shouldn't make the > assumption that the symbol is an address so it should resolve the relocation > at static link-time. > > I think the test: > case BFD_RELOC_AARCH64_16: > #if ARCH_SIZE == 64 > case BFD_RELOC_AARCH64_32: > #endif > if (bfd_link_pic (info) > && (sec->flags & SEC_ALLOC) != 0 > && (sec->flags & SEC_READONLY) != 0) > ... Give error message > Should check that the symbol is not absolute as well. > > Unfortunately I can't think of a workaround for the case where the value of > the symbols has to be in the RO-segment. For some reason the check only > applies in RO sections, which does not make a lot of sense to me as a > R_AARCH64_ABS32 from a RW section to an address will truncate it in the same > way as if it were from a RO section. No dynamic relocation is generated for > either RO or RW so I don't know why the distinction has been made. Indeed, for a absolute symbol, the assumption that it represents an address is not correct. A check should be added to allow absolute symbol with R_AARCH64_ABS relocation. The condition here is to apply the constrain only in allocatable text or read-only data section, where I though is more likely to be a place to store fixed address. I will prepare a patch, trying to fix the absolute symbol case. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703
--- Comment #12 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Maciej W. Rozycki :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e54d3c943bb3999aeaf1667b4975dc035f7b554c
commit e54d3c943bb3999aeaf1667b4975dc035f7b554c
Author: Maciej W. Rozycki
Date: Fri Feb 2 18:08:04 2018 +
LD/testsuite: Pass $AFLAGS_PIC to GAS for PIC assembly
Add $AFLAGS_PIC flags for PIC assembly to a number of tests missing them
and remove `tic6x-*-*' XFAIL annotations from them, previously added to
paper over:
.../ld-new: warning: generating a shared library containing non-PID code
error messages produced due to `-mpic -mpid=near' GAS options having not
been used. Such errors now do not happen anymore, removing:
XFAIL: Build shared library for pr14170
XFAIL: PR ld/21703 shared
XFAIL: Build shared library for broken linker script test
XFAIL: Build pr17068.so
XFAIL: -Bsymbolic-functions
XFAIL: Build pr20995.so
XFAIL: Build pr22374 shared library
with `tic6x-elf' and `tic6x-uclinux' targets. These tests now pass all
except for:
FAIL: PR ld/21703 shared
which is now due to a different reason, as follows:
extra regexps in .../ld/testsuite/ld-elf/pr21703-shared.sd starting with
"^Symbol table '\.dynsym' contains [0-9]+ entries:$"
EOF from dump.out
FAIL: PR ld/21703 shared
The addition of $AFLAGS_PIC requires the affected test cases to use the
`list' command rather than `{}' characters to create a list, to avoid
the quoting property `{}' also have in TCL. Consequently the change is
slightly more extensive than it could otherwise be.
ld/
* testsuite/ld-elf/shared.exp: Add $AFLAGS_PIC throughout to PIC
assembly builds where missing and remove `tic6x-*-*' XFAIL
markings accordingly.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #8 from Ard Biesheuvel --- (In reply to Andrew Pinski from comment #7) > (In reply to Matthias Klose from comment #6) > > systemd on aarch64 configured with efi support fails with a similar > > relocation error: > > > > ld -o src/boot/efi/systemd_boot.so -T /usr/lib/elf_aarch64_efi.lds -shared > > -Bsymbolic -nostdlib -znocombreloc -L /usr/lib /usr/lib/crt0-efi-aarch64.o > > --defsym=EFI_SUBSYSTEM=0xa src/boot/efi/disk.c.o src/boot/efi/graphics.c.o > > src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o > > src/boot/efi/boot.c.o src/boot/efi/console.c.o src/boot/efi/shim.c.o -lefi > > -lgnuefi /usr/lib/gcc/aarch64-linux-gnu/7/libgcc.a > > ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against > > `EFI_SUBSYSTEM' can not be used when making a shared object > > This is a bug in either in gnu-efi or systemd. EFI_SUBSYSTEM is in the > pe-coff header so we don't want any relocation there :). Basically > EFI_SUBSYSTEM is not being defined. Note Uboot has a similar bug too. The PE/COFF header is part of the static GNU=EFI library, and uses a static relocation to populate the efi subsystem field when incorporated into a EFI executable. The ELF spec allows this, so if there is a bug here, it is in ld.bfd not in GNU-EFI, systemd or u-boot. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- (In reply to Matthias Klose from comment #6) > systemd on aarch64 configured with efi support fails with a similar > relocation error: > > ld -o src/boot/efi/systemd_boot.so -T /usr/lib/elf_aarch64_efi.lds -shared > -Bsymbolic -nostdlib -znocombreloc -L /usr/lib /usr/lib/crt0-efi-aarch64.o > --defsym=EFI_SUBSYSTEM=0xa src/boot/efi/disk.c.o src/boot/efi/graphics.c.o > src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o > src/boot/efi/boot.c.o src/boot/efi/console.c.o src/boot/efi/shim.c.o -lefi > -lgnuefi /usr/lib/gcc/aarch64-linux-gnu/7/libgcc.a > ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against > `EFI_SUBSYSTEM' can not be used when making a shared object This is a bug in either in gnu-efi or systemd. EFI_SUBSYSTEM is in the pe-coff header so we don't want any relocation there :). Basically EFI_SUBSYSTEM is not being defined. Note Uboot has a similar bug too. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 Matthias Klose changed: What|Removed |Added CC||ramana at sourceware dot org --- Comment #6 from Matthias Klose --- systemd on aarch64 configured with efi support fails with a similar relocation error: ld -o src/boot/efi/systemd_boot.so -T /usr/lib/elf_aarch64_efi.lds -shared -Bsymbolic -nostdlib -znocombreloc -L /usr/lib /usr/lib/crt0-efi-aarch64.o --defsym=EFI_SUBSYSTEM=0xa src/boot/efi/disk.c.o src/boot/efi/graphics.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o src/boot/efi/boot.c.o src/boot/efi/console.c.o src/boot/efi/shim.c.o -lefi -lgnuefi /usr/lib/gcc/aarch64-linux-gnu/7/libgcc.a ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against `EFI_SUBSYSTEM' can not be used when making a shared object complete build log at https://launchpadlibrarian.net/355386549/buildlog_ubuntu-bionic-arm64.systemd_237-1ubuntu1_BUILDING.txt.gz Related to: 2017-12-13 Renlin Li * elfnn-aarch64.c (elfNN_aarch64_check_relocs): Disallow BFD_RELOC_AARCH64_16 in shared object const section. Disallow BFD_RELOC_AARCH64_32 in shared object const section under LP64. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 Matthias Klose changed: What|Removed |Added CC||renlin.li at arm dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22773] New: [ARM] Invalid immediate constants produce incorrect instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=22773 Bug ID: 22773 Summary: [ARM] Invalid immediate constants produce incorrect instructions Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: koops.j at gmail dot com Target Milestone: --- I have the following bit of assembly: .syntax unified .cpu cortex-m4 .thumb .section .text orr r1, #12800 orr r1, #12801 I invoke the GNU assembler as follows: arm-none-eabi-gcc -g -Wall -c bla.s The assembler issues no warnings, but the output, when inspected with objdump, looks as follows: bla.o: file format elf32-littlearm Disassembly of section .text: <.text>: 0: f441 5148 orr.w r1, r1, #12800 ; 0x3200 4: f243 2101 movwr1, #12801 ; 0x3201 The second orr instruction, which should've produced an error since the constant #12801 cannot be encoded as an immediate, was silently changed into a mov instruction instead. The exact version of the assembler is: GNU assembler version 2.29.51 (arm-none-eabi) using BFD version (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 2.29.51.20171128 I'm running OSX: Darwin trumposaurus.local 15.6.0 Darwin Kernel Version 15.6.0: Sun Jun 4 21:43:07 PDT 2017; root:xnu-3248.70.3~1/RELEASE_X86_64 x86_64 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22773] [ARM] Invalid immediate constants produce incorrect instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=22773 --- Comment #1 from Jeroen Koops --- I highly suspect commit bada434212 to be the problem, in particular the fragment starting at tc-arm.c:23596. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/22773] [ARM] Invalid immediate constants produce incorrect instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=22773 Jeroen Koops changed: What|Removed |Added CC||koops.j at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
