[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-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 ; UNPREDICTABLE 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-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 ; 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-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 ; UNPREDICTABLE 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 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 ; UNPREDICTABLE 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-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 ; UNPREDICTABLE 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-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=4450action=view) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4450action=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-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 ; UNPREDICTABLE 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-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; UNPREDICTABLE 4:005f00b0 ldrheq r0, [pc], #0; UNPREDICTABLE 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-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-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 illegal shifter operand. 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-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 UNPREDICTABLE
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/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/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-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-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-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-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 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
USATc Rd,#imm5,Rn{,shift}
MOVW appears to be an alias for the ARM V6T2 16-bit immediate register
load instruction: MOV[WT]{cond} Rd, #imm16.
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-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-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/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-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/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-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] 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
