[Bug gas/22871] Encode instructions of 64-bit operand without the REX_W bit

[jbeulich at novell dot com]

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

--- Comment #6 from Jan Beulich  ---
(In reply to H.J. Lu from comment #5)
> I updated users/hjl/optimize branch to encode
> 
> testq $imm31, mem
> 
> as
> 
> testl $imm31, mem
> 
> only at -O2.

I was about to suggest that, also because the memory access pattern changes
(the shorter access may not fault when the longer one would, not to think of
side effects when accessing MMIO). I'd even consider moving this higher up, to
-O3.

Another thing to consider here would be to encode e.g. vxorps %zmmM, %zmmM,
%zmmN as vxorps %xmmM, %xmmM, %xmmN for the low 16 registers, as that'll be VEX
encodable, i.e. shorter than the default EVEX variant. Same for vandnps (and of
course all their flavors dealing with different data types).

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Jan Beulich from comment #6)
> (In reply to H.J. Lu from comment #5)
> > I updated users/hjl/optimize branch to encode
> > 
> > testq $imm31, mem
> > 
> > as
> > 
> > testl $imm31, mem
> > 
> > only at -O2.
> 
> I was about to suggest that, also because the memory access pattern changes
> (the shorter access may not fault when the longer one would, not to think of
> side effects when accessing MMIO). I'd even consider moving this higher up,
> to -O3.

Good point.  I will remove "testq $imm31, mem".  I will add
"test{q,l,w} $imm8,%r{64,32,16}" to "testb $imm8,%r8" to -O3.

> Another thing to consider here would be to encode e.g. vxorps %zmmM, %zmmM,
> %zmmN as vxorps %xmmM, %xmmM, %xmmN for the low 16 registers, as that'll be
> VEX encodable, i.e. shorter than the default EVEX variant. Same for vandnps
> (and of course all their flavors dealing with different data types).

We can do it at -O2.

-- 
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/22874] New: GAS does not emit multibyte nops before a function symbol

[mliska at suse dot cz]

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

Bug ID: 22874
   Summary: GAS does not emit multibyte nops before a function
symbol
   Product: binutils
   Version: 2.31 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: mliska at suse dot cz
  Target Milestone: ---

$ cat nops.c
void
__attribute__((aligned(128)))
foo (int invariant)
{
  for (;;)
;
}

void
__attribute__((aligned(64)))
foo2 (int invariant)
{
}


int main() {}

$ gcc nops.c -O2
$ objdump -S a.out
[snip]
004004b0 <__do_global_dtors_aux>:
  4004b0:   80 3d 71 0b 20 00 00cmpb   $0x0,0x200b71(%rip)#
601028 <__TMC_END__>
  4004b7:   75 17   jne4004d0
<__do_global_dtors_aux+0x20>
  4004b9:   55  push   %rbp
  4004ba:   48 89 e5mov%rsp,%rbp
  4004bd:   e8 7e ff ff ff  callq  400440 
  4004c2:   c6 05 5f 0b 20 00 01movb   $0x1,0x200b5f(%rip)#
601028 <__TMC_END__>
  4004c9:   5d  pop%rbp
  4004ca:   c3  retq   
  4004cb:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
  4004d0:   f3 c3   repz retq 
  4004d2:   0f 1f 40 00 nopl   0x0(%rax)
  4004d6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  4004dd:   00 00 00 

004004e0 :
  4004e0:   55  push   %rbp
  4004e1:   48 89 e5mov%rsp,%rbp
  4004e4:   5d  pop%rbp
  4004e5:   eb 89   jmp400470 
  4004e7:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  4004ee:   00 00 00 
  4004f1:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  4004f8:   00 00 00 
  4004fb:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

00400500 :
  400500:   eb fe   jmp400500 
  400502:   90  nop
  400503:   90  nop
  400504:   90  nop
  400505:   90  nop
  400506:   90  nop
  400507:   90  nop
  400508:   90  nop
  400509:   90  nop
  40050a:   90  nop
  40050b:   90  nop
  40050c:   90  nop
  40050d:   90  nop
  40050e:   90  nop
  40050f:   90  nop
  400510:   90  nop
  400511:   90  nop
  400512:   90  nop
  400513:   90  nop
  400514:   90  nop
  400515:   90  nop
  400516:   90  nop
  400517:   90  nop
  400518:   90  nop
  400519:   90  nop
  40051a:   90  nop
  40051b:   90  nop
  40051c:   90  nop
  40051d:   90  nop
  40051e:   90  nop
  40051f:   90  nop
  400520:   90  nop
  400521:   90  nop
  400522:   90  nop
  400523:   90  nop
  400524:   90  nop
  400525:   90  nop
  400526:   90  nop
  400527:   90  nop
  400528:   90  nop
  400529:   90  nop
  40052a:   90  nop
  40052b:   90  nop
  40052c:   90  nop
  40052d:   90  nop
  40052e:   90  nop
  40052f:   90  nop
  400530:   90  nop
  400531:   90  nop
  400532:   90  nop
  400533:   90  nop
  400534:   90  nop
  400535:   90  nop
  400536:   90  nop
  400537:   90  nop
  400538:   90  nop
  400539:   90  nop
  40053a:   90  nop
  40053b:   90  nop
  40053c:   90  nop
  40053d:   90  nop
  40053e:   90  nop
  40053f:   90  nop

00400540 :
  400540:   f3 c3   repz retq 
  400542:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  400549:   00 00 00 
  40054c:   0f 

[Bug gas/22014] as(1) in microMIPS mode: illegal use of memcpy with overlapping addresses

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nickc at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Nick Clifton  ---
Hi A. Wilcox,

  Oops - sorry for missing this.

  I have now applied your patch and checked it in to the mainline.
  I will check it in to the 2.29 branch too, but there appears to
  be a locking problem at moment...

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/22875] New: Strip complains about and then destroys unrecognised relocs

