[Bug binutils/20700] [libopcodes][x86] Invalid suffix for xbegin
https://sourceware.org/bugzilla/show_bug.cgi?id=20700 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from H.J. Lu --- xbeginq is similar to retq. -- 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/20775] dd f0 is disassebled as fnop
https://sourceware.org/bugzilla/show_bug.cgi?id=20775 --- Comment #1 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=48c97fa1ba7d6628352fc2433abd91a41f6c8171 commit 48c97fa1ba7d6628352fc2433abd91a41f6c8171 Author: H.J. Lu Date: Mon Nov 7 14:58:38 2016 -0800 X86: Properly handle bad FPU opcode Since Bad_Opcode and FGRPd9_2 were the same in i386-dis.c, all Bad_Opcode entries in float_reg were displaced as FGRPd9_2. This patch adds an entry for Bad_Opcode in fgrps to avoid treating it as FGRPd9_2. gas/ PR binutils/20775 * testsuite/gas/i386/i386.exp: Run fpu-bad. * testsuite/gas/i386/fpu-bad.d: New file. * testsuite/gas/i386/fpu-bad.s: Likewise. opcodes/ PR binutils/20775 * i386-dis.c (FGRPd9_2): Replace 0 with 1. (FGRPd9_4): Replace 1 with 2. (FGRPd9_5): Replace 2 with 3. (FGRPd9_6): Replace 3 with 4. (FGRPd9_7): Replace 4 with 5. (FGRPda_5): Replace 5 with 6. (FGRPdb_4): Replace 6 with 7. (FGRPde_3): Replace 7 with 8. (FGRPdf_4): Replace 8 with 9. (fgrps): Add an entry for Bad_Opcode. -- 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/20775] dd f0 is disassebled as fnop
https://sourceware.org/bugzilla/show_bug.cgi?id=20775 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |FIXED Target Milestone|--- |2.28 --- Comment #2 from H.J. Lu --- 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
Re: objdump '--stop-address' option stop on a wrong ending address
On 07/11/2016 21:01, Andreas Schwab wrote: > On Nov 07 2016, Nick Clifton wrote: > >> Hi Florian, >> >>> I try to extract function assembly code with objdump using >>> "--start-address" and "--stop-address" options but the stop address stop >>> on the second to last address. >> >>> $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d >> >>>50c59: b8 01 00 00 00 mov$0x1,%eax >>>50c5e: c3 retq >>> >>> As you can see the last address is wrong. The assembly code stop on >>> 0x50c5e instead of 0x50c5f. >> >> Actually this is the intended behaviour. The --stop-address option >> specifies the address at which objdump should *stop* displaying data. >> So when objdump reaches address 50c5f it stops and does not display >> the disassembly for that address. >> >> In order to display the entire disassembly of a specific region you >> need to set the stop address to one more than the last address of the >> region concerned. > > But note that the region does end at 0x50c5f, so there is nothing more > to disassemble anyway. If we take a look to the whole assembly code of the "printf_size_info" functon. We can see à "nop" mnemonics at 0x50c5f before the next function. This was originally doubt about the "--stop-address" option dysfunction. 00050c40 : 50c40: 48 85 f6test %rsi,%rsi 50c43: 74 14 je 50c59 50c45: 0f b6 47 0c movzbl 0xc(%rdi),%eax 50c49: 83 e0 01and$0x1,%eax 50c4c: 3c 01 cmp$0x1,%al 50c4e: 19 c0 sbb%eax,%eax 50c50: 30 c0 xor%al,%al 50c52: 05 07 01 00 00 add$0x107,%eax 50c57: 89 02 mov%eax,(%rdx) 50c59: b8 01 00 00 00 mov$0x1,%eax 50c5e: c3 retq 50c5f: 90 nop But you're right Andreas. The "no operation" opcode can be skip. It doesn't raise a problem against the meaning of this function. Moreover the fully respect of the symbol definition seams to relate to a size of 0x1f (31 opcodes). In this case the function with the "nop" opcode te function is 0x20 long (32 opcodes). This "nop" opcode seams to be some padding added during the compilation process. > > Andreas. > Thank you for this advice. Florian 0x346BBA8F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20755] readelf: DWARF-5 support
https://sourceware.org/bugzilla/show_bug.cgi?id=20755
Jan Kratochvil changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Jan Kratochvil ---
Ongoing work before it gets submitted:
git://sourceware.org/git/archer.git
git diff archer/users/jkratoch/dwarf5gcc{,-gdb}
--
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: objdump '--stop-address' option stop on a wrong ending address
On Nov 07 2016, Nick Clifton wrote: > Hi Florian, > >> I try to extract function assembly code with objdump using >> "--start-address" and "--stop-address" options but the stop address stop >> on the second to last address. > >> $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d > >>50c59:b8 01 00 00 00 mov$0x1,%eax >>50c5e:c3 retq >> >> As you can see the last address is wrong. The assembly code stop on >> 0x50c5e instead of 0x50c5f. > > Actually this is the intended behaviour. The --stop-address option > specifies the address at which objdump should *stop* displaying data. > So when objdump reaches address 50c5f it stops and does not display > the disassembly for that address. > > In order to display the entire disassembly of a specific region you > need to set the stop address to one more than the last address of the > region concerned. But note that the region does end at 0x50c5f, so there is nothing more to disassemble anyway. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20781] e9 opcode wrong disassembling
https://sourceware.org/bugzilla/show_bug.cgi?id=20781 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 18386 *** -- 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/20780] e8 opcode wrong disassembling
https://sourceware.org/bugzilla/show_bug.cgi?id=20780 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 18386 *** -- 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/18386] callw with 0x66 prefix incorrectly disassembled in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18386 --- Comment #11 from H.J. Lu --- *** Bug 20780 has been marked as a duplicate of this bug. *** -- 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/18386] callw with 0x66 prefix incorrectly disassembled in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18386 --- Comment #10 from H.J. Lu --- *** Bug 20781 has been marked as a duplicate of this bug. *** -- 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/18386] callw with 0x66 prefix incorrectly disassembled in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18386 --- Comment #9 from H.J. Lu --- *** Bug 20783 has been marked as a duplicate of this bug. *** -- 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/20783] FF /4 (JMP Ev) wrong disassembling
https://sourceware.org/bugzilla/show_bug.cgi?id=20783 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 18386 *** -- 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/18386] callw with 0x66 prefix incorrectly disassembled in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18386 H.J. Lu changed: What|Removed |Added CC||anatolymik at gmail dot com --- Comment #8 from H.J. Lu --- *** Bug 20782 has been marked as a duplicate of this bug. *** -- 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/20782] FF /2 (CALL Ev) wrong disassembling
https://sourceware.org/bugzilla/show_bug.cgi?id=20782 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 18386 *** -- 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: objdump '--stop-address' option stop on a wrong ending address
On 07/11/2016 17:09, Nick Clifton wrote: > Hi Florian, Hi Nick > >> I try to extract function assembly code with objdump using >> "--start-address" and "--stop-address" options but the stop address stop >> on the second to last address. > >> $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d > >>50c59:b8 01 00 00 00 mov$0x1,%eax >>50c5e:c3 retq >> >> As you can see the last address is wrong. The assembly code stop on >> 0x50c5e instead of 0x50c5f. > > Actually this is the intended behaviour. The --stop-address option > specifies the address at which objdump should *stop* displaying data. > So when objdump reaches address 50c5f it stops and does not display > the disassembly for that address. > Sorry about my mistake. > In order to display the entire disassembly of a specific region you > need to set the stop address to one more than the last address of the > region concerned. So in your example: > > $ objdump --start-address=0x50c40 --stop-address=0x50c60 -d > > should work. Thank you, > > Cheers > Nick > Regards Florian 0x346BBA8F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objdump '--stop-address' option stop on a wrong ending address
Hi Florian, > I try to extract function assembly code with objdump using > "--start-address" and "--stop-address" options but the stop address stop > on the second to last address. > $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d >50c59: b8 01 00 00 00 mov$0x1,%eax >50c5e: c3 retq > > As you can see the last address is wrong. The assembly code stop on > 0x50c5e instead of 0x50c5f. Actually this is the intended behaviour. The --stop-address option specifies the address at which objdump should *stop* displaying data. So when objdump reaches address 50c5f it stops and does not display the disassembly for that address. In order to display the entire disassembly of a specific region you need to set the stop address to one more than the last address of the region concerned. So in your example: $ objdump --start-address=0x50c40 --stop-address=0x50c60 -d should work. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20784] [2.28 Regression] binutils fails to link a configure test on x86_64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=20784
Nick Clifton changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||nickc at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Nick Clifton ---
Hi Matthias,
Sorry about this bug. There were actually two problems - the infinite loop
when the code did not recognise a token in an rpath search directory, and the
fact that the code did not support curly braced enclosed tokens (ie ${ORIGIN}
and ${LIB}).
I have checked in a patch to fix both of these problems, and to add some
documentation in the ld.texinfo file as well. Please try out the updated
sources and reopen this bug report if there is a 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/20784] [2.28 Regression] binutils fails to link a configure test on x86_64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=20784 --- Comment #1 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=e680a6b69b4bd173a180419e973a9bf18a000151 commit e680a6b69b4bd173a180419e973a9bf18a000151 Author: Nick Clifton Date: Mon Nov 7 15:05:34 2016 + Fix infinite loop when processing rpath tokens. PR ld/20784 * emultempl/elf32.em (search_needed): Fix infinite loop when unable to process a token. Add support for curly braced enclosed tokens. * ld.texinfo (--rpath-link): Document supprot for $ORIGIN and $LIB. -- 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/20744] [PPC] Incorrect relocation for VLE-instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20744 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-07 CC||amodra at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Alan Modra --- Yes, and ld processes an R_PPC_VLE_HA16D reloc as if it were an R_PPC_VLE_HA16A reloc and vice-versa. So fixing this bug means we break object file compatibility. -- 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/20789] New: [avr] Relaxation does not correctly adjust DIFF reloc with negative value
https://sourceware.org/bugzilla/show_bug.cgi?id=20789 Bug ID: 20789 Summary: [avr] Relaxation does not correctly adjust DIFF reloc with negative value Product: binutils Version: 2.28 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: saaadhu at sourceware dot org Target Milestone: --- Addend adjustment for DIFF relocs does not occur if the difference expression is negative. As seen below, the difference is set correctly to -4 at assembly time. At link time, relaxation resizes the JMP to RJMP, but the difference in the linked ELF still stays at -4. $ cat test.s .L1: JMP .L1 .L2: .section .rodata.b,"a",@progbits b: .word .L1-(.L2) $ avr-as test.s -o test.o -mmcu=avr51 -mlink-relax $ avr-objdump -s test.o test.o: file format elf32-avr Contents of section .text: 0c94 Contents of section .rodata.b: fcff .. $ avr-ld test.o -mavr51 --relax $ avr-objdump -s a.out a.out: file format elf32-avr Contents of section .text: ffcf .. Contents of section .data: 800100 fcff .. Swapping the operands in the label difference (making the expression value positive) works. $ cat test.s .L1: JMP .L1 .L2: .section .rodata.b,"a",@progbits b: .word .L2-(.L1) .. $ avr-as test.s -o test.o -mmcu=avr51 -mlink-relax $ avr-objdump -s test.o test.o: file format elf32-avr Contents of section .text: 0c94 Contents of section .rodata.b: 0400 .. $ avr-ld test.o -mavr51 --relax $ avr-objdump -s a.out a.out: file format elf32-avr Contents of section .text: ffcf .. Contents of section .data: 800100 0200 .. -- 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/20789] [avr] Relaxation does not correctly adjust DIFF reloc with negative value
https://sourceware.org/bugzilla/show_bug.cgi?id=20789 Senthil Kumar Selvaraj changed: What|Removed |Added Status|NEW |ASSIGNED -- 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
