[Bug binutils/10288] "objdump -D --target=binary -m arm7tdmi" shows non-ARM7TDMI instructions

2009-07-10 Thread chris at seberino dot org

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

2009-07-10 Thread chris at seberino dot org

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

2009-07-10 Thread chris at seberino dot org

--- 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/10382] setting environment variable RM causes binutils build to fail

2009-07-10 Thread amodra at bigpond dot net dot au

--- Additional Comments From amodra at bigpond dot net dot au  2009-07-11 
03:15 ---
$RM is used by libtool to remove files, so of course setting it to something
nonsensical breaks the build.  So does setting a whole lot of other environment
variables.  Not a bug.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=10382

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


Re: binutils 2.19 issue with kernel link

2009-07-10 Thread Alan Modra
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?

/me reads other email.  I see you did.  Applying.

-- 
Alan Modra
Australia Development Lab, IBM


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


Re: binutils 2.19 issue with kernel link

2009-07-10 Thread Alan Modra
On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
> binutils-2.19 _end is what we expect
> binutils-2.19.1   _end is what we expect
> binutils-2.19.50.0.1  _end is what we expect
> binutils-2.19.51.0.1  _end is 1000
>
> From the release notes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106

Yes, I already have good reason to suspect this patch

2008-10-22  Alan Modra  

* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
sections.
* emultempl/elf32.em (enum orphan_save_index): Add orphan_nonalloc.
(hold): Likewise.
(gld${EMULATION_NAME}_place_orphan): Handle non-alloc orphans.

causes the change in linker behaviour.  Did you try the patch I posted?

-- 
Alan Modra
Australia Development Lab, IBM


___
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

2009-07-10 Thread chris at seberino dot org

--- 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/10380] cannot build binutils statically

2009-07-10 Thread schwab at linux-m68k dot org

--- Additional Comments From schwab at linux-m68k dot org  2009-07-10 18:24 
---
binutils uses libtool, and libtool uses -all-static instead.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10380

--- 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/10380] cannot build binutils statically

2009-07-10 Thread booleandomain at gmail dot com

--- Additional Comments From booleandomain at gmail dot com  2009-07-10 
16:01 ---
It seems to work, thanks. But why do I need --static while all other packages
(gmp, mpfr, bash, ...) work with -static? Also, I think there should be a
document either in binutils sources or on the binutils homepage that explains
how to build binutils statically.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10380

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


Re: binutils 2.19 issue with kernel link

2009-07-10 Thread Kumar Gala


On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:


Hmm, having said all that, the following linker patch seems reasonable
to me and probably won't break anything else (always some risk).
Please test it for me.

Index: ld/ldlang.c
===
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.311
diff -u -p -r1.311 ldlang.c
--- ld/ldlang.c 25 Jun 2009 13:18:46 -  1.311
+++ ld/ldlang.c 10 Jul 2009 04:04:57 -
@@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
   idea is to skip over anything that might be inside a SECTIONS {}
   statement in a script, before we find another output section
   statement.  Assignments to "dot" before an output section statement
-   are assumed to belong to it.  An exception to this rule is made  
for

-   the first assignment to dot, otherwise we might put an orphan
-   before . = . + SIZEOF_HEADERS or similar assignments that set the
-   initial address.  */
+   are assumed to belong to it, except in two cases;  The first
+   assignment to dot, and assignments before non-alloc sections.
+   Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
+   similar assignments that set the initial address, or we might
+   insert non-alloc note sections among assignments setting end of
+   image symbols.  */

static lang_statement_union_type **
insert_os_after (lang_output_section_statement_type *after)
@@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
  continue;
case lang_output_section_statement_enum:
  if (assign != NULL)
-   where = assign;
+   {
+ asection *s = (*where)->output_section_statement.bfd_section;
+
+ if (s == NULL || (s->flags & SEC_ALLOC) != 0)
+   where = assign;
+   }
  break;
case lang_input_statement_enum:
case lang_address_statement_enum:

--


This patch seems to "fix" things.

- k


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/10382] New: setting environment variable RM causes binutils build to fail

