[Bug gas/19556] GNURX toolchain generates incorrect opcode for "mov.b #0xff, [r0]" instruction.
https://sourceware.org/bugzilla/show_bug.cgi?id=19556 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Vinay, > The above reported testcase work fine with attched patch for r0 register. > https://sourceware.org/bugzilla/attachment.cgi?id=8954 You need to make the patch work with all registers though, not just the r0 register. When you do, please also make sure to run the gas testsuite on the resulting patched assembler. I found that just adding F($8, 9, 3) to your new patterns actually resulted in some new failures ... Cheers Nick PS. If you prefer I can have a go at fixing the bug, but I thought that you might find it useful to experiment with fixing it yourself. -- 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 binutils/19571] New: Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 Bug ID: 19571 Summary: Buffer Overflow in libbfd Product: binutils Version: unspecified Status: NEW Severity: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: boehme.marcel at gmail dot com Target Milestone: --- Created attachment 8956 --> https://sourceware.org/bugzilla/attachment.cgi?id=8956&action=edit Test case #1 The attached program binary causes a buffer overflow in cplus-dem.c when it tries to demangle specially crafted function arguments in the binary. Both the buffer size as well as the buffer content are controlled from the binary. Tested on the following configurations * 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 22:00:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux * 4.1.12-boot2docker #1 SMP Tue Nov 3 06:03:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux * Binutils versions: 2.20 and 2.26 Best regards, - Marcel -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 --- Comment #1 from Marcel Böhme --- Created attachment 8957 --> https://sourceware.org/bugzilla/attachment.cgi?id=8957&action=edit Test Case #2 -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |WONTFIX --- Comment #2 from Nick Clifton --- Hi Marcel, > The attached program binary causes a buffer overflow in cplus-dem.c when it > tries to demangle specially crafted function arguments in the binary. cplus-dem.c is part of the libiberty package, which is not part of the binutils. Please could you report this problem using the gcc bugzilla system instead ? When you do, please could you also include details of how to trigger the bug, ie the command that you ran. It would also help if you could say how you detected the bug - are you running the command under valgrind, or did you compile it with sanitization enabled ? Cheers Nick -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 --- Comment #3 from Marcel Böhme --- Hi Nick, Sure. I'll send the bug report to the gcc bugzilla. The bug can be triggered with: objdump -x -C nm -C I detected the bug with a modified version of the AFL Fuzzer w/out sanitization. -- 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/19556] GNURX toolchain generates incorrect opcode for "mov.b #0xff, [r0]" instruction.
https://sourceware.org/bugzilla/show_bug.cgi?id=19556 --- Comment #4 from vinay kumar --- Hi Nick, Thanks for your feedback I will work on this bug. Regards, Vinay -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #4 from Markus Trippelsdorf --- I don't think it makes any sense to fuzz the demangler with arbitrary binary files. -- 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/19541] Format reader for ILF format (used by MSVC-generated import libraries) does not properly handle data imports
https://sourceware.org/bugzilla/show_bug.cgi?id=19541 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Hi Nathaniel, Right - the patch is checked in. I have verified that the patched sources do indeed show the data symbols in the ILF object file you uploaded. Unfortunately I have not been able to work out a way to turn this into a testcase in the binutils testsuite. So I will leave that for now. In the meantime I am closing this PR, but if the problem resurfaces please do not hesitate to reopen it. Cheers Nick -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 --- Comment #5 from Nick Clifton --- Hi Markus, > I don't think it makes any sense to fuzz the demangler with arbitrary binary > files. The tools (nm, objdump) should be able to cope though. When I tried running nm for example I received this error message (after a long pause): ./binutils/nm-new: out of memory allocating 18446744071629176800 bytes after a total of 3221147648 bytes We ought to be able to better than this. Or rather the libiberty demangler should be able to cope better. Cheers Nick -- 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 binutils/19571] Buffer Overflow in libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=19571 Markus Trippelsdorf changed: What|Removed |Added URL||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69687 Resolution|WONTFIX |MOVED --- Comment #6 from Markus Trippelsdorf --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 -- 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/19572] New: -Ttext-segment accepts out of range value
https://sourceware.org/bugzilla/show_bug.cgi?id=19572 Bug ID: 19572 Summary: -Ttext-segment accepts out of range value Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- [hjl@gnu-6 pr19567]$ cat x.S .globl _start _start: #ifdef __x86_64__ mov $_start,%rax mov _start,%rax #else mov $_start,%eax mov _start,%eax #endif [hjl@gnu-6 pr19567]$ make LD=ld gcc -m32 -c -O2 -ffunction-sections -fPIC -o x.o x.S ld -Ttext-segment 0x8000 -m elf_i386 -o x x.o objdump -dw x x: file format elf32-i386 Disassembly of section .text: 8054 <_start>: 8054: b8 54 00 00 80 mov$0x8054,%eax 8059: a1 54 00 00 80 mov0x8054,%eax [hjl@gnu-6 pr19567]$ Ld shouldn't accept -Ttext-segment 0x8000 for 32-bit ELF. -- 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/19567] Symbol_value::value doesn't support x32 overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=19567 --- Comment #8 from H.J. Lu --- (In reply to Cary Coutant from comment #7) > > [hjl@gnu-6 pr19567]$ cat x.s > > .globl _start > > _start: > > mov $_start,%rax > > mov _start,%rax > > [hjl@gnu-6 pr19567]$ make > > as --x32 -o x.o x.s > > ld.gold -m elf32_x86_64 -Ttext-segment 0x8000 -o x x.o > > objdump -dw x > > > > x: file format elf32-x86-64 > > > > > > Disassembly of section .text: > > > > 8074 <_start>: > > 8074: 48 c7 c0 74 00 00 80mov$0x8074,%rax > > 807b: 48 8b 04 25 74 00 00 80 mov0x8074,%rax > > This looks correct to me (and also highly artificial). According to the > psABI, x32 uses an address space running from 0 to 0x7eff (the small > code model); from 0x8000 and up is considered the "negative half" of the > address space (the kernel code model). According to that, you're actually > placing the text segment at a negative address, and the mov instruction is > generating the correct 64-bit value. My test here doesn't follow any programming model and is independent of x32 or x86-64: [hjl@gnu-6 pr19567]$ cat x.s .globl _start _start: mov $_start,%rax mov _start,%rax [hjl@gnu-6 pr19567]$ make as -o x.o x.s ld.gold -Ttext-segment 0x8000 -o x x.o objdump -dw x x: file format elf64-x86-64 Disassembly of section .text: 80b0 <_start>: 80b0: 48 c7 c0 b0 00 00 80mov$0x80b0,%rax 80b7: 48 8b 04 25 b0 00 00 80 mov0x80b0,%rax [hjl@gnu-6 pr19567]$ > Linking with -Ttext-segment 0x8000 and with -Ttext-segment > 0x8000 produces the same results, as far as I can tell (as it > should, since we're dealing with a 32-bit address space): Address is truncated to 32 bits. I opened: https://sourceware.org/bugzilla/show_bug.cgi?id=19572 > [../../ld-new == gold] > $ ../../ld-new -m elf32_x86_64 -Ttext-segment=0x8000 x.o > $ readelf -sW a.out > > Symbol table '.symtab' contains 5 entries: >Num:Value Size TypeBind Vis Ndx Name > 0: 0 NOTYPE LOCAL DEFAULT UND > 1: 8074 0 NOTYPE GLOBAL DEFAULT1 _start > 2: 80001000 0 NOTYPE GLOBAL DEFAULT ABS _edata > 3: 80001000 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > 4: 80001000 0 NOTYPE GLOBAL DEFAULT ABS _end > $ objdump -d a.out > > a.out: file format elf32-x86-64 > > > Disassembly of section .text: > > 8074 <_start>: > 8074: 48 c7 c0 74 00 00 80mov$0x8074,%rax > 807b: 48 8b 04 25 74 00 00mov0x8074,%rax > 8082: 80 The issue here is the operand of mov is the address/immediate of symbol _start. Gold doesn't handle it properly. > $ ../../ld-new -m elf32_x86_64 -Ttext-segment=0x8000 x.o > $ readelf -sW a.out > > Symbol table '.symtab' contains 5 entries: >Num:Value Size TypeBind Vis Ndx Name > 0: 0 NOTYPE LOCAL DEFAULT UND > 1: 8074 0 NOTYPE GLOBAL DEFAULT1 _start > 2: 80001000 0 NOTYPE GLOBAL DEFAULT ABS _edata > 3: 80001000 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > 4: 80001000 0 NOTYPE GLOBAL DEFAULT ABS _end > $ objdump -d a.out > > a.out: file format elf32-x86-64 > > > Disassembly of section .text: > > 8074 <_start>: > 8074: 48 c7 c0 74 00 00 80mov$0x8074,%rax > 807b: 48 8b 04 25 74 00 00mov0x8074,%rax > 8082: 80 > > > On the other hand, using movabs: > > $ ../../ld-new -m elf32_x86_64 -Ttext-segment=0x8000 z.o > $ objdump -d a.out > > a.out: file format elf32-x86-64 > > > Disassembly of section .text: > > 8074 <_start>: > 8074: 48 b8 74 00 00 80 00movabs $0x8074,%rax > 807b: 00 00 00 > 807e: 48 a1 74 00 00 80 00movabs 0x8074,%rax > 8085: 00 00 00 > > Here, 0x8074 should have been sign-extended when we applied the > relocations. No, it shouldn't. > Now using Gnu ld: > > $ ld -m elf32_x86_64 -Ttext-segment=0x8000 z.o > $ objdump -d a.out > > a.out: file format elf32-x86-64 > > > Disassembly of section .text: > > 8054 <_start>: > 8054: 48 b8 54 00 00 80 00movabs $0x8054,%rax > 805b: 00 00 00 > 805e: 48 a1 54 00 00 80 00movabs 0x8054,%rax > 8065: 00 00 00 > > $ ld -m elf32_x86_64 -Ttext-segment=0x8000 z.o > $ objdump -d a.out > > a.out: file format elf32-x86-64 > > > Disassembly of section .text: > > 8054 <_start>: > 8054: 48 b8 54 00 00 80 ffmovabs $0x8054,%rax > 805b: ff ff ff > 805e: 48 a1 54 00 00 80 ffmovabs 0x8054,%rax > 8065: ff ff ff > > This is an ELF32 file. In both cases, the segment headers are the same: > > Elf file type is
Re: binutils 2.25.1 creates big sparse files
Hi Joakim, > When building small libs/exec on ppc32 I usally get sparse files like so: > binutils 2.25.1 doing in this commit: > (Set ppc COMMONPAGESIZE to 64k) > > This is a huge problem as these sparse file are packaged into a > tar file and when unpacked they lose the sparse attribute and will expand to > 66K on > disk and fill up the my small FS. > I guess many packaging tools uses tar so I expect I other people will run > into this to. > > I do wonder why it now became necessary to increase page size in binutils? For correct operation with Linux based installations. It appears however that there is a workaround. If you define __QNXTARGET__ whilst building the ppc32 binutils you will set the page size to 1K, which is presumably what you want. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19437] ld segmentation fault
https://sourceware.org/bugzilla/show_bug.cgi?id=19437 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi João, Could you check to see if the problem still exists with the new 2.26 release ? I have a feeling that it might have been fixed... Cheers Nick -- 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/18695] [x86-64] Missing relocation overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=18695 --- Comment #5 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=44803b5d876fcbbc1c6d9919a1b763679d5c035f commit 44803b5d876fcbbc1c6d9919a1b763679d5c035f Author: Cary Coutant Date: Fri Feb 5 08:27:13 2016 -0800 Overhaul relocation framework to support overflow checking. gold/ PR gold/18695 * reloc.h (Relocate_functions::Address): New typedef. (Relocate_functions::Addendtype): New typedef. (Relocate_functions::Overflow_check): New enum type. (Relocate_functions::Reloc_status): New enum type. (Relocate_functions::check_overflow): New function template. (Relocate_functions::rel): Add check parameter; check for overflow. (Relocate_functions::rel_unaligned): Likewise. (Relocate_functions::rela): Likewise. (Relocate_functions::pcrel): Likewise. (Relocate_functions::pcrel_unaligned): Likewise. (Relocate_functions::pcrela): Likewise. (Relocate_functions::rel8): Adjust parameter types. (Relocate_functions::rela8): Likewise. (Relocate_functions::pcrel8): Likewise. (Relocate_functions::pcrela8): Likewise. (Relocate_functions::rel16): Likewise. (Relocate_functions::rela168): Likewise. (Relocate_functions::pcrel16): Likewise. (Relocate_functions::pcrela16): Likewise. (Relocate_functions::rel32): Likewise. (Relocate_functions::rel32_unaligned): Likewise. (Relocate_functions::rela32): Likewise. (Relocate_functions::pcrel32): Likewise. (Relocate_functions::pcrel32_unaligned): Likewise. (Relocate_functions::pcrela32): Likewise. (Relocate_functions::rel8_check): New function. (Relocate_functions::rela8_check): New function. (Relocate_functions::pcrel8_check): New function. (Relocate_functions::pcrela8_check): New function. (Relocate_functions::rel16_check): New function. (Relocate_functions::rela168_check): New function. (Relocate_functions::pcrel16_check): New function. (Relocate_functions::pcrela16_check): New function. (Relocate_functions::rel32_check): New function. (Relocate_functions::rel32_unaligned_check): New function. (Relocate_functions::rela32_check): New function. (Relocate_functions::pcrel32_check): New function. (Relocate_functions::pcrel32_unaligned_check): New function. (Relocate_functions::pcrela32_check): New function. (Bits::has_unsigned_overflow32): New function. (Bits::has_unsigned_overflow): New function. * testsuite/Makefile.am (overflow_unittest): New test. * testsuite/Makefile.in: Regenerate. * testsuite/overflow_unittest.cc: New source file. -- 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/19567] Symbol_value::value doesn't support x32 overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=19567 --- Comment #9 from Cary Coutant --- > My test here doesn't follow any programming model and is independent of > x32 or x86-64: > > [hjl@gnu-6 pr19567]$ cat x.s > .globl _start > _start: > mov $_start,%rax > mov _start,%rax > [hjl@gnu-6 pr19567]$ make > as -o x.o x.s > ld.gold -Ttext-segment 0x8000 -o x x.o With today's patches to add overflow checking, this now gives relocation overflow errors for x86_64: $ ../../ld-new -Ttext-segment=0x8000 x64.o x64.o(.text+0x3): error: relocation overflow x64.o(.text+0xb): error: relocation overflow I guess we'll have to agree to disagree about x32. > > $ ../../ld-new -m elf32_x86_64 -Ttext-segment=0x8000 z.o > > $ objdump -d a.out > > > > a.out: file format elf32-x86-64 > > > > > > Disassembly of section .text: > > > > 8074 <_start>: > > 8074: 48 b8 74 00 00 80 00movabs $0x8074,%rax > > 807b: 00 00 00 > > 807e: 48 a1 74 00 00 80 00movabs 0x8074,%rax > > 8085: 00 00 00 > > > > Here, 0x8074 should have been sign-extended when we applied the > > relocations. > > No, it shouldn't. Are you going to change the psABI document? -- 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/18695] [x86-64] Missing relocation overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=18695 --- Comment #6 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=c34c98ed62f7f01fa19b1cfb174df942ee47127d commit c34c98ed62f7f01fa19b1cfb174df942ee47127d Author: Cary Coutant Date: Fri Feb 5 09:19:47 2016 -0800 Add some relocation overflow checks for x86_64. 2016-02-05 Cary Coutant Andrew Senkevich gold/ PR gold/18695 * x86_64.cc (Target_x86_64::Relocate::relocate): Add overflow checking for R_X86_64_32, R_X86_64_32S, R_X86_64_PC32, and R_X86_64_PLT32. * testsuite/Makefile.am (x86_64_overflow_pc32): New test. * testsuite/x86_64_overflow_pc32.sh: New test script. * testsuite/x86_64_overflow_pc32.s: New source file. -- 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/19541] Format reader for ILF format (used by MSVC-generated import libraries) does not properly handle data imports
https://sourceware.org/bugzilla/show_bug.cgi?id=19541 --- Comment #5 from Nathaniel J. Smith --- Can the test suite include binary files? Two tests I can think of would be: 1) Include the ILF file; run objdump on it; confirm that the appropriate symbols appear. 2) Include the ILF file + a regular .o that references a data member in it; use ld to link them together and then use objdump to confirm that the resulting dll has a correct import table. -- 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/18695] [x86-64] Missing relocation overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=18695 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #7 from Cary Coutant --- Leaving this open, as there are still more overflow checks to add. -- 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/19567] Symbol_value::value doesn't support x32 overflow check
https://sourceware.org/bugzilla/show_bug.cgi?id=19567 --- Comment #10 from H.J. Lu --- (In reply to Cary Coutant from comment #9) > > My test here doesn't follow any programming model and is independent of > > x32 or x86-64: > > > > [hjl@gnu-6 pr19567]$ cat x.s > > .globl _start > > _start: > > mov $_start,%rax > > mov _start,%rax > > [hjl@gnu-6 pr19567]$ make > > as -o x.o x.s > > ld.gold -Ttext-segment 0x8000 -o x x.o > > With today's patches to add overflow checking, this now gives relocation > overflow errors for x86_64: > > $ ../../ld-new -Ttext-segment=0x8000 x64.o > x64.o(.text+0x3): error: relocation overflow > x64.o(.text+0xb): error: relocation overflow Thanks. > I guess we'll have to agree to disagree about x32. > > > > $ ../../ld-new -m elf32_x86_64 -Ttext-segment=0x8000 z.o > > > $ objdump -d a.out > > > > > > a.out: file format elf32-x86-64 > > > > > > > > > Disassembly of section .text: > > > > > > 8074 <_start>: > > > 8074: 48 b8 74 00 00 80 00movabs $0x8074,%rax > > > 807b: 00 00 00 > > > 807e: 48 a1 74 00 00 80 00movabs 0x8074,%rax > > > 8085: 00 00 00 > > > > > > Here, 0x8074 should have been sign-extended when we applied the > > > relocations. > > > > No, it shouldn't. > > Are you going to change the psABI document? No. Small model is for compilers. Assembly can do whatever it wants within 32-bit address space. -- 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
OCTETS_PER_BYTE and Gas
To those who maintain the GNU assembler, thank you.
I am currently working on a back-end implementation of the assembler to
an embedded system where OCTETS_PER_BYTE=4. From a C standpoint, you
might think of it as a system where sizeof(char)==sizeof(int), and both
are 32-bits.
The embedded system is quite minimal in its support, therefore I don't
expect to run the assembler from the embedded system itself. I'm just
building a cross-assembler to support this target from an i86_64
machine.
The assembler support structure provided by the GNU assembler has worked
quite well for this circumstance, with only a couple minor changes that
I would like to propose. Without these changes, the assembler would
crash with some strange bugs. Therefore, I thought I'd push these
upstream.
Admittedly, my full implementation requires lots of other changes
elsewhere, such as in the testsuite, configuration files, and more.
These changes, though, should be applicable to anyone else working in
this type of situation.
Below is the diff for gas/read.c:
--- binutils-2.25-original/gas/read.c 2014-10-14 03:32:03.0
-0400
+++ binutils-2.25/gas/read.c2016-02-05 06:48:11.911995367 -0500
@@ -684,7 +684,8 @@
/* We do this every time rather than just in s_bundle_align_mode
so that we catch any affected section without needing hooks all
over for all paths that do section changes. It's cheap enough.
*/
- record_alignment (now_seg, bundle_align_p2 - OCTETS_PER_BYTE_POWER);
+ if (bundle_align_p2 > OCTETS_PER_BYTE_POWER)
+record_alignment (now_seg, bundle_align_p2 -
OCTETS_PER_BYTE_POWER);
}
/* Assemble one instruction. This takes care of the bundle features
@@ -1394,6 +1395,9 @@
static void
do_align (int n, char *fill, int len, int max)
{
+ if (n < OCTETS_PER_BYTE_POWER)
+n = OCTETS_PER_BYTE_POWER;
+
if (now_seg == absolute_section)
{
if (fill != NULL)
@@ -1415,7 +1419,7 @@
#endif
/* Only make a frag if we HAVE to... */
- if (n != 0 && !need_pass_2)
+ if ((n >= OCTETS_PER_BYTE_POWER) && !need_pass_2)
{
if (fill == NULL)
{
@@ -1434,7 +1438,8 @@
just_record_alignment: ATTRIBUTE_UNUSED_LABEL
#endif
- record_alignment (now_seg, n - OCTETS_PER_BYTE_POWER);
+ if (n > OCTETS_PER_BYTE_POWER)
+record_alignment (now_seg, n - OCTETS_PER_BYTE_POWER);
}
/* Handle the .align pseudo-op. A positive ARG is a default alignment
@@ -4927,6 +4932,8 @@
while (!(((value == 0) && ((byte & 0x40) == 0))
|| ((value == -1) && ((byte & 0x40) != 0;
+ if (OCTETS_PER_BYTE_POWER > 0)
+size = (size +
(1< 0)
+size = (size +
(1< 0)
+size = (size +
(1< 0)
+size = (size +
(1<___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19472] [aarch64] Large shared objects need pc-relative stubs or relocations for absolute stubs
https://sourceware.org/bugzilla/show_bug.cgi?id=19472 Han Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Han Shen --- Fixed in 9a472eda40ba686e45bf4922455518ffa3c887e1 -- 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/19576] New: bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 Bug ID: 19576 Summary: bogus code generation with on SunOS with 2.26 Product: binutils Version: 2.26 Status: NEW Severity: critical Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: richard at netbsd dot org Target Milestone: --- Created attachment 8958 --> https://sourceware.org/bugzilla/attachment.cgi?id=8958&action=edit intermediate assembler file Having applied the patch for gas/19520 backported to 2.26 release tarball and used with pkgsrc gcc49, I'm noticing issues when building either pkgsrc modular-xorg-server or modular-xorg-xephyr 1.18.0 on SunOS 5.11 (illumos distribution OmniOS) 32-bit i386 with dtrace enabled With gas from binutils 2.25.1 things build just fine. The symptom is the following during link (with sun linker): > CCLD Xorg > Undefined first referenced > symbol in file > ree ../../dix/dix.O > ld: fatal: symbol referencing errors. No output written to Xorg > collect2: error: ld returned 1 exit status after digging in to see the problem, I was able to isolate the issue with the module dix/resource.c, setting '-save-temps -v'. The intermediates (.i and .s) are, as hoped, identical in the test runs, only the generated .o is different. listing the symbols from the 'bad' file: gnm -lug .libs/resource.o U __assert_c99 resource.c:0 U _CallCallbacks resource.c:0 U _GLOBAL_OFFSET_TABLE_resource.c:0 U clients resource.c:0 U CloseFont U currentMaxClientsresource.c:0 U DeletePassiveGrab U DeleteWindow U dixDestroyPixmap U ErrorF resource.c:0 U FatalError resource.c:0 U FreeClientPixels U FreeColormap U FreeCursor U FreeGC U HandleSaveSetresource.c:0 U LimitClients resource.c:0 U LookupResourceName resource.c:0 U malloc resource.c:0 U MarkClientException resource.c:0 U NoopDDA U noPanoramiXExtension resource.c:0 U OtherClientGone U ree resource.c:0 U RegisterResourceName resource.c:0 U serverClient resource.c:0 U XaceHook resource.c:0 U xreallocarrayresource.c:0 which differs from the 'good' one generated with 2.25.1 only with 'free()': 12d11 < U free resource.c:0 24a24 > U reeresource.c:0 disabling dtrace fixes the problem. To note, dtrace generates symbols of the sort: grep dtrace resource.s call__dtrace_Xserver___resource__alloc@PLT call__dtrace_Xserver___resource__free@PLT call__dtrace_Xserver___resource__free@PLT call__dtrace_Xserver___resource__free@PLT call__dtrace_Xserver___resource__free@PLT I add the .s file for info -- 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/19576] bogus code generation with on SunOS with 2.26
https://sourceware.org/bugzilla/show_bug.cgi?id=19576 --- Comment #1 from Richard PALO --- Created attachment 8959 --> https://sourceware.org/bugzilla/attachment.cgi?id=8959&action=edit the respective gas output file -- 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
