https://sourceware.org/bugzilla/show_bug.cgi?id=10924
Alan Modra changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=10924
Andreas Schwab changed:
What|Removed |Added
CC|schwab at sourceware dot org |
--
You are receiving this m
https://sourceware.org/bugzilla/show_bug.cgi?id=10924
Andreas Schwab changed:
What|Removed |Added
Status|NEW |WAITING
CC|
--- 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
--- Additional Comments From nickc at redhat dot com 2009-12-17 10:01
---
Hi Chris,
> I'm not sure what you mean. Are you saying you don't want to flag
> all UNPREDICTABLES?
Don't mind me, I was just whining...
> Did you catch all the load and store situations that are UNPREDICTABLE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-12-17
09:52 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-12-17 09:52:18
Modified files:
opcodes: ChangeLog arm-dis.c
gas
--- 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 beha
--- Additional Comments From nickc at redhat dot com 2009-12-14 16:46
---
Hi Chris,
I have checked in another patch (which should be in tomorrow's tarball) to fix
the new cases you found and also to correct the snafu when post indexed
addressing is used with an immediate offset 15. (
--- Additional Comments From nickc at redhat dot com 2009-12-14 16:39
---
Created an attachment (id=4467)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4467&action=view)
More tests for unpredictable instructions
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10924
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-12-14
16:38 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-12-14 16:38:23
Modified files:
opcodes: ChangeLog arm-dis.c
gas/test
--- 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 co
--- 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
--- 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
--- 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 th
--- 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 zer
--- 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
--- 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:
--- 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
--- Additional Comments From drow at sources dot redhat dot com 2009-12-10
23:12 ---
Subject: Re: Bug in objdump when disassembling raw
armv4t binaries
On Thu, Dec 10, 2009 at 10:47:41PM -, chris at seberino dot org wrote:
> I can't see why 0x004000bf is marked UNPREDICTABLE. I t
--- 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:0040
Hi Chris,
Will the daily snapshot of binutils contain latest patches always?
Sorry - you will have to wait until tomorrow (Thursday). I have only
just checked it in today.
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-12-09
08:38 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-12-09 08:38:04
Modified files:
opcodes: ChangeLog arm-dis.c
Log message:
--- Additional Comments From drow at sources dot redhat dot com 2009-12-08
19:49 ---
Subject: Re: Bug in objdump when disassembling raw
armv4t binaries
On Tue, Dec 08, 2009 at 05:30:21PM -, nickc at redhat dot com wrote:
> Mine is ARM DDI 0100E. I would not mind having a copy of
--- 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
--- Additional Comments From nickc at redhat dot com 2009-12-08 17:30
---
Hi Chris,
Good catch. I have uploaded a patch to catch this form of unpredictable
addressing. You may have some difficulty applying it as I created it from my
local sources which have a second, uncommited, pa
--- 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)
Cathc PC used in post-indexed addressing
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10924
--
--- 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
--- Additional Comments From nickc at redhat dot com 2009-12-03 10:54
---
Hi Chris,
> See these 3...
There were only 2 instructions in your test case...
> 0:004f00b0 strheq r0, [pc], #0;
> 4:005f00b0 ldrheq r0, [pc], #0;
>
> Why are those UNPREDICTA
--- 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
--- 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 i
--- 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
--- 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
--- 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 disassem
--- 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 th
--- 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 sourc
--- 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), although [r0, #0]! is a sufficiently odd addressing
mode that it does seem sensible.
--
W
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-11-19
14:07 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-11-19 14:07:11
Modified files:
opcodes: ChangeLog arm-dis.c
gas/test
--- Additional Comments From nickc at redhat dot com 2009-11-19 14:03
---
Hi Guys,
Right - I have checked in the third patch in this series. This restores the
default behaviour of not printing a zero offset if it is used in Immediate
Offset addressing mode. This also resovles the gr
--- Additional Comments From nickc at redhat dot com 2009-11-19 14:01
---
Created an attachment (id=4396)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4396&action=view)
Do not prnt zero offset for Immediate Offset addressing
--
http://sourceware.org/bugzilla/show_bug.cgi?i
--- Additional Comments From nickc at redhat dot com 2009-11-19 11:15
---
Hi Chris,
> Just to make sure we're clearmy understanding of my ARM manual is that
> we need to specify #0 just like any other number.
Not quite. There is one form of Addressing Mode 3 where the #0 is optio
--- 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 pre
--- Additional Comments From nickc at redhat dot com 2009-11-18 17:07
---
Subject: Re: Bug in objdump when disassembling raw armv4t
binaries
Hi Daniel,
> Thoms Schwinge noticed a failure in group-relocations.d:
>
> regexp_diff match failure
> regexp "^8074: e1c020d0
Hi Daniel,
Thoms Schwinge noticed a failure in group-relocations.d:
regexp_diff match failure
regexp "^8074: e1c020d0ldrdr2, \[r0\]$"
line "8074: e1c020d0ldrdr2, [r0, #0]"
Oops, I thought that I had caught all of these.
Is this change
--- Additional Comments From drow at sources dot redhat dot com 2009-11-18
16:14 ---
Hi Nick,
Thoms Schwinge noticed a failure in group-relocations.d:
regexp_diff match failure
regexp "^8074: e1c020d0ldrdr2, \[r0\]$"
line "8074: e1c020d0
--- Additional Comments From nickc at redhat dot com 2009-11-18 09:14
---
Hi Chris,
> On another note, do you have any tricks to make me feel confident we aren't
> introducing bugs?
Tricks no. But the newly patched disassembler does not introduce any
regressions into the GAS testsuite
--- 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_d
--- Additional Comments From nickc at redhat dot com 2009-11-17 17:25
---
Hi Chris,
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 obsole
--- Additional Comments From nickc at redhat dot com 2009-11-17 17:22
---
Created an attachment (id=4392)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4392&action=view)
More fixes
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10924
--- You are receiving this mail
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-11-17
17:20 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-11-17 17:20:26
Modified files:
gas/testsuite : ChangeLog
gas/testsuite/gas/
--- 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 ope
--- Additional Comments From nickc at redhat dot com 2009-11-11 09:54
---
Hi Chris,
> I would just suggest making the warning a comment so that
> the output of objdump still can be run through gas.
Good point - I will make that change.
> On another note, do you have any links explaini
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-11-11
09:45 ---
Subject: Bug 10924
CVSROOT:/cvs/src
Module name:src
Changes by: ni...@sourceware.org2009-11-11 09:44:46
Modified files:
opcodes: ChangeLog arm-dis.c
Log message:
--- 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 th
--- Additional Comments From nickc at redhat dot com 2009-11-10 10:32
---
Hi Chris,
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>:
--- Additional Comments From nickc at redhat dot com 2009-11-10 10:29
---
Created an attachment (id=4377)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4377&action=view)
Add UNPREDICTABLE warning for insns which use Addressing Mode 3 and P == 0 and
W == 1
--
http://sourcewa
55 matches
Mail list logo
