--- Additional Comments From nickc at redhat dot com 2006-06-23 08:45
---
Hi Anton,
Sorry about the delay in getting back to you. I am a bit swamped at the
moment.
I am uploading a revised patch which I think should take care of this issue
now. The problem appears to be the
--- Additional Comments From nickc at redhat dot com 2006-06-23 08:46
---
Created an attachment (id=1114)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1114action=view)
Improved check for missing aux entries.
--
What|Removed |Added
--- Additional Comments From balkohen at gmail dot com 2006-06-23 14:27
---
Here is a very stripped down localealias.c:
#define __make_section_unallocated(section_string) \
asm (.section section_string \n\t.previous);
#define __sec_comment \\n\t#\
#define libc_freeres_ptr(decl) \
--- Additional Comments From nickc at redhat dot com 2006-06-23 14:30
---
Created an attachment (id=1116)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1116action=view)
Real version of previous patch
--
What|Removed |Added
Hi Martin,
Cope with missing .idata sections when building DataDictionary
is this the complete patch?
No. Bum. I sent you the wrong one. Sorry about that. I have uploaded
the proper version this time.
Cheers
Nick
___
bug-binutils
--- Additional Comments From nickc at redhat dot com 2006-06-23 14:31
---
Subject: Re: ld terminated with signal 11 [Segmentation fault]
Hi Martin,
Cope with missing .idata sections when building DataDictionary
is this the complete patch?
No. Bum. I sent you the wrong one.
John Reiser:
On x86, the byte sequence {0xc7,0310,1,2,3,4} superficially looks like move
immediate to r/m dword because of the opcode 0xC7. Actually, it is an illegal
instruction because 0!=(070 mod_rm); namely, the 0310 should be 0300. Gdb
disassembly should report illegal instruction, but
--- Additional Comments From web-sources dot redhat dot com at
jankratochvil dot net 2006-06-23 15:07 ---
Created an attachment (id=1117)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1117action=view)
libopcodes CVS version patch
When I upgraded to binutils 2.16.91 20060413, I started seeing an error when
compiling legacy C++ code with GCC 3.3. The error can be reproduced like this:
// a.cc:
#include boost/format.hpp
std::string f1()
{
return boost::format(x).str();
}
// b.cc:
#include boost/format.hpp
std::string
On Mon, 2006-06-19 at 23:49, cgray at cse dot unsw dot edu dot au wrote:
ld on ia64 applies LTOFF22X and LDXMOV relocations at linktime, voilating the
ABI.
If you read the documentation for LTOFF22X and LDXMOV, it clearly says
that they are link time optimizations. So there is no ABI
--- Additional Comments From wilson at specifix dot com 2006-06-23 21:02
---
Subject: Re: New: ld incorrect applies LTOFF22X/LDXMOV
relocations
On Mon, 2006-06-19 at 23:49, cgray at cse dot unsw dot edu dot au wrote:
ld on ia64 applies LTOFF22X and LDXMOV relocations at
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
doctor electron [EMAIL PROTECTED] writes:
As author of the HotBasic compiler for Windows, in porting same
to Linux, I find that ld does not properly link relative
relocations (R_386_PC32) in correct elf32-i386 .o files.
--- Additional Comments From mkoeppe at gmx dot de 2006-06-24 01:29 ---
Hi Nick,
thank you very much. Now it does apply and build, and the segfault is away.
Unfortunately, linking is not yet successful, even with result=TRUE, due to
missing symbols, namely .idata$4 and atexit.
I now
--- Additional Comments From mkoeppe at gmx dot de 2006-06-24 01:31 ---
Created an attachment (id=1119)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1119action=view)
cref table from working interix ld
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2729
--- You are
--- Additional Comments From mkoeppe at gmx dot de 2006-06-24 01:32 ---
Created an attachment (id=1120)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1120action=view)
cref table from failing cross ld
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2729
--- You are
Long, long ago, Ian Lance Taylor, a life form in far off space,
emitted:
the four bytes affected by R_386_PC32
Dear Ian, I think a single statement edit would fix ld re rel
relocs: The place where we read the four bytes affected now
is the equivalent of
x = [the four bytes] ...or... mov
16 matches
Mail list logo
