[Bug ld/19662] New: elf_link_sort_relocs is insufficient

2016-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19662

Bug ID: 19662
   Summary: elf_link_sort_relocs is insufficient
   Product: binutils
   Version: 2.27 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

elf_link_sort_relocs is called by

 if (dynamic && info->combreloc && dynobj != NULL)
relativecount = elf_link_sort_relocs (abfd, info, );

There are cases where relocations aren't sorted:

1. When -z nocombreloc is used.
2. Some targets, like x86, have:

  [ 8] .rel.dyn  REL 080494b0 0014b0 38 08   A  4   0 
4
  [ 9] .rel.plt  REL 080494e8 0014e8 0003d0 08  AI  4  21 
4

with z combreloc.  .rel.plt aren't get sorted.

-- 
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/19661] [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL

2016-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19661

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
Please provide an ELF object file as the input for "objdump -d".

-- 
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/19660] [libopcodes] [x86] REP prefixes shown incorrectly

2016-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19660

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
Please provide an ELF object file as the input for "objdump -d".

-- 
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/19659] [libopcodes] Segmentation fault on print_insn_i386

2016-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19659

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
Please provide an ELF object file as the input for "objdump -d".

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


Incorrect warning for AVX512 gathers

2016-02-18 Thread Steve Vormwald
On the current tip of binutils-2_26-branch, gas is emitting an incorrect 
warning 'Warning: index and destination registers should be distinct' when the 
two zmm registers are separated by 16.  For exmaple, zmm19 and zmm3 in 
'vgatherqpd  (%rax,%zmm19,8), %zmm3 {%k1}'.  This warning was added in 
commit 8444f82a1d163171deccfcf014cc31adb81f703b.  The problem appears to be 
that the register_number() function in gas/config/tc-i386.c doesn't check for 
RegVRex flag like it does for the RegRex flag, leading to aliasing issues 
between the low and high 16 registers.

Steven Vormwald
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug admin/19657] CERTIFICATE

2016-02-18 Thread WPGBLASANTHA at hotmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19657

WELIGAMA PALALLAPALLIYA GURUGE BUDDHIKA LASANTHA  changed:

   What|Removed |Added

URL||HTTP://WWW.USCIS.GOV
 CC||WPGBLASANTHA at hotmail dot com

--- Comment #2 from WELIGAMA PALALLAPALLIYA GURUGE BUDDHIKA LASANTHA 
 ---
I AM A ARMY/DIA EMPLOYEE AND WORKING IN SRI LANKA.
CONFIRM THE CERTIFICATE.

-- 
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/19661] New: [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL

2016-02-18 Thread njholcomb at wi dot rr.com
https://sourceware.org/bugzilla/show_bug.cgi?id=19661

Bug ID: 19661
   Summary: [libopcodes] [x86] Lock prefixes are allowed even when
they SIGILL
   Product: binutils
   Version: 2.27 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: njholcomb at wi dot rr.com
  Target Milestone: ---

Lock prefixes are also allowed even when they cause an Illegal Instruction
signal. Lock prefixes should require a memory operand, but libopcodes will
produce code like:

lock mov bh, 0x9f

-- 
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/19660] New: [libopcodes] [x86] REP prefixes shown incorrectly

2016-02-18 Thread njholcomb at wi dot rr.com
https://sourceware.org/bugzilla/show_bug.cgi?id=19660

Bug ID: 19660
   Summary: [libopcodes] [x86] REP prefixes shown incorrectly
   Product: binutils
   Version: 2.27 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: njholcomb at wi dot rr.com
  Target Milestone: ---

The rep prefixes only affects string instructions (like scas, movs, etc.), yet
these are shown in other cases, such as:

repz loopne 0x5b

-- 
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 admin/19657] CERTIFICATE

2016-02-18 Thread ppluzhnikov at google dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19657

Paul Pluzhnikov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Paul Pluzhnikov  ---
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 ld/19617] ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols

2016-02-18 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=19617

--- Comment #6 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c304e18e5ca825f57963bd0c5f022fa8f5797b29

commit c304e18e5ca825f57963bd0c5f022fa8f5797b29
Author: H.J. Lu 
Date:   Thu Feb 18 07:48:57 2016 -0800

Enable PR ld/19617 tests only for Linux/GNU/Solaris

Since PR ld/19617 tests require share library support, enable them
only for Linux/GNU/Solaris targets.

* testsuite/ld-elf/pr19617a.d: Enable only for *-*-linux*,
*-*-gnu* and *-*-solaris*.
* testsuite/ld-elf/pr19617b.d: Likewise.
* testsuite/ld-elf/pr19617c.d: Likewise.

-- 
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 admin/19657] New: CERTIFICATE

2016-02-18 Thread WPGBLASANTHA at hotmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19657

Bug ID: 19657
   Summary: CERTIFICATE
   Product: binutils
   Version: 2.27 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: admin
  Assignee: unassigned at sourceware dot org
  Reporter: WPGBLASANTHA at hotmail dot com
  Target Milestone: ---

-- 
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/19617] ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols

2016-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=19617

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.27

--- Comment #5 from H.J. Lu  ---
Fixed for 2.27.

-- 
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/19617] ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols

2016-02-18 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=19617

--- Comment #4 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bf89386a862ace008f0152bca8bddf996d3993c8