[nickc at redhat dot com]

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

Bug ID: 22875
   Summary: Strip complains about and then destroys unrecognised
relocs
   Product: binutils
   Version: 2.31 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: nickc at redhat dot com
  Target Milestone: ---

Hi Guys,

If strip encounters a relocation that it does not recognise, it issues a
warning message, and then proceeds to replace the relocation with a null
version.  It then completes successfully, even though it has now produced a
corrupt binary.

For example, consider this test:

  % cat unknown-reloc.s
.text
  foo:
.dc.l0x12345678

.section .rela.text
.dc.l0
.dc.l0
.dc.l0x12345678
.dc.l0

.dc.l0
.dc.l0
.dc.l0
.dc.l0

  % as unknown-reloc.s -o unknown-reloc.o

  % readelf -r unknown-reloc.o
  Relocation section '.rela.text' at offset 0x44 contains 1 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
    12345678 unrecognized: 123456780

  % strip -g unknown-reloc.o
  strip: bad-reloc.o: invalid relocation type 120

  % echo $?
  0

  % readelf -r unknown-reloc.o
  Relocation section '.rela.text' at offset 0xc8 contains 1 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
     R_X86_64_NONE0

This is not just a theoretical problem.  We (Red Hat) recently had a user
report
that they were seeing corrupt binaries, and the problem turned out to be that
they were compiling using a toolchain with a 2.28 assembler that produced 
R_X86_64_REX_GOTPCRELX relocations, but using a version of strip that came from
the 2.25 binutils release.

There are at least two bugs here:

  * strip should not replace relocations that it does not recognise.
  * strip should either accept and ignore unknown relocations, or, if
   it must, complain about them, leave the input alone, and return an
   exit failure status.

I am filing this bug as a reminder to myself to investigate and fix the
problems.  That is unless somebody else does it first... :-)

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/22871] Encode instructions of 64-bit operand without the REX_W bit

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
I updated users/hjl/optimize branch to fix "andq $foo, %rax"
and remove "testq $imm31, mem".

-- 
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/22875] Strip complains about and then destroys unrecognised relocs

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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/22014] as(1) in microMIPS mode: illegal use of memcpy with overlapping addresses

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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=39334a61e63321352304cbae77b37fcba4fed662

commit 39334a61e63321352304cbae77b37fcba4fed662
Author: A. Wilcox 
Date:   Thu Feb 22 12:49:49 2018 +

Fix memory access violation when attempting to shorten a suffixed micromips
instruction during lookup.

