[Bug binutils/20637] 32-bit XOP instructions should silently ignore REX_B
https://sourceware.org/bugzilla/show_bug.cgi?id=20637 --- Comment #2 from Amit Pawar --- Ramiro, can you please provide the testcase and will try to verify. Thanks. -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 --- Comment #9 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=9eaff8613893f063400fdae95bc382ab33685e3b commit 9eaff8613893f063400fdae95bc382ab33685e3b Author: Akihiko Odaki Date: Wed Sep 28 11:50:41 2016 +0100 Fix seg-fault in the linker introduced by the previous delta. PR ld/20636 * elf-bfd.h (struct elf_backend_data): Delete elf_backend_count_output_relocs callback and add elf_backend_update_relocs. * elf32-arm.c (elf32_arm_count_output_relocs): Deleted. (emit_relocs): Deleted. (elf32_arm_emit_relocs): Deleted. (elf_backend_emit_relocs): Updated not to use the old functions. (elf32_arm_update_relocs): New function. (elf_backend_update_relocs): New define. * elflink.c (bfd_elf_final_link): Add additional_reloc_count to the relocation count. Call elf_backend_emit_relocs. (_bfd_elf_size_reloc_section): Do not call elf_backend_count_output_relocs. * elfxx-target.h (elf_backend_count_output_relocs): Deleted. (elf_backend_update_relocs): New define. -- 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/20636] [arm] ld crash when linking glibc unwind code
https://sourceware.org/bugzilla/show_bug.cgi?id=20636 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Nick Clifton --- I have applied Akihiko's patch, which is a much better way yo solve this problem. -- 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/20637] 32-bit XOP instructions should silently ignore REX_B
https://sourceware.org/bugzilla/show_bug.cgi?id=20637 --- Comment #3 from Amit Pawar --- Hi Ramior, Instruction syntax format vphsubwd xmm1, xmmword ptr [ebp-0x3e] -> in intel format vphsubwd -0x3e(%ebp),%xmm1 -> GNU AS format. If I assemble this in gas, instruction is encoded as "8f e9 78 e2 4d c2" (in 32 bit mode) but your hexdump upcode shows "8f c9 78 e2 4d c2" bytes for the same instruction. Checking the third byte shows difference in encoding. E9 in gas and C9 in your case. I verfied the steps give by you and the output is same as what you have mentioned. I have verified that gnu assembler is not allowing to encode in that manner. Can you please share the assembly testcase and also which assembler did you use it to generate the object file. I will try to look into that. -- 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/20637] 32-bit XOP instructions should silently ignore REX_B
https://sourceware.org/bugzilla/show_bug.cgi?id=20637 --- Comment #4 from Ramiro Polla --- Hi Amit, This sample comes from fuzzed data, hence why I provided the bytes directly. The instruction is still valid, though, but with ebp as register (REX_B should be silently ignored). Both XED and LLVM disassemble it correctly. -- 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 ld/20528] ld -r doesn't handle SHF_EXCLUDE section properly
Hi H.J.
> This works:
>
> diff --git a/ld/emultempl/elf32.em b/ld/emultempl/elf32.em
> index dd4d35a..6ce4e00 100644
> --- a/ld/emultempl/elf32.em
> +++ b/ld/emultempl/elf32.em
> @@ -1903,9 +1903,16 @@ gld${EMULATION_NAME}_place_orphan (asection *s,
> lang_insert_orphan to create a new output section. */
>constraint = SPECIAL;
>
> + /* SEC_EXCLUDE is ignored when doing a relocatable link. But
> + we can't merge 2 input sections with the same name when only
> + one of them has SHF_EXCLUDE. */
>if (os->bfd_section != NULL
>&& (os->bfd_section->flags == 0
> - || (((s->flags ^ os->bfd_section->flags)
> + || ((!bfd_link_relocatable (&link_info)
> + || (((elf_section_flags (s)
> + ^ elf_section_flags (os->bfd_section))
> + & SHF_EXCLUDE) == 0))
> + && ((s->flags ^ os->bfd_section->flags)
>& (SEC_LOAD | SEC_ALLOC)) == 0
> && _bfd_elf_match_sections_by_type (link_info.output_bfd,
> os->bfd_section,
Looks good to me too - please consider the patch approved.
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20528] ld -r doesn't handle SHF_EXCLUDE section properly
https://sourceware.org/bugzilla/show_bug.cgi?id=20528
--- Comment #2 from Nick Clifton ---
Hi H.J.
> This works:
>
> diff --git a/ld/emultempl/elf32.em b/ld/emultempl/elf32.em
> index dd4d35a..6ce4e00 100644
> --- a/ld/emultempl/elf32.em
> +++ b/ld/emultempl/elf32.em
> @@ -1903,9 +1903,16 @@ gld${EMULATION_NAME}_place_orphan (asection *s,
> lang_insert_orphan to create a new output section. */
>constraint = SPECIAL;
>
> + /* SEC_EXCLUDE is ignored when doing a relocatable link. But
> + we can't merge 2 input sections with the same name when only
> + one of them has SHF_EXCLUDE. */
>if (os->bfd_section != NULL
>&& (os->bfd_section->flags == 0
> - || (((s->flags ^ os->bfd_section->flags)
> + || ((!bfd_link_relocatable (&link_info)
> + || (((elf_section_flags (s)
> + ^ elf_section_flags (os->bfd_section))
> + & SHF_EXCLUDE) == 0))
> + && ((s->flags ^ os->bfd_section->flags)
>& (SEC_LOAD | SEC_ALLOC)) == 0
> && _bfd_elf_match_sections_by_type (link_info.output_bfd,
> os->bfd_section,
Looks good to me too - please consider the patch approved.
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/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it
https://sourceware.org/bugzilla/show_bug.cgi?id=20535 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |INVALID --- Comment #1 from Nick Clifton --- Hi Stephan, The problem here is that you are using environment variables which are not being expanded at link time. > $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos > -ldso1 This stores a DT_NEEDED string of "$ORIGIN" into libdso2.so. It does *not* store the expansion of $ORIGIN into the DT_NEEDED entry. > $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2 This makes the linker look in a directory path called "$ORIGIN/dsos", again with no expansion of $ORIGIN, which is why this approach also fails. (Note this behaviour is intended. The linker does not perform expansion of environment variables found in path names). This sequence does work: % setenv ORIGIN `pwd` % mkdir dsos % gcc -shared -fPIC -o dsos/libdso1.so dso1.c % gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath=$ORIGIN/dsos dso2.c -Ldsos -ldso1 % gcc main.c -Ldsos -ldso2 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/20551] Cygwin64: ld: infinite loop when linking a shared library from objects compiled with std=c++14
https://sourceware.org/bugzilla/show_bug.cgi?id=20551 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Zosrothko, Unfortunately the poco-c++11 branch does not exist in the repository you listed. Is there another branch that I can try, that will reproduce 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 ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it
https://sourceware.org/bugzilla/show_bug.cgi?id=20535 --- Comment #2 from Stephan Bergmann --- (In reply to Nick Clifton from comment #1) > The problem here is that you are using environment variables which are not > being expanded at link time. No, I'm not using environment variables. I'm rather using the $ORIGIN token supported by ld.so's rpath token expansion (see "man ld.so"). > > $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos > > -ldso1 > > This stores a DT_NEEDED string of "$ORIGIN" into libdso2.so. It does > *not* > store the expansion of $ORIGIN into the DT_NEEDED entry. I assume you mean DT_RPATH instead of DT_NEEDED? And that this creates a DT_RPATH of exactly "$ORIGIN" is expected. > > $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2 > > This makes the linker look in a directory path called "$ORIGIN/dsos", again > with no expansion of $ORIGIN, which is why this approach also fails. (Note > this behaviour is intended. The linker does not perform expansion of > environment variables found in path names). But when ld.so supports $ORIGIN (and some more special tokens) in DT_RPATH, wouldn't it be useful if ld did, too? (I just notice that I failed to add "-z origin" when using "-Wl,-rpath='$ORIGIN...", but even adding that to the two affected gcc invocations doesn't make a difference.) > This sequence does work: > > % setenv ORIGIN `pwd` > % mkdir dsos > % gcc -shared -fPIC -o dsos/libdso1.so dso1.c > % gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath=$ORIGIN/dsos dso2.c > -Ldsos -ldso1 That causes an absolute path be recorded into dso2's DT_RPATH, which is /not/ what is wanted. > % gcc main.c -Ldsos -ldso2 -- 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/20553] Bug in objdump when disassembling fmul, fmla and fmls
https://sourceware.org/bugzilla/show_bug.cgi?id=20553 Jiong Wang changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-28 CC||jiwang at gcc dot gnu.org Assignee|unassigned at sourceware dot org |jiwang at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jiong Wang --- Posted a patch here https://sourceware.org/ml/binutils/2016-09/msg00213.html (Forget to add "PR target/20553" in the change log, will add before committing if the patch get approved) -- 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/20641] powerpc: Should not allow three-operand cmp[l][i]
https://sourceware.org/bugzilla/show_bug.cgi?id=20641 --- Comment #5 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=a5721ba270ddf860e0e5a45bba456214e8eac2be commit a5721ba270ddf860e0e5a45bba456214e8eac2be Author: Alan Modra Date: Thu Sep 29 15:12:47 2016 +0930 Disallow 3-operand cmp[l][i] for ppc64 cmp[l][o] get an optional L field only when generating 32-bit code. dcbf, tlbie and tlbiel keep their optional L field, ditto for R field of tbegin. cmprb, tsr., wlcr[all] and mtsle all change to a compulsory L field. L field of dcbf and wclr is 2 bits. PR 20641 include/ * opcode/ppc.h (PPC_OPERAND_OPTIONAL32): Define. opcodes/ * ppc-opc.c (L): Make compulsory. (LOPT): New, optional form of L. (HTM_R): Define as LOPT. (L0, L1): Delete. (L32OPT): New, optional for 32-bit L. (L2OPT): New, 2-bit L for dcbf. (SVC_LEC): Update. (L2): Define. (insert_l0, extract_l0, insert_l1, extract_l2): Delete. (powerpc_opcodes ): Use L32OPT. : Use L2OPT. : Use LOPT. : Use L2. gas/ * config/tc-ppc.c (md_assemble): Handle PPC_OPERAND_OPTIONAL32. * testsuite/gas/ppc/power8.s: Provide tbegin. operand. * testsuite/gas/ppc/power9.d: Update cmprb disassembly. -- 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