commit bf89386a862ace008f0152bca8bddf996d3993c8
Author: H.J. Lu 
Date:   Thu Feb 18 03:13:19 2016 -0800

Always create dynamic sections for -E/--dynamic-list

In embedded environments, including boot loaders, the non-PIC executable
needs to export its symbols to modules loaded in the future.  We should
always create dynamic sections for -E/--dynamic-list.

bfd/

PR ld/19617
* elflink.c (elf_link_add_object_symbols): Always create dynamic
sections for -E/--dynamic-list.

ld/

PR ld/19617
* testsuite/ld-elf/pr19617.s: New file.
* testsuite/ld-elf/pr19617a.d: Likewise.
* testsuite/ld-elf/pr19617b.d: Likewise.
* testsuite/ld-elf/pr19617c.d: Likewise.

-- 
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: OCTETS_PER_BYTE and Gas

2016-02-18 Thread Nick Clifton
Hi Dan,

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

Thanks for sending us this patch.  I have decided to apply the changes to 
the alignment functions, but not to the LEB128 encoding functions.  The 
reason for this is that the LEB128 functions currently pack only a single
octet into a byte, which is terribly wasteful for targets such as yours,
but this is how the DWARF spec appears to define the encoding operation.
Changing the functions to pack multiple octets into a single byte (where
possible) would be a much more extensive change, and probably contravene
the DWARF standard.


> Without these changes, the assembler would crash with some strange bugs.

I would be interested to know more about these crashes.

Note - we already support two targets where OCTETS_PER_BYTE_POWER is 2 
(tic4x and tic54x), so I would hope that in general we have the octets
vs bytes thing sorted out.


Attached is the patch that I am going to apply.

Cheers
  Nick

gas/ChangeLog
2016-02-18  Dan Gisselquist  
Nick Clifton  

* read.c (finish_bundle): Avoid recording a negative alignment.
(do_align): Use unsigned values for n, len and max.  Only create
a frag if the alignment requirement is greater than the minimum
byte alignment.  Avoid recording a negative alignment.
(s_align): Use unsigned values where appropriate.
(bss_alloc): Use an unsigned value for the alignment.
(sizeof_sleb128): Add a comment noting that we encode one octet
per byte, regardless of the value of OCTETS_PER_BYTE_POWER.
(emit_leb129_expr): Abort if the emitted encoding was longer than
expected.
* read.h (output_leb128): Update prototype.
(sizeof_leb128): Update prototype.
(bss_alloc): Update prototype.
* write.c (record_alignment): Use an unsigned value for the
alignment.  Do not record alignments less than the minimum
alignment for a byte.
* write.h (record_alignment): Update prototype.

diff --git a/gas/read.c b/gas/read.c
index 5c04789..f8fff78 100644
--- a/gas/read.c
+++ b/gas/read.c
@@ -238,7 +238,6 @@ static unsigned int bundle_lock_depth;
 #endif
 
 static void do_s_func (int end_p, const char *default_prefix);
-static void do_align (int, char *, int, int);
 static void s_align (int, int);
 static void s_altmacro (int);
 static void s_bad_end (int);
@@ -685,7 +685,8 @@ finish_bundle (fragS *frag, unsigned int size)
   /* 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
@@ -736,6 +737,75 @@ single instruction is %u bytes long but .bundle_align_mode limit is %u"),
 
 #endif  /* HANDLE_BUNDLE */
 
+static bfd_boolean
+in_bss (void)
+{
+  flagword flags = bfd_get_section_flags (stdoutput, now_seg);
+
+  return (flags & SEC_ALLOC) && !(flags & (SEC_LOAD | SEC_HAS_CONTENTS));
+}
+
+/* Guts of .align directive:
+   N is the power of two to which to align.  A value of zero is accepted but
+ignored: the default alignment of the section will be at least this.
+   FILL may be NULL, or it may point to the bytes of the fill pattern.
+   LEN is the length of whatever FILL points to, if anything.  If LEN is zero
+but FILL is not NULL then LEN is treated as if it were one.
+   MAX is the maximum number of characters to skip when doing the alignment,
+or 0 if there is no maximum.  */
+
+static void
+do_align (unsigned int n, char *fill, unsigned int len, unsigned int max)
+{
+  if (now_seg == absolute_section || in_bss ())
+{
+  if (fill != NULL)
+	while (len-- > 0)
+	  if (*fill++ != '\0')
+	{
+	  if (now_seg == absolute_section)
+		as_warn (_("ignoring fill value in absolute section"));
+	  else
+		as_warn (_("ignoring fill value in section `%s'"),
+			 segment_name (now_seg));
+	  break;
+	}
+  fill = NULL;
+  len = 0;
+}
+
+#ifdef md_flush_pending_output
+  md_flush_pending_output ();
+#endif
+
+#ifdef md_do_align
+  md_do_align (n, fill, len, max, just_record_alignment);
+#endif
+
+  /* Only make a frag if we HAVE to...  */
+  if ((n > OCTETS_PER_BYTE_POWER) && !need_pass_2)
+{
+  if (fill == NULL)
+	{
+	  if (subseg_text_p (now_seg))
+	frag_align_code (n, max);
+	  else
+	frag_align (n, 0, max);
+	}
+  else if (len <= 1)
+	frag_align (n, *fill, max);
+  else
+	frag_align_pattern (n, fill, len, max);
+}
+
+#ifdef md_do_align
+