PR 22014
* config/tc-mips.c (mips_lookup_insn): Use memmove to strip the
instruction size suffix.

-- 
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/22874] GAS does not emit multibyte nops before a function symbol

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  ---
The limit of multibyte nop for code alignment is

#define MAX_MEM_FOR_RS_ALIGN_CODE  31

-- 
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/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu

[pbrobinson at gmail dot com]

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

Peter Robinson  changed:

   What|Removed |Added

 CC||pbrobinson at gmail dot com

-- 
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/22014] as(1) in microMIPS mode: illegal use of memcpy with overlapping addresses

[awilfox at adelielinux dot org]

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

--- Comment #6 from A. Wilcox  ---
Thank you for merging this.

Does the master commit bring this to the 2.30 branch as well, or will there be
no further releases of 2.30?

-- 
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/22870] slow aarch64 assembler for source with lots of .loc directives

[aoliva at sourceware dot org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at sourceware dot org

--- Comment #4 from Alexandre Oliva  ---
IIRC it already does that; it only emits symbolic expressions when, at the time
it sees the .loc directive, it can't yet determine whether . > .LVL(#-1) (IOW,
have we advanced PC since the previous view in the same subsection?).  If we
can do more to resolve these early, we will certainly cut short the expression
bloat and dep chain.

Now, even if we can't determine that earlier, we could still do better.  We
multiply the negation of the above by (.LVU# + 1) (IOW, the successor to the
previous view).  If the multiplication could take a shortcut if one of the
operands is found to be zero (it often will be, in this particular case) and
resolve the result to zero (not necessarily for good, since relaxing might turn
an align to nothing), we'd get much shorter evaluations overall.

If optimizing multiplication is no good, maybe we could introduce a ternary
operator for internal use, for use in this case?


All that said, GCC will soon cut the chains short at function entry points,
where it will force a view reset.  This should shrink the chain lengths
significantly, but I guess we can still use any of the suggested above to
improve it so we only hit the O(2^n) case with small n.

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[torva...@linux-foundation.org]

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

--- Comment #9 from Linus Torvalds  ---
I already pointed this out in email to hjl, but adding it to the bugzilla too,
in case people want to track it:

There are a few more common cases that can use the REX.W optimization, notably

 movq $imm,%reg

and there it actually allows the whole unsigned 32-bit range, so it changes the
immediate logic a bit.

Right now gas generates a 10-byte instruction for

movq $0x87654321,%rax

in the form of

   0: 48 b8 21 43 65 87 00 movabs $0x87654321,%rax
   7: 00 00 00

but you can actually do it with just 5 bytes:

   0: b8 21 43 65 87mov$0x87654321,%eax

instead. Note that the C7/0 instruction with REX.W wasn't used,
because it sign-extends the 32-bit constant.

But even when the constant *isn't* in the full 32-bit range and you can use
C7/0 to avoid the long constant, gas currently picks a non-optimal instruction:

movq $0x77654321,%rax

becomes

   0: 48 c7 c0 21 43 65 77 mov$0x77654321,%rax

which is 7 bytes, even though (again) that 5-byte 32-bit mov would
have sufficed:

   0: b8 21 43 65 77mov$0x77654321,%eax

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[torva...@linux-foundation.org]

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

--- Comment #10 from Linus Torvalds  ---
(In reply to H.J. Lu from comment #7)
> 
> Good point.  I will remove "testq $imm31, mem".  I will add
> "test{q,l,w} $imm8,%r{64,32,16}" to "testb $imm8,%r8" to -O3.

I'm assuming that you  limit the immediate to just 7 bits for the testb case. 

But I think you can do the register versions at -O2. Unlike the memory ops,
there are no faulting behaviors there.

-- 
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/22870] slow aarch64 assembler for source with lots of .loc directives

