[Bug ld/20428] ld powerpc64le NULL deref in ppc_get_stub_entry when linking code in not-executable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20428 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alan Modra --- Fixed -- 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/20428] ld powerpc64le NULL deref in ppc_get_stub_entry when linking code in not-executable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20428 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The binutils-2_26-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d45d94d9484e5f22e1e414a17f8d4317f4f1ee37 commit d45d94d9484e5f22e1e414a17f8d4317f4f1ee37 Author: Alan Modra Date: Tue Aug 2 23:28:47 2016 +0930 PowerPC64 ld segfault with code in non-executable sections PR ld/20428 * elf64-ppc.c (ppc_get_stub_entry): Don't segfault on NULL group. -- 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/20428] ld powerpc64le NULL deref in ppc_get_stub_entry when linking code in not-executable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20428 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The binutils-2_27-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=24ef2be9b6ca8276a62b3f60f845f4c8bb6194dd commit 24ef2be9b6ca8276a62b3f60f845f4c8bb6194dd Author: Alan Modra Date: Tue Aug 2 23:28:47 2016 +0930 PowerPC64 ld segfault with code in non-executable sections PR ld/20428 * elf64-ppc.c (ppc_get_stub_entry): Don't segfault on NULL group. -- 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/17739] Assertion fail ../../bfd/elf32-sh.c:4504 on sh4 when compiling Qt5
https://sourceware.org/bugzilla/show_bug.cgi?id=17739 --- Comment #22 from John Paul Adrian Glaubitz --- (In reply to cvs-com...@gcc.gnu.org from comment #20) > The master branch has been updated by Nick Clifton : Btw, can you make sure this gets backported to binutils-2_27-branch as well? We need to make sure it's going to be in the 2.27 release. Thanks, Adrian -- 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/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Ali Bahrami changed: What|Removed |Added CC||ali_swbugzilla at emvision dot com --- Comment #7 from Ali Bahrami --- We think it's not a linker bug. The 32 and 64-bit sparc platform ABIs are distinct, and here, we're talking about relocations defined for 64-bit objects, but not for 32-bit ones. The error from ld seems legit, and is intended to catch this case. The 2 tables of sparc relocations (32 and 64-bit) can be found here: https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-62988 This question wouldn't come up if we were discussing x86, where the 32 and 64-bit relocations are pretty different, but with sparc, where the 64-bit case is essentially an extension of the 32-bit case, that's probably less obvious. Just to be sure, I checked with our resident sparc architecture expert, and he told us: I'm not exactly sure what the question is. The relocations are for late binding of the value of a symbol. Symbol values in a 32-bit program cannot be larger than 32-bits, AFAIK. Now relocations are a little more complicated, because they encode an expression. So, we could have relocations that encode an expression that is larger than 32-bits for a 32-bit program. But there has been no need for them, so they were never created, AFAIK. It would certainly be possible to create some 64-bit relocation expressions for 32-bit programs. I would want to see some better justification before creating them, though. And some assembler syntax might be necessary to disambiguate which relocation should be used in some circumstances. Which I will simplify to "we haven't needed that relocation for 32-bit sparc, so it doesn't exist". Another engineer here mentioned the following: For what it's worth, Go's internal linker handles this by generating two relocations internally -- one for the lower half of the 64-bit value and one for the upper half of the 64-bit value. This tends to work out nicely since you have to load each half separately anyway: // R_ADDRSPARC64LO (only used on sparc64) resolves to low 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64LO // R_ADDRSPARC64HI (only used on sparc64) resolves to high 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64HI That squares with Nick's earlier comment Does it, for example, produce two 32-bit relocs, one for the lower 32-bits and one for the upper 32-bits ? -- 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/20364] Data-based padding causes current address evaluation to be non-constant on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=20364 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-02 CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Nick Clifton --- Created attachment 9419 --> https://sourceware.org/bugzilla/attachment.cgi?id=9419&action=edit Proposed patch Hi Paul, This is a subtle one. What is happening is that ".align " in a code section (like .text or .vectors) will use the default NOP value to fill in the space. But ".align , " will use the provided fill value. This matters because the AArch64 backend knows that NOP is an instruction, but it does not know about and it assumes that it is a *data* value, not an *instruction*. So it changes the mapping state to MAP_DATA, creates a mapping symbol ($d) indicate the change of state, and creates a new fragment to contain the data. All of this means that when the macro parser tries to evaluate the .if statement it finds that dot is one fragment and the symbol is in another fragment. Since fragments can grow or shrink the distance between them cannot be computed reliably (at the time that the .if expressions is evaluated) and so the assembler issues its error message. I have uploaded a small patch which I think will fix the problem. It tells the AArch64 backend not to assume that alignment directives in code sections contain data. Instead it should assume that they contain instructions, and so not change the mapping state. This causes a subtle problem with regard to literal pools, but the patch takes care of that. Please give the patch a try and let me know how you get on. 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 gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #6 from Stefan Teleman --- If i change the test case for the Sun assembler: __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ + 0x1234567890 i get this: [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 7:30:35][544]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o /usr/bin/as: "test32-sun.S", line 14: warning: value does not fit in 32 bits [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 7:30:43][545]>> readelf -sW --relocs test32-sun.o Relocation section '.rela.data' at offset 0xf8 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 34567890 Symbol table '.symtab' contains 5 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32-sun.S 2: 0 SECTION LOCAL DEFAULT2 3: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 4: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr Same as GAS, but the Sun assembler emits a warning. Which now creates a new and interesting question that i am going to run by the Solaris linker people: isn't this a Solaris rtld bug, in final analysis? I will ask the linker folks and i will come up with more test cases for the other relocations. Thank you very much! --Stefan -- 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/20428] ld powerpc64le NULL deref in ppc_get_stub_entry when linking code in not-executable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20428 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=89d77b8a520602832516ce6628ea930b4f0ccff4 commit 89d77b8a520602832516ce6628ea930b4f0ccff4 Author: Alan Modra Date: Tue Aug 2 23:28:47 2016 +0930 PowerPC64 ld segfault with code in non-executable sections PR ld/20428 * elf64-ppc.c (ppc_get_stub_entry): Don't segfault on NULL group. -- 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/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #5 from Nick Clifton --- Hi Stefan, > So, this is what happens if i re-write the test32.S program for the Sun > SPARC assembler: > .comm .gomp_critical_user_, 64, 8 > Relocation section '.rela.data' at offset 0xf8 contains 1 entries: > Offset InfoTypeSym. Value Symbol's Name + Addend > 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 0 Interesting. I wonder if this is a bug in the Solaris assembler ? Maybe it knows that a symbol's value can only ever be 32-bits, so in this particular case the reloc will work. But what if the test really needed a (non-zero) 64-bit value to be installed into the memory location. For example, how does the Solaris assembler handle this: .data .global __kmp_unnamed_critical_addr __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ + 0x1234567890 .type __kmp_unnamed_critical_addr,#object .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr Looking at the output for GAS, it seems that the addition in the reloc is truncated: R_SPARC_UA64 .gomp_critical_user_+0x34567890 This is not reported as an error, either, so presumably it is expected behaviour. Which makes me think that your patch will be OK. But I would like to know the results of your search for other 64-bit tests. 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
Re: [Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
Hi Stefan, > So, this is what happens if i re-write the test32.S program for the Sun > SPARC assembler: > .comm .gomp_critical_user_, 64, 8 > Relocation section '.rela.data' at offset 0xf8 contains 1 entries: > Offset InfoTypeSym. Value Symbol's Name + Addend > 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 0 Interesting. I wonder if this is a bug in the Solaris assembler ? Maybe it knows that a symbol's value can only ever be 32-bits, so in this particular case the reloc will work. But what if the test really needed a (non-zero) 64-bit value to be installed into the memory location. For example, how does the Solaris assembler handle this: .data .global __kmp_unnamed_critical_addr __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ + 0x1234567890 .type __kmp_unnamed_critical_addr,#object .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr Looking at the output for GAS, it seems that the addition in the reloc is truncated: R_SPARC_UA64 .gomp_critical_user_+0x34567890 This is not reported as an error, either, so presumably it is expected behaviour. Which makes me think that your patch will be OK. But I would like to know the results of your search for other 64-bit tests. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20391] ar on native Windows stores localtime, not UTC times tamps in archives
https://sourceware.org/bugzilla/show_bug.cgi?id=20391 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Konrad, > $ ar tv libarm_mp_startup.a > rw-rw-rw- 0/0 18584 Jul 20 14:38 2016 startup.o > $ arm-none-eabi-ar tv libarm_mp_startup.a > rw-rw-rw- 0/0 18584 Jul 20 13:38 2016 startup.o Assuming that the two programs were compiled from the same binutils source code, it is hard to see how this can be a binutils problem. Since the (correctly working) ARM version of the tool was supplied by Canonical, however it may be that they have applied a patch that fixes the problem. If so, it would be worthwhile contacting them to find out detail of thehttps://sourceware.org/bugzilla/ patch. Otherwise all that I can think of is that the two tools are using different versions of the cygwin dll, one of which has a fix for the timestamp problem and one of which does not. 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 ld/20428] ld powerpc64le NULL deref in ppc_get_stub_entry when linking code in not-executable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=20428 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-02 CC|amodra at gmail dot com| Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- Gah, code in non-exec sections? -- 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/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #4 from Stefan Teleman --- Hi Nick, (In reply to Nick Clifton from comment #3) > Hi Stefan, > > > proposed patch -- tc-sparc.c.patch > > I have a couple of questions about this patch: > > 1. There appear to be other places in cons_fix_new_sparc() where > 64-bit relocs can be generated (ie BFD_RELOC_64_PCREL, > BFD_RELOC_SPARC_PLT64 and BFD_RELOC_SPARC_TLS_DTPOFF64) but the > patch does not affect them. Why not ? Mainly because i haven't been able to come up with a test case which would trigger gas to emit these 64-bit relocations in 32-bit. I can try coming up with test cases for these as well. This would actually be quite useful. > > 2. The relocs that you are changing are intended to install 64-bit > values into the binary. By changing them to 32-bit versions it > seems like you are loosing the upper bits. Have you run any tests > to see if 64-bit values are still handled correctly after applying > the patch ? [It would be useful to know what the Solaris assembler > does in these circumstances. Does it, for example, produce two > 32-bit relocs, one for the lower 32-bits and one for the upper > 32-bits ?] I have verified that the values are being handled correctly with the gas + Solaris ld combination. The Solaris SPARC assembler can't hanlde .8byte. So, i have to use .xword, which isn't quite the same exact thing as .8byte. So, this is what happens if i re-write the test32.S program for the Sun SPARC assembler: ! test32-sun.S .data .align 8 .global .gomp_critical_user_ .comm .gomp_critical_user_, 64, 8 .type .gomp_critical_user_,#object .size .gomp_critical_user_, 64 .data .global __kmp_unnamed_critical_addr __kmp_unnamed_critical_addr: .xword .gomp_critical_user_ .type __kmp_unnamed_critical_addr,#object .size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr .file "test32-sun.S" [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:49:34][536]>> /usr/bin/as -m32 -xarch=v8plusa test32-sun.S -o test32-sun.o [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:49:36][537]>> readelf -sW --relocs test32-sun.o Relocation section '.rela.data' at offset 0xf8 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0004 0303 R_SPARC_32 0008 .gomp_critical_user_ + 0 Symbol table '.symtab' contains 5 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32-sun.S 2: 0 SECTION LOCAL DEFAULT2 3: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 4: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr So, as you can see, the Sun SPARC assembler emitted a R_SPARC_32 relocation for .gomp_critical_user_. By comparison, GAS with my proposed patch emits this: [steleman@hoggle][/builds/steleman/userland-s12-binutils-gas-24380705/components/binutils/build/sparcv9/gas][08/02/2016 6:50:56][540]>> readelf -sW --relocs test32-new.o Relocation section '.rela.data' at offset 0x140 contains 1 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0617 R_SPARC_UA32 0008 .gomp_critical_user_ + 0 Symbol table '.symtab' contains 8 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS test32.S 2: 0 SECTION LOCAL DEFAULT1 3: 0 SECTION LOCAL DEFAULT2 4: 0 SECTION LOCAL DEFAULT4 5: 0 SECTION LOCAL DEFAULT5 6: 000864 OBJECT GLOBAL DEFAULT COM .gomp_critical_user_ 7: 8 OBJECT GLOBAL DEFAULT2 __kmp_unnamed_critical_addr But, you are absolutely right in saying that I should come up with test cases and proposed patches for all the other possible 64-bit relocations for 32-bit cases. So, please stay tuned. :-) And thank you very much for looking at this proposed patch so quickly!! -- 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/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Stefan, > proposed patch -- tc-sparc.c.patch I have a couple of questions about this patch: 1. There appear to be other places in cons_fix_new_sparc() where 64-bit relocs can be generated (ie BFD_RELOC_64_PCREL, BFD_RELOC_SPARC_PLT64 and BFD_RELOC_SPARC_TLS_DTPOFF64) but the patch does not affect them. Why not ? 2. The relocs that you are changing are intended to install 64-bit values into the binary. By changing them to 32-bit versions it seems like you are loosing the upper bits. Have you run any tests to see if 64-bit values are still handled correctly after applying the patch ? [It would be useful to know what the Solaris assembler does in these circumstances. Does it, for example, produce two 32-bit relocs, one for the lower 32-bits and one for the upper 32-bits ?] 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 ld/17739] Assertion fail ../../bfd/elf32-sh.c:4504 on sh4 when compiling Qt5
https://sourceware.org/bugzilla/show_bug.cgi?id=17739 John Paul Adrian Glaubitz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from John Paul Adrian Glaubitz --- I think we can mark this as RESOLVED now. -- 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/17739] Assertion fail ../../bfd/elf32-sh.c:4504 on sh4 when compiling Qt5
https://sourceware.org/bugzilla/show_bug.cgi?id=17739 --- Comment #20 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a94d834c9d0108f0bb50ddc311554d1bed320f54 commit a94d834c9d0108f0bb50ddc311554d1bed320f54 Author: Nick Clifton Date: Tue Aug 2 11:56:55 2016 +0100 Fix SH GOT allocation in the presence of linker garbage collection. PR ld/17739 ld * emulparams/shelf.sh (CHECK_RELOCS_AFTER_OPEN_INPUT): Define with valye 'yes'. * emulparams/shelf32.sh: Likewise. * emulparams/shelf32.sh: Likewise. * emulparams/shelf_nto.sh: Likewise. * emulparams/shelf_nto.sh: Likewise. * emulparams/shelf_vxworks.sh: Likewise. * emulparams/shelf_vxworks.sh: Likewise. * emulparams/shlelf32_linux.sh: Likewise. * emulparams/shlelf32_linux.sh: Likewise. * emulparams/shlelf_linux.sh: Likewise. * emulparams/shlelf_linux.sh: Likewise. * emulparams/shlelf_nto.sh: Likewise. * emulparams/shlelf_nto.sh: Likewise. bfd * elf32-sh.c (sh_elf_gc_sweep_hook): Delete. (elf_backend_sweep_hook): Delete. -- 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/17512] libbfd/binutils: crashes on fuzzed samples
https://sourceware.org/bugzilla/show_bug.cgi?id=17512 felix changed: What|Removed |Added CC|felix.von.s at posteo dot de | -- 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/17512] libbfd/binutils: crashes on fuzzed samples
https://sourceware.org/bugzilla/show_bug.cgi?id=17512 --- Comment #232 from Nick Clifton --- (In reply to Christophe Lyon from comment #230) Hi Christophe, > ../../binutils/resbin.c:967:5: error: format '%lu' expects argument of type > 'long unsigned int', but argument 2 has type 'rc_uint_type' [-Werror=format=] > verlen, length); Sorry about that. For some reason my 32-bit builds are not showing up this kind of problem. I think it is because my host machine is still 64-bits. Anyway, I have checked in a simple patch to fix the problem. 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/17512] libbfd/binutils: crashes on fuzzed samples
https://sourceware.org/bugzilla/show_bug.cgi?id=17512 --- Comment #231 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2d5bddc1eb5d2c04ed142c7ba6fc13e2e3a28079 commit 2d5bddc1eb5d2c04ed142c7ba6fc13e2e3a28079 Author: Nick Clifton Date: Tue Aug 2 11:06:28 2016 +0100 Avoid compile time warning when building on 32-bit host. PR binutils/17512 * resbin.c (bin_to_res_version): Cast variables to correct type for printing in error message. -- 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/20430] 1-855-855-6595 Mcafee Antivirus Tech Support Number USA customer care
https://sourceware.org/bugzilla/show_bug.cgi?id=20430 Mike Frysinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Assignee|ccoutant at gmail dot com |unassigned at sourceware dot org --- Comment #1 from Mike Frysinger --- spam -- 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/20430] New: 1-855-855-6595 Mcafee Antivirus Tech Support Number USA customer care
https://sourceware.org/bugzilla/show_bug.cgi?id=20430 Bug ID: 20430 Summary: 1-855-855-6595 Mcafee Antivirus Tech Support Number USA customer care Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: jimmyanderson908 at gmail dot com CC: ian at airs dot com Target Milestone: --- Mcafee Antivirus Tech Support Number USA : 1-855-855-6595 technical support 360 Phone Mcafee internet security customer service usa Mcafee tech support scams Mcafee customer service 360 Phone number ++ 1-855-855-6595 ++ ireland Mcafee internet customer service Mcafee customer service hong kong Mcafee customer service canada Mcafee symantec customer service 360 Phone number ++ 1-855-855-6595 ++ Mcafee 360 tech support 360 Phone number usa Mcafee symantec customer login Mcafee by symantec customer service number ++ 1-855-855-6595 ++ Mcafee registry cleaner support does Mcafee support windows xp Mcafee antivirus download crack Mcafee customer download Mcafee antivirus disable Mcafee USA customer service patrick Mcafee tech thing Mcafee tech support 360 Phone number usa Mcafee technical ltd Mcafee healthcare customer service Mcafee product support technical issues Mcafee security tech bench Mcafee mercury technical data Mcafee internet security tech support 360 Phone number Mcafee customer service 360 Phone number ++ 1-855-855-6595 ++ canada Mcafee tech support australia gillian Mcafee wake tech Mcafee Antivirus Tech Support Number USA tech support 360 Phone number Mcafee enterprise support contact Mcafee technical support Mcafee Antivirus Tech Support Number USA customer service 360 Phone number ++ 1-855-855-6595 ++ USA Mcafee customer service USA Mcafee commando tech tips Mcafee customer service number ++ 1-855-855-6595 ++ in usa Mcafee technical support email address Mcafee 360 existing customer download tech support for Mcafee Antivirus Tech Support Number USA Mcafee desktop web proxy support Mcafee antivirus definitions Mcafee customer service australia Mcafee business premium tech support Mcafee products customer service Mcafee spyware customer service Mcafee endpoint support Mcafee Antivirus Tech Support Number USA customer care toll free number ++ 1-855-855-6595 ++ high tech Mcafee ma Mcafee customer support 360 Phone number ++ 1-855-855-6595 ++ canada Mcafee sales customer service Mcafee customer care us fake Mcafee tech support Mcafee customer support online chat Mcafee Antivirus Tech Support Number USA customer service 360 Phone number ++ 1-855-855-6595 ++ usa Mcafee books customer service Mcafee technician toolkit Mcafee account customer service Mcafee ghost 15 tech support Mcafee utilities tech support Mcafee customer care Mcafee os support Mcafee tech service Mcafee antivirus download 2015 Mcafee customer reviews heidi Mcafee info-tech Mcafee technical institute Mcafee customer support canada Mcafee Antivirus Tech Support Number USA technical specifications gfi Mcafee business support phone number Mcafee Antivirus Tech Support Number USA customer service uk Mcafee tech support number usa Mcafee technical support 360 Phone number australia Mcafee customer service Mcafee lambrianos attorneys customer service Mcafee customer care number ++ 1-855-855-6595 ++ usa customer support 360 Phone number for Mcafee 360 Mcafee help support Mcafee support business Mcafee internet customer service number ++ 1-855-855-6595 ++ Mcafee smartwork customer service Mcafee support uk tele360 Phone Mcafee software customer service uk Mcafee customer service 360 Phone number ++ 1-855-855-6595 ++ USA Mcafee.com technical support Mcafee business premium support chat Mcafee customer service support Mcafee subscription customer service Mcafee technical ceramics Mcafee healthcare billing customer service Mcafee tech support online chat Mcafee business premium support number Mcafee 360 support 360 Phone number usa Mcafee technical support canada kaplan Mcafee customer value proposition does Mcafee support xp Mcafee helpline 360 Phone number ++ 1-855-855-6595 ++ uk Mcafee customer service in spanish Mcafee technical support australia Mcafee support online Mcafee technical support nz Mcafee one customer support Mcafee tele 360 Phone customer service bianca Mcafee virginia tech Mcafee tech support virginia tech Mcafee Antivirus Tech Support Number USA Mcafee online backup tech support Mcafee customer service get human Mcafee online backup customer service Mcafee email security exchange support Mcafee technical support knowledge base Mcafee door customer service Mcafee support number australia Mcafee security customer service uk Mcafee support uk Mcafee 360 tech support 360 Phone number australia Mcafee technical maintenance marjorie Mcafee virginia tech contact Mcafee customer service by 360 Phone Mcafee support chat
Re: as allows too many registers for vldm/vstm (ARMv7/8)
On 1.8.2016 16:26, Mike Frysinger wrote: could you file a bug please here: https://sourceware.org/bugzilla/ make sure to include a small test case that can be assembled Done. Sorry, I was wrong about vldm/vstm; I was certain that I did check those, too, but clearly I was wrong as they get the proper treatment. However, vpush/vpop are not checked and they'll end up generating bad opcode. -- Pekka ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20429] New: ARM: too many registers allowed for vpush/vpop
https://sourceware.org/bugzilla/show_bug.cgi?id=20429
Bug ID: 20429
Summary: ARM: too many registers allowed for vpush/vpop
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: pexu at sourceware dot mail.kapsi.fi
Target Milestone: ---
Created attachment 9418
--> https://sourceware.org/bugzilla/attachment.cgi?id=9418&action=edit
vpush and vpop with too many D and Q registers
as doesn't currently check that no more than 16 D or 8 Q registers are given
for vpush and vpop instructions. This limit is mandated by ARMv7 and ARMv8
architecture specifications.
as does, though, properly check the above limit for vldm and vstm instructions
(do_neon_ldm_stm). However, do_vfp_nsyn_push or do_vfp_nsyn_pop do not check
that the number of D or Q registers do not exceed the limit.
Moreover, vpush and vpop mnemonics are currently considered "unique to VFP" in
the source code. This is likely wrong, as e.g. ARM compiler toolchain assembler
reference at least since 2010 (v4.1) categorises these instructions as shared
between NEON and VFP (and mentions the D/Q register limitation).
Attached test file.
as -march=armv7-a -mfpu=neon vpushpop.S && objdump a.out
Should catch and reject all vpush/vpop instructions in the file. Currently
assembles as:
<.text>:
0: ed2d0b40vpush {d0-d31}
4: ed2d1b22vpush {d1-d17}
8: ecbd1b22vpop{d1-d17}
c: ecbd0b40vpop{d0-d31}
10: ed2d0b40vpush {d0-d31}
14: ed2d2b24vpush {d2-d19}
18: ecbd2b24vpop{d2-d19}
1c: ecbd0b40vpop{d0-d31}
in which all the instructions will raise undefined instruction exception, as
imm8 (i.e. the number of push/pop'd registers [times two]) is out of range.
--
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
