specified fill value.
Sincerely,
Chris P
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
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
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: bi
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 yo
/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
--- 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 understan
--- 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 unpredicta
--- 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 ;
--- 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 d
--- 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 unpredictab
--- 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
--- 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 appl
--- 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.
--- 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 c
--- 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.
--- 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 d
--- 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 coun
--- 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 d
--- 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
--- 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 d
--- 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 addr
--- 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 d
--- 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 compuls
--- 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 uploa
--- 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 is
--- 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 addr
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
--- 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
--- 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:/
--- 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 w
--- 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".
&
--- 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:
--- 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.or
--- 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
--- 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 some
--- 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
--- 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.
--- 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 i
--- 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
--- 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 paragra
--- 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
--- 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
--- 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
--- 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://sourcewar
--- 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
--- 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
--- 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
--- 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
--
--- 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
--
W
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
--- Y
--- 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
--- 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 t
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-binut
r 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 differen
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/tool
.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
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_bitfie
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
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".
Chr
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
60 matches
Mail list logo
