objdump for old ARM7TDMI (ARMv4T) showing instructions for newer architectures?!
Hello! I care about the success of GNU very much and wanted some feedback on what to do about a potential bug in objdump for ARM I'm examining the output of "objdump -D --target=binary -m arm7tdmi" and seeing instructions that do not exist on the ancient ARM7TDMI cores. For example, mrcc, blx and ldc2 only appeared in ARMv5 or later but I see them in the output with command line switches above. (I see same problems with "-m armv4t".) I'm using version 2.19.1-multiarch from Ubuntu 9.04. Is this a genuine bug or must I use different switches. Sincerely, chris ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
binutils-2.16.1 error when builing gcc-3.2.3 cross (target mipsel, host x86)
When trying to build a mipsel cross of gcc-3.2.3 (host x86) I get the error: Error: operation combines symbols in different segments it seems to be the issue discussed at: http://sources.redhat.com/ml/binutils/2004-05/msg00112.html I was unable to find wht resolution there is to this. Does anyone know if this is fixed and if so in which release(s)? Thanks, --cw ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
ld.texinfo bug in 2.16
I noticed this buglet while reading the hard copy: In section 2.1,
--hash-size has an @kindex but no @item, so you don't actually see the
option name in the text.
Also, a bit lower down is written "Another affect of the switch", and
this should be "effect".
Chris Metcalf
--
@@ -1795,6 +1795,7 @@
those options are only available for ELF systems.
@kindex [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Set the default size of the linker's hash tables to a prime number
close to @var{number}. Increasing this value can reduce the length of
time it takes the linker to perform its tasks, at the expense of
@@ -1808,7 +1809,7 @@
for link map file generation, rather than the new O(n) algorithm which uses
about 40% more memory for symbol storage.
-Another affect of the switch is to set the default hash table size to
+Another effect of the switch is to set the default hash table size to
1021, which again saves memory at the cost of lengthening the linker's
run time. This is not done however if the @option{--hash-size} switch
has been used.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
bug in bfd relocation overflow handling
It appears that if you have a 64-bit host targetting a 32-bit platform, the complain_overflow_bitfield case in _bfd_relocate_contents() will incorrectly generate an overflow error for negative constants. The "~fieldmask" gives you a whole lot of high one bits (for a 16-bit bitfield you get 0x). But, taking the value "a" to be some typical negative constant like -1 == 0x, ss becomes 0x, and doesn't equal ((bfd_vma) -1 >> rightshift) & signmask)) even though the expectation in this case is that it should. So I just cut signmask down with addrmask so it's 0x instead (where addrmask is the mask for the target bitsize). This bug is present in binutils-2.16.1. Chris Metcalf --- binutils-2.16.1/bfd/reloc.c.orig2005-11-30 14:49:23.0 -0500 +++ binutils-2.16.1/bfd/reloc.c 2005-11-30 14:52:32.0 -0500 @@ -1504,21 +1504,21 @@ case complain_overflow_bitfield: /* Much like the signed check, but for a field one bit wider, and no trimming inputs with addrmask. We allow a bitfield to represent numbers in the range -2**n to 2**n-1, where n is the number of bits in the field. Note that when bfd_vma is 32 bits, a 32-bit reloc can't overflow, which is exactly what we want. */ a >>= rightshift; - signmask = ~ fieldmask; + signmask = (~ fieldmask) & addrmask; ss = a & signmask; if (ss != 0 && ss != (((bfd_vma) -1 >> rightshift) & signmask)) flag = bfd_reloc_overflow; signmask = ((~ howto->src_mask) >> 1) & howto->src_mask; b = (b ^ signmask) - signmask; b >>= bitpos; sum = a + b; ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: bug in bfd relocation overflow handling
It's not a 32-bit relocation, it's a 16-bit relocation. Chris On 12/1/2005 12:27 AM, Alan Modra wrote: On Wed, Nov 30, 2005 at 03:02:25PM -0500, Chris Metcalf wrote: It appears that if you have a 64-bit host targetting a 32-bit platform, the complain_overflow_bitfield case in _bfd_relocate_contents() will The real bug is the 32-bit target using complain_overflow_bitfield on a 32-bit relocation. It should just simply use complain_overflow_dont. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
format string vulnerabilities in c++filt
Hi, There are two format string vulnerabilities in c++filt program of binutils. Line 66 printf (mangled_name); and line 71 printf (result); These are easily demonstrated by running c++filt on a symbol with the correct format specifiers: $./c++filt AAA%x.AAA%x.AAA%x.AAA%x.AAA AAAb.AAA804be40.AAA0.AAAbfbe82d0.AAA Thanks! chris http://em386.blogspot.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Directive .p2align Not As Documented
If I assemble the following assembly .text the .text section begins right after the elf header at 0x34 (as expected). However, .text .p2align 4,,1 makes the .text section begin at 0x40, ignoring the third expression, which is documented as If doing the alignment would require skipping more bytes than the specified maximum, then the alignment is not done at all Additionally, the assembly .text .p2align 4,0x90,1 ignores the fill value, as if it were left empty (adding zero padding bytes). Lastly, .text xor %eax, %eax .p2align 4,0x90,15 Once again ignores the fill value, as if it was left unspecified, padding the alignment with lea instructions. The lea instructions take less time to decode, however, the fill value field is documented as The second expression (also absolute) gives the fill value to be stored in the padding bytes. Clearly, the lea instructions are not the specified fill value. Sincerely, Chris P ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
ld should support --no-fatal-warnings
This turns out to be convenient in cases where one's build system
defaults to "ld --fatal-warning" but occasionally one would like to
override it. It's also parallel to existing gcc conventions for setting
and unsetting options. See attached diff to ld/lexsup.c; it's against
2.17 but patches OK against 2.18.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
//tilera/user/cmetcalf/branch/tools/gnu/ld/lexsup.c#2 -
/u/cmetcalf/p4/branch/tools/gnu/ld/lexsup.c
--- /tmp/tmp.23673.27 2008-05-30 13:56:59.0 -0400
+++ /u/cmetcalf/p4/branch/tools/gnu/ld/lexsup.c 2008-05-30 13:46:03.405525000
-0400
@@ -110,6 +110,7 @@
OPTION_WARN_COMMON,
OPTION_WARN_CONSTRUCTORS,
OPTION_WARN_FATAL,
+ OPTION_WARN_NO_FATAL,
OPTION_WARN_MULTIPLE_GP,
OPTION_WARN_ONCE,
OPTION_WARN_SECTION_ALIGN,
@@ -360,6 +361,9 @@
{ {"fatal-warnings", no_argument, NULL, OPTION_WARN_FATAL},
'\0', NULL, N_("Treat warnings as errors"),
TWO_DASHES },
+ { {"no-fatal-warnings", no_argument, NULL, OPTION_WARN_NO_FATAL},
+'\0', NULL, N_("Don't treat warnings as errors"),
+TWO_DASHES },
{ {"fini", required_argument, NULL, OPTION_FINI},
'\0', N_("SYMBOL"), N_("Call SYMBOL at unload-time"), ONE_DASH },
{ {"force-exe-suffix", no_argument, NULL, OPTION_FORCE_EXE_SUFFIX},
@@ -1231,6 +1235,9 @@
case OPTION_WARN_FATAL:
config.fatal_warnings = TRUE;
break;
+ case OPTION_WARN_NO_FATAL:
+ config.fatal_warnings = FALSE;
+ break;
case OPTION_WARN_MULTIPLE_GP:
config.warn_multiple_gp = TRUE;
break;
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
can't build gold on FreeBSD
Hi folks-- I'm trying to get gccgo to go, using the latest sources from binutils for gold. I did a quick google search, and this doesn't appear to be a known bug. Any help would be greatly appreciated. Here are my system details, followed by binutils info, followed by the bug: maxwell$ uname -a FreeBSD maxwell.cjones.org 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 binutils checked out from anon...@sourceware.org:/cvs/src a few minutes ago Configured using: ../../gnusrc/binutils/configure --enable-gold --prefix=$HOME/gccgo Built using: gmake Error: g++ -DHAVE_CONFIG_H -I. -I../../../gnusrc/binutils/gold -I../../../gnusrc/binutils/gold -I../../../gnusrc/binutils/gold/../include -I../../../gnusrc/binutils/gold/../elfcpp -DLOCALEDIR="\"/usr/home/chris/gccgo/share/locale\"" -DBINDIR="\"/usr/home/chris/gccgo/bin\"" -DTOOLBINDIR="\"/usr/home/chris/gccgo/i386-unknown-freebsd8.1/bin\"" -I./../intl -W -Wall-Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=sparc.o -g -O2 -MT sparc.o -MD -MP -MF .deps/sparc.Tpo -c -o sparc.o ../../../gnusrc/binutils/gold/sparc.cc ../../../gnusrc/binutils/gold/sparc.cc: In member function 'void::Target_sparcbig_endian>::gc_process_relocs(gold::Symbol_table*, gold::Layout*, gold::Sized_relobj*, unsigned int, unsigned int, const unsigned char*, size_t, gold::Output_section*, bool, size_t, const unsigned char*) [with int size = 64, bool big_endian = true]': ../../../gnusrc/binutils/gold/sparc.cc:3343: instantiated from here ../../../gnusrc/binutils/gold/sparc.cc:2333: error: dependent-name '::Target_sparc::Relocatable_size_for_reloc' is parsed as a non-type, but instantiation yields a type ../../../gnusrc/binutils/gold/sparc.cc:2333: note: say 'typename ::Target_sparc::Relocatable_size_for_reloc' if a type is meant ../../../gnusrc/binutils/gold/sparc.cc: In member function 'void::Target_sparcbig_endian>::gc_process_relocs(gold::Symbol_table*, gold::Layout*, gold::Sized_relobj*, unsigned int, unsigned int, const unsigned char*, size_t, gold::Output_section*, bool, size_t, const unsigned char*) [with int size = 32, bool big_endian = true]': ../../../gnusrc/binutils/gold/sparc.cc:3343: instantiated from here ../../../gnusrc/binutils/gold/sparc.cc:2333: error: dependent-name '::Target_sparc::Relocatable_size_for_reloc' is parsed as a non-type, but instantiation yields a type ../../../gnusrc/binutils/gold/sparc.cc:2333: note: say 'typename ::Target_sparc::Relocatable_size_for_reloc' if a type is meant gmake[4]: *** [sparc.o] Error 1 gmake[4]: Leaving directory `/usr/home/chris/gnuobj/binutils/gold' ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: can't build gold on FreeBSD
On 8/2/2010 9:10 AM, Ian Lance Taylor wrote: Chris Jones writes: I'm trying to get gccgo to go, using the latest sources from binutils for gold. I did a quick google search, and this doesn't appear to be a known bug. Any help would be greatly appreciated. What version of g++ are you using to build gold? The stock one that comes with FreeBSD: maxwell$ g++ -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] Note that while it is useful to use gold with gccgo on x86/x86_64, there is currently no advantage to doing so on SPARC. Got it. I'm not using SPARC, though -- I'm on an i386, which makes it seem a bit odd that the sparc files are getting compiled at all. Chris ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/15435] New: Gold rejects undefined weak hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15435 Bug #: 15435 Summary: Gold rejects undefined weak hidden symbol Product: binutils Version: 2.24 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: ch...@smowton.net Classification: Unclassified If I try to link a file that contains a weak hidden undefined symbol, Gold complains "hidden symbol 'foo' is not defined locally" (from target-reloc.h:404, where weak symbols are disregarded but /any/ symbol with non-default visibility, including weak ones, are required to be defined). In the event this was produced by using the LLVMgold plugin, which has the interesting behaviour that when processing an LLVM declaration like declare extern_weak hidden void @_stdio_init() (example from uclibc) the LLVM plugin actually disguises the fact that the extern is annotated hidden and just describes it was weak-undef to Gold. However its subterfuge cannot last, and it is discovered after LLVM lowers the LTO'd IR to a plain ELF binary and Gold rereads, I guess to check if LLVM introduced calls (e.g. to memcpy). At that stage it notices the extern is still declared hidden-weak-undef and merges the symbol table entries. One could argue this is a bug in LLVM (and I shall submit this report to their tracker as well) and that the idea of hidden-undefined doesn't make sense. I would argue a change is warranted in gold either way: 1. If you think hidden-weak-undef isn't sensible, report "illegal attributes for symbol foo" rather than "not defined here" 2. If you think it is, disregard like any other weak-undef. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/15435] Gold rejects undefined weak hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15435 --- Comment #1 from Chris Smowton 2013-05-06 17:44:17 UTC --- LLVM tracker entry: http://llvm.org/bugs/show_bug.cgi?id=15919 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/10288] New: "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
objdump for ARM7TDMI binaries shows instructions for newer ARM architectures. It doesn't return "undefined" like it should for these instructions. -- Summary: "objdump -D --target=binary -m arm7tdmi" shows non- ARM7TDMI instructions Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: chris at seberino dot org CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-18 03:34 --- You were certainly correct to remove certain coprocessor instructions like ldc2 that only belong on later architectures. I'm not sure we're allowed to remove *all* coprocessor instructions. Even though many (most?) fielded ARM7TDMIs don't utilize coprocessors or virtual floating point instructions, I think they are still recognized by ARM7TDMI. What was your rationale for remove *all* coprocessor instructions? -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-18 18:33 --- I think your patch may have done more than you think. It not only removed coprocessor instructions that are not supported by ARM7TDMI, but also removed coprocessor instructions that *are* supported by ARM7TDMI. For example, I don't see ldc anymore which *is* supported by ARM7TDMI. Not it is reported as undefined. The problem with your suggestion of using the "-marm" switch is that is would return the problem that existed before...namely, showing coprocessors instructions for newer architectures that shouldn't be there like ldc2. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10297] New: inconsistencies in objdump's presentation of undefined's and comments
Here is a Python script that creates a raw binary and runs objdump on it to
reproduce the problem with the output following...
#
import commands
raw_binary = open("raw_binary", "w")
raw_binary.write(chr(0x1f) + chr(0x19) + chr(0x42) + chr(0xc3))
raw_binary.write(chr(0x6d) + chr(0xe8) + chr(0x6e) + chr(0x50))
raw_binary.write(chr(0x17) + chr(0x23) + chr(0xa9) + chr(0xb7))
raw_binary.write(chr(0x77) + chr(0xce) + chr(0x1b) + chr(0xf9))
raw_binary.close()
print commands.getoutput("objdump -D --target=binary -m arm7tdmi raw_binary")
#
% python foo.py
raw_binary: file format binary
Disassembly of section .data:
<.data>:
0: c342191fcmpgt r2, #507904 ; 0x7c000
4: 506ee86drsbpl lr, lr, sp, ror #16
8: b7a92317undefined
c: f91bce77undefined instruction 0xf91bce77
-
Notice that the first 2 instructions have a immediate value but only the first
once has a comment with the hex equivalent.
Also, notice the last 2 instructions are both undefined's yet only the last one
repeats the hex representation of the instruction.
--
Summary: inconsistencies in objdump's presentation of undefined's
and comments
Product: binutils
Version: 2.19
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: chris at seberino dot org
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=10297
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-19 17:50 --- I can't apply patch from bug #10288 and bug #10297 at same time. They crash into each other when you try to apply both of them. Can you make a patch that includes both fixes? chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10297] inconsistencies in objdump's presentation of undefined's and comments
--- Additional Comments From chris at seberino dot org 2009-06-19 17:50 --- I can't apply patch from bug #10288 and bug #10297 at same time. They crash into each other when you try to apply both of them. Can you make a patch that includes both fixes? chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10297 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-22 19:43
---
The undefined fix is very nice. I did find some issues and have appended a
Python script to reproduce...
#==The Python script
import struct
raw_binary = open("raw_binary", "w")
raw_binary.write(struct.pack("L", 0x4c585ee5))
raw_binary.write(struct.pack("L", 0x01a23597))
raw_binary.write(struct.pack("L", 0x3d9da24e))
#==The Python script output=
% objdump -D --target=binary -m arm7tdmi raw_binary
raw_binary: file format binary
Disassembly of section .data:
<.data>:
0: 4c585ee5mrrcmi 14, 14, r5, r8, cr5
4: 01a23597strbeq r3, [r2, r7]!
8: 3d9da24elfmcc f2, 1, [sp, #312]
#==Comments==
1. mrrcmi is an extended DSP instruction that doesn't belong on ARM7TDMI right?
2. According to my ARM ref manual, strb needs to have bits 4-11 zeroed out which
01a23597 doesn't. Should this be undefined instead?
3. I can't find lfm in my ARM ref manual. Googling reveal it to be a floating
point multiple load instruction. This may be right but I'm not sure since it
isn't documented in ARM book I have.
cs
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10288
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-22 21:53 --- I was thinking a little more about the lfm instruction. It seems there are standard coprocessor instruction names on ARM: cdp, ldc, stc, mcr and mrc. And, because ARM defines optional standard coprocessor setups for common hardware extensions like floating point, ARM has defined additional *ALIASES* for aforementioned coprocessor instructions like lfm, fstms, fstmd, fstd, fstd, etc. I would personally prefer that only the standard coprocessor instruction names be used (cdp, ldc, stc, mcr and mrc) and the other aliases like floating point aliases be avoided since we can't guarantee existence of that. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10297] inconsistencies in objdump's presentation of undefined's and comments
--- Additional Comments From chris at seberino dot org 2009-06-22 22:50 --- You said that the hex equivalent should be displayed for all immediate values that are greater than 5 bits. I found some cases where larger immediate values do not have the hex equivalent value shown. For example, loads and stores use addressing mode 2 which has 12 bit immediate values. Here are 2 stores (str) that don't have hex equivalents... 8: 14a4ff06strtne pc, [r4], #3846 18: 858028ddstrhi r2, [r0, #2269] Here are 2 coprocessor loads and stores (addressing mode 5) with 8 bit immediates that don't have hex equivalents... 3c: 4d7e6b9fldclmi 11, cr6, [lr, #-636]! 174: 0ca40a81stceq 10, cr0, [r4], #516 17c: 9d01082fstcls 8, cr0, [r1, #-188] cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10297 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10297] inconsistencies in objdump's presentation of undefined's and comments
--- Additional Comments From chris at seberino dot org 2009-06-23 17:43 --- It looks like a file named gas/testsuite/gas/arm/arm-it-auto-2.d is missing from binutils-2.19.51 so I can't apply the patch. What version did you apply this patch against? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10297 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-24 20:14
---
mrrc is gone with is good. strb appears to have gotten worse! I think the new
patch introduced new bugs into strb. See below. Also, some hex equivalents
appear to be botched. See below for that too
New objdump shows following instructions to be strb but I think they should be
all undefined
46647659strbmi r7, [r4], #-105
77c1cdb4strbvc ip, [r1, #212]
e640361fstrbr3, [r0], #-111
Notice following have incorrect or missing hex equivalents...
4c585ee5ldclmi 14, cr5, [r8], {229}; 0xfc6c
d446399estrble r3, [r6], #-158
11d87ed1ldrsbne r7, [r8, #225]
44afa697strtmi sl, [pc], #1687 ; 0xb4
d4bf78b4ldrtle r7, [pc], #2228 ; 0xf4
bc041350stclt 3, cr1, [r4], {80} ; 0xfec0
chris
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10288
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-24 22:32 --- About lfm and sfm.these are alternative aliases for floating point coprocessor instructions along with many others in the ARM docs I've seen. We can't guarantee that every ARM7TDMI will have a floating point coprocessor so these aliases will not always apply. Wouldn't it therefore be safer and make more sense to have objdump just display the standard coprocessor instruction names?... (i.e. ldc, stc, cdp ?) -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-25 18:26
---
** Incorrect or missing hex equivalents...
(If this is hard to fix and you want to just remove all hex equivalents that
would be fine by me.)
4c585ee5ldclmi 14, cr5, [r8], {229}; 0xfc6c
11d87ed1ldrsbne r7, [r8, #225]
44afa697strtmi sl, [pc], #1687 ; 0xb4
d4bf78b4ldrtle r7, [pc], #2228 ; 0xf4
bc041350stclt 3, cr1, [r4], {80} ; 0xfec0
** Notice the very last argument for these 3 strb's are registers. It doesn't
appear in my ARM ref book for addressing mode 2. In other words, to the right
of asr, lsl, lsr and ror should only be immediate values.
46647659strbmi r7, [r4], -r9, asr r6
e640361fstrbr3, [r0], -pc, lsl r6
77c1cdb4strbvc ip, [r1, r4, lsr sp]
** What did you think of my reasons for replacing floating point aliases like
lfm with the always correct standard names like ldc? This would apply for
example to this one...
3d9da24elfmcc f2, 1, [sp, #312] ; 0x138
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10288
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-06-30 20:22 --- I couldn't apply tc-arm.c.patch but it looked like you applied it already to binutils-2.19.51.tar.bz2. So these comments pertain to your June 30th 2.19.51... I'll mention 2 things in this paragraph that if you don't want to fix I'm ok with..There were still some inconsistencies with some hex equivalents that were missing. Also, some undefineds that were "undefined instuction 0x" and others that were "undefined". (If you just want to cut out hex equivalents that ok by me. Also, objdump already shows the instruction and address so if you want to just make all undefined's just print "undefined" that is ok with me too.) More importantly, it looks like you reintroduced DSP instructions and instructions for later CPU architectures that don't belong in ARM7TDMI like... mrrc, blx and ldc2. There was also some unidentifiable instructions I didn't know what to make of like these... usat, movw, vdupcs.8 and fldmdbxmi. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-02 17:28
---
(In reply to comment #27)
> Subject: Re: "objdump -D --target=binary -m arm7tdmi"
> showsnon-ARM7TDMI instructions
>
> Hi Chris,
>
> > More importantly, it looks like you reintroduced DSP instructions and
> > instructions for later CPU architectures that don't belong in ARM7TDMI
> > like...
> > mrrc, blx and ldc2.
>
> Are you sure ? I could not reproduce these.
Try these...
4c585ee5mrrcmi 14, 14, r5, r8, cr5
fd37a04fldc20, cr10, [r7, #-316]!
fabf5236blx 0xfefd49dc
(By the way, I didn't apply your latest patch tc0arn.c.patch because it looked
like you already applied it to latest iteration of 2.19.51.)
> > There was also some unidentifiable instructions I didn't know what to make
> > of
> > like these...
> > usat, movw, vdupcs.8 and fldmdbxmi.
>
> According to the "ARMv7-M Architecture Application Level Reference
> Manual" the first one is:
>
>USAT
>Unsigned Saturate saturates an optionally-shifted signed value
>to a selected unsigned range.
>The Q flag is set if the operation saturates.
>
>Encoding T1 ARMv6T2, ARMv7
>USAT ,#,{,}
>
> MOVW appears to be an alias for the ARM V6T2 16-bit immediate register
> load instruction: MOV[WT]{cond} Rd, #.
I wonder if you are making the same mistake I used to. ARM version numbering is
confusing because there are architecture versions and architecture
*implementation* versions. ARM7TDMI is an implementation of the ARMv4T
architecture. The "7" in ARM7TDMI might make one think it support ARMv6 and
ARMv7 but it does NOT. This is because the architecture version is the old
ARMv4T. Hence, the above ARMv6 and ARMv7 instructions shouldn't be there form
-m arm7tdmi.
Clear?
P.S. I'm committed to hanging in there until this is as right as you are willing
to make it. I appreciate all your help.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10288
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-03 06:10 --- I just rebuilt latest binutils Th 7/2/09 evening PST and it seems better now. I don't know if you fixed something in the interim or I blew it in my last test. The only problem that is still around is the undocumented addressing mode for strb.. 46647659strbmi r7, [r4], -r9, asr r6 77c1cdb4strbvc ip, [r1, r4, lsr sp] e640361fstrbr3, [r0], -pc, lsl r6 Did you mean to add the standard general coprocessor instruction as a comment after the version you preferred? Because for 3d9da24elfmcc f2, 1, [sp, #312] I didn't see a comment with "; ldccc2, cr10, [sp, #312]" cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-03 19:26 --- > I didn't see a comment with "; ldccc 2, cr10, [sp, #312]" Nick I owe you an apology. I do see this comment. The only lingering problem is the strb nonexistent addressing mode. I will now start comprehensive brute force testing of your code. What I mean by that is that there are "only" 2^32 possible 32 bit instructions. I plan to compare the output of my disassembler against objdump for all those guys. Results to follow soon. Then we can be happy we did extensive testing and all we practically could to get objdump done right for the world! :) cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10342] Wrong instruction-byte association on Z80 port
--- Additional Comments From chris at zxdesign dot info 2009-07-05 15:48 --- Fixed in HEAD 2008-09-14 http://sourceware.org/ml/binutils/2008-09/msg00105.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=10342 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-07 17:41 --- Nick, I'm very glad you are still sending patches on this. I very much appreciate it. We are almost done I was afraid this would happen. It seems for some reason often when we try to fix something unrelated to the "DSP and newer instructions bug" that that old bug keeps sneaking back in. The 6/30 patch was wonderful because the *only* leftover issue was the STRB scaled addressing modes. Unfortunately, I must report that once again we need to remove instructions that don't belong like mrrc, blx, ldc2, usat, etc. You can pat yourself on the back because the current state of binutils is beautiful and almost across the finish line. All you need to do is take another crack at a new patch to it and we'll be golden. chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-10 18:46 --- Nick Sorry this is the second time I sent out a false alarm. My guess is there is some lag time between when your email notice arrives in my mailbox and the new tarballs get posted. Hence, I end up pulling an old tarball and then few days later all works fine with a newer tarball. ALL my previous preliminary tests now pass on binutils-2.19.51.tar.bz2 with the md5sum of 572abc9d57659cae8b2654217f642cb4. Now I will start comprehensive testing of all 4 billions instructions and get back to you in a few days with the final output of that battery of tests. Good job! Chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-11 06:22 --- OK. Here is first bug from the serious testing "00b0 strheq r0, [r0], r0" That should be "strheq r0, [r0], -r0" <--- notice the negative cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-11 06:33 --- I think all of the following are wrong. This "asr" part of addressing mode must be instructions like 0x005Z for Z=0,1,2,3, ... *not* 0x00dZ. <--- notice the "d". < 340: 00d0andeq r0, r0, r0, asr r0 < 344: 00d1andeq r0, r0, r1, asr r0 < 348: 00d2andeq r0, r0, r2, asr r0 < 34c: 00d3andeq r0, r0, r3, asr r0 < 350: 00d4andeq r0, r0, r4, asr r0 < 354: 00d5andeq r0, r0, r5, asr r0 < 358: 00d6andeq r0, r0, r6, asr r0 < 35c: 00d7andeq r0, r0, r7, asr r0 < 360: 00d8andeq r0, r0, r8, asr r0 < 364: 00d9andeq r0, r0, r9, asr r0 < 368: 00daandeq r0, r0, sl, asr r0 < 36c: 00dbandeq r0, r0, fp, asr r0 < 370: 00dcandeq r0, r0, ip, asr r0 < 374: 00ddandeq r0, r0, sp, asr r0 < 378: 00deandeq r0, r0, lr, asr r0 < 37c: 00dfandeq r0, r0, pc, asr r0 -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-11 06:37 --- I think all of the following are wrong. This "ror" part of addressing mode 1 must be instructions like 0x007Z for Z=0,1,2,3, ... *not* 0x00fZ. <--- notice the "f". < 3c0: 00f0andeq r0, r0, r0, ror r0 < 3c4: 00f1andeq r0, r0, r1, ror r0 < 3c8: 00f2andeq r0, r0, r2, ror r0 < 3cc: 00f3andeq r0, r0, r3, ror r0 < 3d0: 00f4andeq r0, r0, r4, ror r0 < 3d4: 00f5andeq r0, r0, r5, ror r0 < 3d8: 00f6andeq r0, r0, r6, ror r0 < 3dc: 00f7andeq r0, r0, r7, ror r0 < 3e0: 00f8andeq r0, r0, r8, ror r0 < 3e4: 00f9andeq r0, r0, r9, ror r0 < 3e8: 00faandeq r0, r0, sl, ror r0 < 3ec: 00fbandeq r0, r0, fp, ror r0 < 3f0: 00fcandeq r0, r0, ip, ror r0 < 3f4: 00fdandeq r0, r0, sp, ror r0 < 3f8: 00feandeq r0, r0, lr, ror r0 < 3fc: 00ffandeq r0, r0, pc, ror r0 -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-16 18:16 --- Nick Many bit regions in ARM instructions are specified as SBZ "Should Be Zero". ARM docs say if these bits are NOT zero that the results are UNPREDICTABLE for all ARM chips! So the question is what is the best thing for objdump to do in these situations where a bit region is not zeroed out when it should be. I think the cleanest thing to do is to return UNDEFINED. I found some incorrect ldrsb's and ldrsh's that I think would best be interpreted as UNDEFINED instead Here are some examples. (These all have SBZ regions that aren't zeroed out)... <2fe40: 001001d0ldrsbeq r0, [r0], -r0 <2fe44: 001001d1ldrsbeq r0, [r0], -r1 <2fe48: 001001d2ldrsbeq r0, [r0], -r2 <2fe4c: 001001d3ldrsbeq r0, [r0], -r3 <2fe50: 001001d4ldrsbeq r0, [r0], -r4 <2fe54: 001001d5ldrsbeq r0, [r0], -r5 <2fe58: 001001d6ldrsbeq r0, [r0], -r6 <2fe5c: 001001d7ldrsbeq r0, [r0], -r7 <2fe60: 001001d8ldrsbeq r0, [r0], -r8 <2fe64: 001001d9ldrsbeq r0, [r0], -r9 <2fec0: 001001f0ldrsheq r0, [r0], -r0 <2fec4: 001001f1ldrsheq r0, [r0], -r1 <2fec8: 001001f2ldrsheq r0, [r0], -r2 <2fecc: 001001f3ldrsheq r0, [r0], -r3 <2fed0: 001001f4ldrsheq r0, [r0], -r4 <2fed4: 001001f5ldrsheq r0, [r0], -r5 <2fed8: 001001f6ldrsheq r0, [r0], -r6 ...etc. Would it be hard for you to make these return UNDEFINED? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-07-16 18:44 --- Nick If you think the SBZ issue isn't worth changing, or fine the way it is, that is fine. I'll move on. I just wanted to make you aware of what I found. That's all. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions
--- Additional Comments From chris at seberino dot org 2009-08-04 17:03 --- Nick Would it be possible for me to take a few weeks break from our work on http://sourceware.org/bugzilla/show_bug.cgi?id=10288 and come back to it? Other things came up in the short term and these last few bugs are a little trickier than the early more obvious ones. I'd like to rest for a bit doing other things and then come back. I don't know if you want to close this ticket for now or leave it open until I return. I just don't want you to think I'm bailing on this. Chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10288 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] New: Bug in objdump when disassembling raw armv4t binaries
Instruction 0x002000b0 looks like a strheq instruction but it should be unpredictable since the P bit is zero and W bit is 1. Another reason it should be unpredictable is that when W is 1 you can have Rd == Rn. Perhaps returning undefined for all unpredictables would be a good idea? That is my suggestion. Thoughts? -- Summary: Bug in objdump when disassembling raw armv4t binaries Product: binutils Version: 2.21 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: chris at seberino dot org CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-10 17:31
---
Subject: Re: Bug in objdump when disassembling raw
armv4t binaries
On Tue, Nov 10, 2009 at 10:32:26AM -, nickc at redhat dot com wrote:
> I am planning on applying the uploaded patch to address this issue, but I
> would like your feedback on the new behaviour. With the patch applied your
> testcase will disassemble as:
>
> <.text>:
> 0: 002000b0strheq r0, [r0], -r0
>
> I feel that displaying the disassembled instruction is correct, even though it
> is unpredictable, since it is the behaviour of the instruction that cannot be
> specified rather than the entire instruction being undefined.
Sounds good. I would just suggest making the warning a comment so that
the output of objdump still can be run through gas.
e.g.
<.text>:
0: 002000b0strheq r0, [r0], -r0 ; UNPREDICTABLE
On another note, do you have any links explaining the hows and whys of
UNPREDICTABLEs? How did you know "it is the behaviour of the instruction that
cannot be specified rather than the entire instruction being undefined" ?
cs
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10924
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-14 23:38 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Wed, Nov 11, 2009 at 09:54:45AM -, nickc at redhat dot com wrote: > I have checked the patch in, but I will leave this issue open for reports of > other UNPREDICTABLE bit patterns. Nick OK I tried to find all bugs I could in one pass to make your job easier. Regarding me helping with writing patches, I'll do it if I need to but it is enough work just to inspect all this output to find the bugs in the first place. I'd be afraid of making a mistake. Is there a specific file you could point me to where all this parsing takes place? I'll have a look. I assume have unit tests you run your patches through so we know we aren't adding new bugs as we fix existing ones? And, I assume you are testing what I say against the ARM manual so that *I* don't introduce a bug? ... Here is what I found recently. BTW, when I give you an example of a bug, it is most likely found in other instructions. I'm hoping that your fix ends up eliminating the whole *class* of bugs. For example, that last undefined bug regarding P=0 and W=1 was reported for a store. It also shows up in ldrsb and ldrh. I hope you patch nailed those too? Without further ado 0x004000b0 strheq r0, [r0], #-0 <--- objdump is missing the "#-0" (see ARM-ARM top of A5-45) 0x004f00b1 strheq r0, [pc], #-1 <--- objdump has r0, [pc, #-1] 0x005f ldrsheq pc, [pc], #-255 <--- objdump has pc, [pc, #-255] 0x00500090 <-- should be undefined not ldrbeq 0x006fffbf <-- P=0 so can't be right 0x00700090 bit 26 is zero so can't be ldrbeq...I think it is undefined 0x007f ldrsheq pc, [pc, #-255]! <-- objdump is missing the "!" since bit 21=1 0x00cf00b0 strheq r0, [pc], #0 <--- objdump has r0, [pc, #0] (bit24=0) (likewise for 0x00df00b0 and 0x00df) 0x00ff ldrsheq pc, [pc, #255] <-- can't be right since P=0 0x0100f000 <-- obdjump say this is a tstpeqWhat is tstp? No such thing! 0x01100090 <-- Can't be ldrbeq since bit26 is zero. I think is undefined 0x0120f096 <-- objdump has "". That should be fixed. 0x01300090 <--Can't be ldrbeq since bit26 =0. I think is undefined. 0x0140 <-- Should be mrseq not cmpeq since bit 20=0 0x016000b0 strheq r0, [r0, #-0]! <-- objdump has r0, [r0]! which is wrong cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-17 17:57 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Tue, Nov 17, 2009 at 05:25:50PM -, nickc at redhat dot com wrote: > Right - I have checked in the newly uploaded pr10924_arm_dis.c_patch.2 which > handles all of the new test cases you found. > > With regard to the TSTP instruction, it is a real instruction, but an > obsolete > one. The patch takes care of this as well. > > Let me know if you find any more bad instruction patterns. Thanks will do. Glad I can help. On another note, do you have any tricks to make me feel confident we aren't introducing bugs? I don't suppose ARM has a blessed disassembler we can compare against? Or, do you have rock solid comprehensive unit tests against gas? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-18 18:17 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Wed, Nov 18, 2009 at 05:07:14PM -, nickc at redhat dot com wrote: > Actually I think that he was referring to the compulsory presence of the > offset, even if it is zero, in the pre-indexed form of addressing. Just to make sure we're clearmy understanding of my ARM manual is that we need to specify #0 just like any other number. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-22 17:12 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Sun, Nov 22, 2009 at 04:43:12AM -, drow at sources dot redhat dot com wrote: > > --- Additional Comments From drow at sources dot redhat dot com > 2009-11-22 04:43 --- > Thanks. I don't see why we need to print a positive zero offset (it's not > ambiguous with anything), I think Nick is right. I don't think we have to. My ARM book seems to agree. although [r0, #0]! is a sufficiently odd addressing > mode that it does seem sensible. Not sure about ! situation yet. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-11-30 04:55 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Tue, Nov 10, 2009 at 10:32:26AM -, nickc at redhat dot com wrote: > I am planning on applying the uploaded patch to address this issue, but I > would like your feedback on the new behaviour. With the patch applied your > testcase will disassemble as: > > <.text>: > 0: 002000b0strheq r0, [r0], -r0 You ended up adding a comment for the above unpredictable instruction flagging it as unpredictable. There are thousands of other loads and stores you still need to flag as unpredictable.What they all have in common is they have W=1 and P=0. (bits #21 and #24) for addressing mode 3. Please flag all loads and stores with the following format as unpredictable... 0xX02X 0xX03X 0xX06X 0xX07X 0xX0aX 0xX0bX 0xX0eX ..etc. (Notice they all have bit 24 unset and bit 21 set.) cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-01 15:20 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Tue, Dec 01, 2009 at 12:07:56PM -, nickc at redhat dot com wrote: > > --- Additional Comments From nickc at redhat dot com 2009-12-01 12:07 > --- > Hi Chris, > > > Please flag all loads and stores with the following format as > > unpredictable... > > A checked a variety of the patterns you suggested and they are all flagged as > unpredictable, so I think that the disassembler is working correctly. I tried to apply the patch to binutils-2.20.51 and patch said it looked like the patch was applied already so I did NOT apply it. Did I blow it? Must I apply the patch to another version? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-02 06:41 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Tue, Dec 01, 2009 at 07:20:14AM -0800, ch...@seberino.org wrote: > I tried to apply the patch to binutils-2.20.51 and patch said it looked like > the patch was applied already so I did NOT apply it. See here... % cd binutils-2.20.51 % patch -p0 < pr10924_arm-dis.c_patch.3 patching file opcodes/arm-dis.c Reversed (or previously applied) patch detected! Assume -R? [n] cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-02 19:20 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Wed, Dec 02, 2009 at 11:22:15AM -, nickc at redhat dot com wrote: > > --- Additional Comments From nickc at redhat dot com 2009-12-02 11:22 > --- > Hi Chris, > > > I tried to apply the patch to binutils-2.20.51 and patch said it looked like > > the patch was applied already so I did NOT apply it. > > Good - I have already checked the patch in. (I was confident that it was > correct). Sorry. That one was my fault. Indeed objdump now flags loads and stores as UNPREDICTABLE that should be. It appears that it also flags some as UNPREDICTABLE that are not. See these 3... % ./objdump -b binary -m armv4t -D aaa23 test: file format binary Disassembly of section .data: <.data>: 0:004f00b0 strheq r0, [pc], #0; 4:005f00b0 ldrheq r0, [pc], #0; Why are those UNPREDICTABLE? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-04 19:15 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Thu, Dec 03, 2009 at 10:54:51AM -, nickc at redhat dot com wrote: > They are unpredictable because they use the program counter as the address > register. See page A5-45 of your ARM ARM: > > "Specifying R15 as register Rn has UNPREDICTABLE results." Nick Thanks for being patient with my mistakes. Between the two of us, we'll catch each other's mistakes and both end up stronger for it. OK I think I found a bug on an old fix to redeem myself 0x00bf returns strheq r0, [r0], -pc (pc = r15) ARM ARM say for this situation neither Rn nor Rm can be pc (R15). Hence, we need an "; " for this case too. cs P.S. By the way, I'm using ARM ARM version ARM DDI 0100I which has different page numbers than your version. I can send you my PDF if you wish. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-08 18:25 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Tue, Dec 08, 2009 at 05:25:00PM -, nickc at redhat dot com wrote: > > --- Additional Comments From nickc at redhat dot com 2009-12-08 17:25 > --- > Created an attachment (id=4450) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4450&action=view) > --> (http://sourceware.org/bugzilla/attachment.cgi?id=4450&action=view) > Cathc PC used in post-indexed addressing Will the daily snapshot of binutils contain latest patches always? Like this one? Last time I didn't need to apply your patch so I'm wondering if I should just always use latest snapshot "as is" for new testing. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-10 22:47 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries >From Dec 10 version of binutils I can't see why 0x004000bf is marked UNPREDICTABLE. I think that is incorrect... 0:004000bf strheq r0, [r0], #-15 ; Agreed? cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-10 23:33 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Thu, Dec 10, 2009 at 11:12:27PM -, drow at sources dot redhat dot com wrote: > Writeback is set, and rN == rT. From my copy of the docs, that's > unpredictable. You are right. I found where this is hidden in my ARM ARM. Nice catch. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:12 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I think instructions like these below should have a comment flagging them as UNPREDICTABLEstrh can't have Rd == R15. 3c2c0: f0b0strheq pc, [r0], -r0 3fc2f8: 000ff0bestrheq pc, [pc], -lr cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:25 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I don't think the following is UNPREDICTABLE. Every load and store that has Rd == Rn isn't UNPREDICTABLE. That only applies if the W and P bits are set. Or, if it is one of the "t" variants like strt. 2fc:004000bfstrheq r0, [r0], #-15 ; cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:35 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries I don't see why this one is marked UNPREDICTABLE... 42fc: 005010bf ldrheq r1, [r0], #-15 ; The P and W bits are both zero which is ok. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 17:58 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:48:59PM -, drow at false dot org wrote: > My copy of the manual doesn't say this is unpredictable - but it > doesn't say what it means, either. The valid versions all have P == 1 > and/or W == 1. And the post-indexed encoding is the same as strht > encoding. > > I'm not quite sure what that adds up to! Oh no. I'll check later but an unspecified instruction would be bad for us. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-11 18:17 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:48:59PM -, drow at false dot org wrote: > > --- Additional Comments From drow at false dot org 2009-12-11 17:48 > --- > Subject: Re: Bug in objdump when disassembling raw > armv4t binaries > > On Fri, Dec 11, 2009 at 05:25:25PM -, chris at seberino dot org wrote: > > I don't think the following is UNPREDICTABLE. Every load and store that has > > Rd == Rn isn't UNPREDICTABLE. That only applies if the W and P bits are > > set. > > Or, if it is one of the "t" variants like strt. > > > > 2fc:004000bfstrheq r0, [r0], #-15 ; > > My copy of the manual doesn't say this is unpredictable - but it > doesn't say what it means, either. I think unspecified should be flagged as UNPREDICTABLE since we can't predict what it will do. cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-13 03:46 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Fri, Dec 11, 2009 at 05:48:59PM -, drow at false dot org wrote: > > 2fc:004000bfstrheq r0, [r0], #-15 ; > > My copy of the manual doesn't say this is unpredictable - but it > doesn't say what it means, either. The valid versions all have P == 1 > and/or W == 1. And the post-indexed encoding is the same as strht > encoding. If I'm not mistaken, this instruction as well as the P=W=0 case *is* specified in the ARM ARM. I can send you a copy of my version ARM DDI 0100I if you wish. The instruction above involves addressing mode 3 with immediate post-indexed case. That case has P=W=0. Chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-15 02:20 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Mon, Dec 14, 2009 at 04:46:12PM -, nickc at redhat dot com wrote: > There are also several situations where unpredictable behaviour results from > the same register being used twice in an instruction. (Eg the MLA, MUL, UMULL > etc instructions). Currently the disassembler does not pick these up. I am > not > sure how important it is to detect them, but let me know what you think. I'm not sure what you mean. Are you saying you don't want to flag all UNPREDICTABLES? I would think we should flag all UNPREDICTABLEs with a comment. It helps me check objdump against by custom disassemblerI need something in the output that is predictable. Did you catch all the load and store situations that are UNPREDICTABLE when the same register is used twice I alerted you to in a previous email? Chris -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10924] Bug in objdump when disassembling raw armv4t binaries
--- Additional Comments From chris at seberino dot org 2009-12-17 16:33 --- Subject: Re: Bug in objdump when disassembling raw armv4t binaries On Thu, Dec 17, 2009 at 10:01:02AM -, nickc at redhat dot com wrote: > Don't mind me, I was just whining... I understand. This is a little tedious. I commend you for hanging on this far. It does take a lot of work on your part to fix other peoples' code. It is a big responsibility since so many people use binutils. You are doing a lot of hard work. There is no denying that. Anything I can do to motivate you to hang on? > > Did you catch all the load and store situations that are UNPREDICTABLE > > when the same register is used twice I alerted you to in a previous email? > > I think so. Please try updating your sources in order to get my latest patch > and then see if you still find any undetected unpredictable instructions. I assume if I wait until Friday that it will have the patch included already? > (Actually I know that we are not currently detecting many unpredictable THUMB > instructions, but I was going to look at them after we are confident that we > have the ARM instruction set covered). Yes me too. I'll attack Thumb after ARM (32 bit) is all done. I'm hoping the loads and stores are the hardest part. We should be almost done with that. Hopefully things will go a lot faster now. *knocking on wood* cs -- http://sourceware.org/bugzilla/show_bug.cgi?id=10924 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