2009-07-10 Thread mariah dot lenox at gmail dot com
Setting the environment variable RM causes binutils build ('make') to fail.
You should be able to duplicate this by setting the environment variable
RM to anything nonsensical.

-- 
   Summary: setting environment variable RM causes binutils build to
fail
   Product: binutils
   Version: 2.19
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: mariah dot lenox at gmail dot com
CC: bug-binutils at gnu dot org
 GCC build triplet: x86_64-unknown-linux
  GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux


http://sourceware.org/bugzilla/show_bug.cgi?id=10382

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


Re: binutils 2.19 issue with kernel link

2009-07-10 Thread Kumar Gala


On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:



On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:

On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797  
wrote:
I understand your arguments, but there is something inconsistent  
about this.

If I change the script to be:
 _end3 = . ;
 . = _end3;
 . = ALIGN(PAGE_SIZE);
 _end = . ;
 PROVIDE32 (end = .);
}
The result is corrected:
c067f678 A _end3
c068 A _end

Why the apuinfo section with zero VMA sometimes interfere with "."  
and

sometimes not ?


I said it was weird in my last email.  Not so.  The orphan gets  
placed

between

 _end3 = . ;
 . = _end3;

So dot is restored after the orphan section sets it.


This seems to be a bit of a chick and egg scenario.  Older kernel  
linker scripts aren't going to cover all sections and thus may have  
orphan sections.  How do we ensure _end can be set properly under  
such conditions?


Not sure if this helps, but I've isolated down the version of binutils  
that changes to:


binutils-2.19   _end is what we expect
binutils-2.19.1 _end is what we expect
binutils-2.19.50.0.1_end is what we expect
binutils-2.19.51.0.1_end is 1000

From the release notes:

binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
binutils-2.19.51.0.1 is based on CVS binutils 2009 0106

- k


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/10380] cannot build binutils statically

2009-07-10 Thread nickc at redhat dot com

--- Additional Comments From nickc at redhat dot com  2009-07-10 15:17 
---
Subject: Re:  New: cannot build binutils statically

Hi,

> I'm trying to build binutils-2.19.1 statically. I tried with
> ../binutils-2.19.1/configure LDFLAGS="-static" && make but I get:

Try adding a second dash.  ie:

   ../binutils-2.19.1/configure LDFLAGS="--static" && make

Cheers
   Nick



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10380

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


Re: [Bug binutils/10380] New: cannot build binutils statically

2009-07-10 Thread Nick Clifton

Hi,


I'm trying to build binutils-2.19.1 statically. I tried with
../binutils-2.19.1/configure LDFLAGS="-static" && make but I get:


Try adding a second dash.  ie:

  ../binutils-2.19.1/configure LDFLAGS="--static" && make

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


Re: binutils 2.19 issue with kernel link

2009-07-10 Thread Kumar Gala


On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:

On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797  
wrote:
I understand your arguments, but there is something inconsistent  
about this.

If I change the script to be:
  _end3 = . ;
  . = _end3;
  . = ALIGN(PAGE_SIZE);
  _end = . ;
  PROVIDE32 (end = .);
}
The result is corrected:
c067f678 A _end3
c068 A _end

Why the apuinfo section with zero VMA sometimes interfere with "."  
and

sometimes not ?


I said it was weird in my last email.  Not so.  The orphan gets placed
between

  _end3 = . ;
  . = _end3;

So dot is restored after the orphan section sets it.


This seems to be a bit of a chick and egg scenario.  Older kernel  
linker scripts aren't going to cover all sections and thus may have  
orphan sections.  How do we ensure _end can be set properly under such  
conditions?


- k


___
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

2009-07-10 Thread nickc at redhat dot com

--- Additional Comments From nickc at redhat dot com  2009-07-10 08:21 
---
Hi Chris,

> Unfortunately, I must report that once again we need to remove instructions 
> that don't belong like mrrc, blx, ldc2, usat, etc.

I am still not seeing this.  You will have to show me a way to reproduce the 
effect.

Not for reference this is what I am currently seeing with my local test case:

  % cat 10288.s

.text
  foo:
