--- Additional Comments From ysato at users dot sourceforge dot jp
2009-12-11 20:53 ---
Created an attachment (id=4465)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4465&action=view)
simply fix.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11086
--- You are recei
../../gas/config/tc-rx.c: In function rx_equ:
../../gas/config/tc-rx.c:898: error: declaration of expr shadows a global
declaration
../../gas/expr.h:173: error: shadowed declaration is here
--
Summary: build failed
Product: binutils
Version: 2.21 (HEAD)
--- 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:
When linking object files using the options --gc-sections and -relax
(MicroBlaze specific option that
removes superfluous "imm 0" instructions), the addresses for some labels are
miscalculated.
Apparently this problem is caused by removing the "imm 0" instructions without
changing the labels'
--- Additional Comments From takis at xfree86 dot org 2009-12-11 16:41
---
simple solution (not implementing the most complicated -G size as gnu ld, jusr
-G as its used on a typical SVR4)
options.h
+ DEFINE_bool(G, options::ONE_DASH, '\0', false,
+ N_("Generate shared li
Gold cannt seem to handle at all dynamic objects (on the final linking stage) if
the dynamic table is not present. (aka objdump -T libfoo.so is empty)
Gnu linker version 2.15 and 2.20 however they dont seem to have a problem with
that issue linkinmg will go through fine.
--
Summary: Go
Gold linker doesnt handle the typical svr4 option -G vfor creating shared
objects. As this option (-G) is implemented for most systems in GNU libtool it
can be a problem for some systems.
--
Summary: Gold does not supports -G option for creating shared
libs
--- Additional Comments From divis1969 at gmail dot com 2009-12-11 14:19
---
Hi,
While running my program with BFD 2.20.51.20090916 (which I had grabbed from
GDB
7.0) I see there is still a possibility for the problem reported by this bug.
It does not crash but produces a message lik
13 matches
Mail list logo
