--- Additional Comments From ths at networkno dot de 2007-03-20 10:42
---
The answer is "it depends", see gas/config/tc-mips.c:reloc_needs_lo_p. But this
depends also on gas/config/tc-mips.c:11755. I figure this doesn't happen with
recent gcc versions. Maybe it makes sense to downgrade t
--
What|Removed |Added
CC||ths at networkno dot de
http://sourceware.org/bugzilla/show_bug.cgi?id=4208
--- You are receiving this ma
--- Additional Comments From nickc at redhat dot com 2007-03-20 10:53
---
Created an attachment (id=1631)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=1631&action=view)
patch.3 + zero-initialise memory allocated for group date
--
http://sourceware.org/bugzilla/show_bug.cgi
--- Additional Comments From nickc at redhat dot com 2007-03-20 10:55
---
Hi Sami,
OK I have another patch for you to try. (Please remove patch.3 first).
I could not reproduce the failure, but looking at the logs you attached it
appears that we need to zero-fill the memory allocat
--- Additional Comments From nickc at redhat dot com 2007-03-20 12:18
---
Patch applied with this ChangeLog
bfd/ChangeLog
2007-03-20 Nick Clifton <[EMAIL PROTECTED]>
PR binutils/3535
* elf.c (copy_private_bfd_data): Widen the scope of Solaris
specific conditio
Hi Kelvin,
and then run strip from binutils-2.17 on the output binary.
This problem has already been reported and fixed. Please try using the
latest binutils sources from the mainline of the CVS repository. For
more information on the bug and the fix please see issue 3535:
http://sourcew
--- Additional Comments From pkoning at equallogic dot com 2007-03-20
14:02 ---
I ran into this issue with GCC 4.1.2, so I'm not sure about it not happening
with newer compilers.
A warning doesn't help, because it's as bad as an error when you build with
"warnings are errors" as many do
On x86_64 the 0x90 opcode can be prefixed with a rexB prefix allowing it to
access the extended register r8 (see AMD64 V3, pg. 289 and 378). However,
objdump incorrectly displays this as a prefixed nop:
11: 41 90 rexZ nop
This should read:
11: 41 90 xchg %r8, %rax
If prefixed with 0x66 as
--- Additional Comments From nickc at redhat dot com 2007-03-20 14:49
---
Created an attachment (id=1632)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=1632&action=view)
Disable conversion to non-h8300 formats whilst linking h8300 binaries
--
http://sourceware.org/bugzilla/
--- Additional Comments From fruffell at cs dot uwaterloo dot ca
2007-03-20 14:51 ---
Created an attachment (id=1633)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=1633&action=view)
A test case illustrated the a rexB prefixed 0x90 instruction is not a nop.
gcc -c xchg-eax-stub.
--- Additional Comments From hjl at lucon dot org 2007-03-20 14:52 ---
I agreed that a warning is useless since there is nothing a user can do when
assembler and linker don't agree on unmachted HI16 relocation. If assembler
believes that an unmachted HI16 relocation is OK, it shouldn't le
--- Additional Comments From nickc at redhat dot com 2007-03-20 14:54
---
Hi Diego,
This is a known problem for quite a lot of linker targets. Converting to the
binary file format at the same time as performing a final link rarely works and
it is always safer to perform a non-transfo
--- Additional Comments From ths at networkno dot de 2007-03-20 15:25
---
AFAICS it is a compiler bug, and assembler/linker used to work around it. Now
the linker trips over it. Since the bug seems still to be unfixed, a warning
might in fact be unhelpful, as there is no widely deployed
Hello,
I am cross compiling an eCos application and am hitting an internal
error with ld.
When linking the application it fails with the error:
ld: internal error /src/binutils-2.17/ld/ldlang.c 3803
Host system is cygwin x86, target is PPC866. ld version 2.17.50 20060817
I find that when I
14 matches
Mail list logo