.word 0x4c585ee5
.word 0x01a23597
.word 0x3d9da24e
.word 0x46647659
.word 0x77c1cdb4
.word 0xe640361f
.word 0x4c585ee5
.word 0xd446399e
.word 0x11d87ed1
.word 0x44afa697
.word 0xd4bf78b4
.word 0xbc041350
nop
.word 0x4c585ee5
.word 0xfd37a04f
.word 0xfabf5236
.word 0x46647659@strbmi  r7, [r4], -r9, asr r6
.word 0x77c1cdb4@strbvc  ip, [r1, r4, lsr sp]
.word 0xe640361f@strbr3, [r0], -pc, lsl r6
.word 0x3d9da24e@lfmcc   f2, 1, [sp, #312]

  % arm-eabi-as 10288.s -o 10288.o
  % arm-eabi-objdump -D -j .text -marm7tdmi 10288.o

   0:   4c585ee5ldclmi  14, cr5, [r8], {229}; 0xe5
   4:   01a23597undefined instruction 0x01a23597
   8:   3d9da24elfmcc   f2, 1, [sp, #312]   ; (ldccc 2, cr10, [sp,
#312])   ; 0x138
   c:   46647659undefined instruction 0x46647659
  10:   77c1cdb4undefined instruction 0x77c1cdb4
  14:   e640361fundefined instruction 0xe640361f
  18:   4c585ee5ldclmi  14, cr5, [r8], {229}; 0xe5
  1c:   d446399estrble  r3, [r6], #-2462; 0x99e
  20:   11d87ed1ldrsbne r7, [r8, #225]  ; 0xe1
  24:   44afa697strtmi  sl, [pc], #1687 ; 2c 
  28:   d4bf78b4ldrtle  r7, [pc], #2228 ; 30 
  2c:   bc041350stclt   3, cr1, [r4], {80}  ; 0x50
  30:   e1a0nop ; (mov r0, r0)
  34:   4c585ee5ldclmi  14, cr5, [r8], {229}; 0xe5
  38:   fd37a04fundefined instruction 0xfd37a04f
  3c:   fabf5236undefined instruction 0xfabf5236
  40:   46647659undefined instruction 0x46647659
  44:   77c1cdb4undefined instruction 0x77c1cdb4
  48:   e640361fundefined instruction 0xe640361f
  4c:   3d9da24elfmcc   f2, 1, [sp, #312]   ; (ldccc 2, cr10, [sp,
#312])   ; 0x138

  % arm-eabi-objdump -D -j .text 10288.o

   0:   4c585ee5mrrcmi  14, 14, r5, r8, cr5
   4:   01a23597undefined instruction 0x01a23597
   8:   3d9da24elfmcc   f2, 1, [sp, #312]   ; (ldccc 2, cr10, [sp,
#312])   ; 0x138
   c:   46647659undefined instruction 0x46647659
  10:   77c1cdb4undefined instruction 0x77c1cdb4
  14:   e640361fundefined instruction 0xe640361f
  18:   4c585ee5mrrcmi  14, 14, r5, r8, cr5
  1c:   d446399estrble  r3, [r6], #-2462; 0x99e
  20:   11d87ed1ldrsbne r7, [r8, #225]  ; 0xe1
  24:   44afa697strtmi  sl, [pc], #1687 ; 2c 
  28:   d4bf78b4ldrtle  r7, [pc], #2228 ; 30 
  2c:   bc041350stclt   3, cr1, [r4], {80}  ; 0x50
  30:   e1a0nop ; (mov r0, r0)
  34:   4c585ee5mrrcmi  14, 14, r5, r8, cr5
  38:   fd37a04fldc20, cr10, [r7, #-316]!   ; 0xfec4
  3c:   fabf5236blx fefd491c 
  40:   46647659undefined instruction 0x46647659
  44:   77c1cdb4undefined instruction 0x77c1cdb4
  48:   e640361fundefined instruction 0xe640361f
  4c:   3d9da24elfmcc   f2, 1, [sp, #312]   ; (ldccc 2, cr10, [sp,
#312])   ; 0x138


Cheers
  Nick



-- 


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