[aoliva at sourceware dot org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at sourceware dot org   |aoliva at sourceware 
dot org

--- Comment #5 from Alexandre Oliva  ---
Mine, just awaiting some feedback on the proposed courses of action.

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[torva...@linux-foundation.org]

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

--- Comment #12 from Linus Torvalds  ---
(In reply to H.J. Lu from comment #11)
> 
> imm8 isn't sign-extended.  8 bits should work.

No, it's not sign-extended to the full size, but it doesn't work because you
change the sign bit in the flags in the _small_ size.

So you can't change

testq $255,%rdx

into

testb $255,%dl

because the flag end result is different.

The first instruction always has a positive result (since the resulting sign
bit in 64 bits is always zero). But the shortened version would be negative if
bit#7 in %dl is set.

Or am I missing something else?

-- 
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/22880] ./configure stalls forever if CC=clang

[bjornpagen at gmail dot com]

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

Bjorn Pagen  changed:

   What|Removed |Added

 CC||bjornpagen at gmail dot com
   Host||x86_64-gentoo-linux-musl

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Linus Torvalds from comment #10)
> (In reply to H.J. Lu from comment #7)
> > 
> > Good point.  I will remove "testq $imm31, mem".  I will add
> > "test{q,l,w} $imm8,%r{64,32,16}" to "testb $imm8,%r8" to -O3.
> 
> I'm assuming that you  limit the immediate to just 7 bits for the testb
> case. 
> 
> But I think you can do the register versions at -O2. Unlike the memory ops,
> there are no faulting behaviors there.

imm8 isn't sign-extended.  8 bits should work.

-- 
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/22874] GAS does not emit multibyte nops before a function symbol

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com
   Severity|normal  |enhancement

--- Comment #2 from Alan Modra  ---
Those nops are emitted by the linker, not the assembler.  We currently have no
generic infrastructure for emitting fancy nop sequences in linker generated
padding, but see emultempl/ppc32elf.em:no_zero_padding.

However, I question whether emitting multi-byte nops in padding on x86 is a
good idea.  If you somehow execute those nops, what happens when you jump into
the middle of a multi-byte nop?

-- 
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/22874] GAS does not emit multibyte nops before a function symbol

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra  ---
Argh, I wish I could delete comments..  Same source file, these are indeed gas
inserted nops.

-- 
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/22880] New: ./configure stalls forever if CC=clang

[bjornpagen at gmail dot com]

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

Bug ID: 22880
   Summary: ./configure stalls forever if CC=clang
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: bjornpagen at gmail dot com
  Target Milestone: 2.31
Target: x86_64-gentoo-linux-musl

Created attachment 10843
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10843=edit
Here is my patch to fix the issue

Binutils 2.29 and 2.30 both do not pass ./configure with CC=clang. When
./configure is run, it stalls when it reaches "checking whether the compiler
driver understands Ada...", and does not continue.

I have also identified the cause. The bug is caused by a test for an edge case
for a gcc earlier than gcc-3. If this snippet of code is remove from
./configure, then the configure process continues as normal and binutils is
compiled flawlessly.

[...]
# There is a bug in old released versions of GCC which causes the
# driver to exit successfully when the appropriate language module
# has not been installed.  This is fixed in 2.95.4, 3.0.2, and 3.1.
# Therefore we must check for the error message as well as an
# unsuccessful exit.
# Other compilers, like HP Tru64 UNIX cc, exit successfully when
# given a .adb file, but produce no object file.  So we must check
# if an object file was really produced to guard against this.
errors=`(${CC} -c conftest.adb) 2>&1 || echo failure`
if test x"$errors" = x && test -f conftest.$ac_objext; then
  acx_cv_cc_gcc_supports_ada=yes
fi
[...]

-- 
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/22871] Encode instructions of 64-bit operand without the REX_W bit

[jbeulich at novell dot com]

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

--- Comment #13 from Jan Beulich  ---
One more pair of cases to consider is conversion of word/dword/qword add/sub
with an immediate of 128 to sub/add with -128 as immediate.

-- 
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/22014] as(1) in microMIPS mode: illegal use of memcpy with overlapping addresses

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_29-branch branch has been updated by Nick Clifton
:

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

commit 96a94bd954f0e1078ed214b5f68de5a28ec6a8c6
Author: A. Wilcox 
Date:   Thu Feb 22 13:00:36 2018 +

Fix memory corruption when using memcpy to overwtite a string in place.

PR 22014
* config/tc-mips.c (mips_lookup_insn): Use memmove to strip the
instruction size suffix.

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