[Bug binutils/20553] Bug in objdump when disassembling fmul, fmla and fmls

[jiwang at gcc dot gnu.org]

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 ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[sbergman at redhat dot com]

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 ld/20551] Cygwin64: ld: infinite loop when linking a shared library from objects compiled with std=c++14

[nickc at redhat dot com]

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

[nickc at redhat dot com]

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/20528] ld -r doesn't handle SHF_EXCLUDE section properly

[nickc at redhat dot com]

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 (_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

Re: [Bug ld/20528] ld -r doesn't handle SHF_EXCLUDE section properly

[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 (_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 binutils/20637] 32-bit XOP instructions should silently ignore REX_B

[ram...@hex-rays.com]

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

[Bug binutils/20637] 32-bit XOP instructions should silently ignore REX_B

[amit.pawar at amd dot com]

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 ld/20636] [arm] ld crash when linking glibc unwind code

[nickc at redhat dot com]

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 ld/20636] [arm] ld crash when linking glibc unwind code

[cvs-commit at gcc dot gnu.org]

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 binutils/20637] 32-bit XOP instructions should silently ignore REX_B

[amit.pawar at amd dot com]

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 gas/20641] powerpc: Should not allow three-operand cmp[l][i]

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20641

--- Comment #4 from Alan Modra  ---
dcbf needs to keep its L field optional.  dcbf is used in the kernel and in
glibc without L.  Also tlbie and tlbiel ought to be optional, I think, because
earlier versions of these insns lacked the L field.

tbegin. is used in the kernel tools/testing/selftests/tm/ files without the R
field, and similarly in the gas testsuite.  I'm unsure about making that one
compulsory.  It seems reasonable to allow omission of the "Roll-back only"
modifier..

So..  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.

-- 
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