[Bug ld/2659] Problem with partial linking [Was: Assertion triggered in cofflink.c]
--- 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 fact that there are multiple defintions of a symbol, but only one of them has an aux entry and the wrong version of the symbol was being selecetd when the code wanted to process the aux data. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=2659 --- 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 ld/2659] Problem with partial linking [Was: Assertion triggered in cofflink.c]
--- 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=1114&action=view) Improved check for missing aux entries. -- What|Removed |Added Attachment #1047 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=2659 --- 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 gas/2756] m68k-linux still has #APP/#NO_APP issue
--- 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) \
__make_section_unallocated ("__libc_freeres_ptrs, \"aw\", %nobits") \
decl __attribute__ ((section ("__libc_freeres_ptrs" __sec_comment)))
extern void *realloc(void *ptr, int size);
struct alias_map
{
const char *alias;
const char *value;
};
libc_freeres_ptr (static struct alias_map *map);
libc_freeres_ptr (static char *string_space);
static int string_space_max;
int
read_alias_file (fname, fname_len)
const char *fname;
int fname_len;
{
int added = 0;
int alias_len = 0;
int value_len = 0;
int new_size = (string_space_max + (alias_len + value_len > 1024 ? alias_len +
value_len : 1024));
char *new_pool = (char *) realloc (string_space, new_size);
int i;
for (i = 0; i < 10; i++)
{
map[i].alias += new_pool - string_space;
map[i].value += new_pool - string_space;
}
return added;
}
const char *
_nl_expand_alias (name)
const char *name;
{
int added = 0;
static const char *locale_alias_path = "/share/locale";
while (added == 0 && locale_alias_path[0] != '\0')
{
const char *start;
while (locale_alias_path[0] == ':')
++locale_alias_path;
start = locale_alias_path;
if (start < locale_alias_path)
added = read_alias_file (start, locale_alias_path - start);
}
return '\0';
}
$ m68k-unknown-linux-gnu-gcc -v
Using built-in specs.
Target: m68k-unknown-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/home/lior/builds/m68k/cdk
--disable-nls --target=m68k-unknown-linux-gnu --disable-shared --disable-threads
--disable-libmudflap --disable-libssp --enable-languages=c
Thread model: single
gcc version 4.1.1
$ m68k-unknown-linux-gnu-as --version
GNU assembler 2.17.50.0.2 20060526
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `m68k-unknown-linux-gnu'.
$ m68k-unknown-linux-gnu-gcc -Wall -O -c localealias.c
/tmp/ccF8XX4h.s: Assembler messages:
/tmp/ccF8XX4h.s:72: Error: junk at end of line, first unrecognized character is
`"'
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2756
--- 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 ld/2729] ld terminated with signal 11 [Segmentation fault]
--- 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=1116&action=view) Real version of previous patch -- What|Removed |Added Attachment #1112 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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 ld/2729] 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. Sorry about that. I have uploaded the proper version this time. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2729] ld terminated with signal 11 [Segmentation fault]
--- 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. Sorry about that. I have uploaded the proper version this time. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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/2829] New: bad disassembly for 0xC7 /1 "movl $___,"
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 instead says "movl
$0x4030201,%eax".
Please see the original post:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172034
Steps to Reproduce:
1. Compile and run this program under gdb:
-foo.S
_start: .globl _start
nop; int3
.byte 0xc7,0310,1,2,3,4
nop; nop
-
$ gcc -o foo -nostartfiles -nostdlib foo.S
$ gdb foo
(gdb) run
2.
3.
Actual Results: Program received signal SIGTRAP, Trace/breakpoint trap. ## as
expected for 'int3'
0x08048076 in _start ()
(gdb) x/i $pc
0x8048076 <_start+2>: mov$0x4030201,%eax ## gdb says it's OK
(gdb) stepi
Program received signal SIGILL, Illegal instruction. ## CPU rejects
0x08048076 in _start ()
0x8048076 <_start+2>: mov$0x4030201,%eax
(gdb)
Expected Results: Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048076 in _start ()
(gdb) x/i $pc
0x8048076 <_start+2>: (bad) ## modrm of 0310 is illegal for opcode 0xC7
--
Summary: bad disassembly for 0xC7 /1 "movl $___,"
Product: binutils
Version: 2.18 (HEAD)
Status: NEW
Severity: minor
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: web-sources dot redhat dot com at jankratochvil dot net
CC: bug-binutils at gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=2829
--- 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/2829] bad disassembly for 0xC7 /1 "movl $___,"
--- 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=1117&action=view)
libopcodes CVS version patch
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172034
See IA-32 Intel® Architecture Software Developer's Manual Volume 2B:
Instruction Set Reference, N-Z, page 434 (of 582),
http://download.intel.com/design/Pentium4/manuals/25366719.pdf
Opcodes 0xC6 and 0xC7 do not have ('reg' (Bits 5,4,3) != 0) defined.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2829
--- 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 ld/2834] New: Linker reports error "X referenced in section '.rodata' of foo.o: defined in discarded section X of foo.o" with g++ 3.3
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
std::string f1()
{
return boost::format("x").str();
}
// b.cc:
#include
std::string f2()
{
return boost::format("y").str();
}
// main.cc:
#include
#include
using namespace std;
string f1();
string f2();
int main()
{
printf("%s %s\n", f1().c_str(), f2().c_str());
return 0;
}
Then:
$ g++-3.3 a.cc b.cc main.cc
`.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh'
referenced in section `.rodata' of /tmp/cchMh54t.o: defined in discarded section
`.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh'
of /tmp/cchMh54t.o
collect2: ld returned 1 exit status
parse_printf_directive, mentioned in mangled form in the error messsage, is a
Boost function that gets called from format().
In older binutils (16.91 20060118) I could work around the bug by specifying the
-g flag, which caused the bug to go away. That workaround, however, no longer
works in 2.16.91 20060413.
--
Summary: Linker reports error "X referenced in section '.rodata'
of foo.o: defined in discarded section X of foo.o" with
g++ 3.3
Product: binutils
Version: 2.16
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: hniksic at xemacs dot org
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=2834
--- 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 ld/2809] 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 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 violation here. However, you do have a point. There is an internal consistency problem in the IA-64 ABI. There is one place where it says segments (not sections) can be arbitrarily remapped at load time, and there is another place where it says you can perform a link time optimization that requires that the relative mapping of gp addressable segments is preserved at load time. I see nothing that resolves this conflict. This is a bug in the IA-64 ABI that should be reported to the maintainers of the ABI. The LTOFF22X/LDXMOV stuff was added late, long after the original ABI was written. I suspect that the only people who ever thought that segment remapping at load time was a good idea was the Monterey project folks, and that project died a long time ago. So when people added the LTOFF22X optimization, they didn't realize that it conflicted with the old stuff that allowed arbitrary segment remapping. Unfortunately, the ABI may not be fixed in a way that helps you, since probably remapping of segments at load time will be restricted to ensure that the LTOFF22X reloc continues working. Meanwhile, it appears that you have the right to remap gp addressable data segments to different places with the current ABI. I would question the wisdom of doing this though. You risk gp overflows for large programs. You disable a link-time optimization, resulting in slower code. Either you fail to perform the optimization, or you have to do it every time the code is loaded instead of just once at link time. It seems an unwise choice unless you have an important reason for doing. But since you insist on doing it, we need to modify the linker to allow you do to this. However, there is no way that we are going to change the behaviour of linux here. We can add a configuration option for your OS, so that it can be enabled by default. This means we need a configure tuple for your OS, which will then work differently than all existing ia64 operating systems. Since you are writing the OS, you may need to do some of this work yourself. I don't have your target configure tuple, nor do I have a copy of your OS to test against, nor do I know any other details of your OS. What you will want to do here is add a new vector for your OS to bfd, and then modify the elfxx-ia64.c file, in the function elfNN_ia64_relax_section to check the vector, and disable the LTOFF22X and LDXMOV optimizations when this vector is true. See for instance how the ia64_hpux_big_vec stuff works. Just grep for that and write something very similar for your target. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/2809] ld incorrect applies LTOFF22X/LDXMOV relocations
--- 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 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 violation here. However, you do have a point. There is an internal consistency problem in the IA-64 ABI. There is one place where it says segments (not sections) can be arbitrarily remapped at load time, and there is another place where it says you can perform a link time optimization that requires that the relative mapping of gp addressable segments is preserved at load time. I see nothing that resolves this conflict. This is a bug in the IA-64 ABI that should be reported to the maintainers of the ABI. The LTOFF22X/LDXMOV stuff was added late, long after the original ABI was written. I suspect that the only people who ever thought that segment remapping at load time was a good idea was the Monterey project folks, and that project died a long time ago. So when people added the LTOFF22X optimization, they didn't realize that it conflicted with the old stuff that allowed arbitrary segment remapping. Unfortunately, the ABI may not be fixed in a way that helps you, since probably remapping of segments at load time will be restricted to ensure that the LTOFF22X reloc continues working. Meanwhile, it appears that you have the right to remap gp addressable data segments to different places with the current ABI. I would question the wisdom of doing this though. You risk gp overflows for large programs. You disable a link-time optimization, resulting in slower code. Either you fail to perform the optimization, or you have to do it every time the code is loaded instead of just once at link time. It seems an unwise choice unless you have an important reason for doing. But since you insist on doing it, we need to modify the linker to allow you do to this. However, there is no way that we are going to change the behaviour of linux here. We can add a configuration option for your OS, so that it can be enabled by default. This means we need a configure tuple for your OS, which will then work differently than all existing ia64 operating systems. Since you are writing the OS, you may need to do some of this work yourself. I don't have your target configure tuple, nor do I have a copy of your OS to test against, nor do I know any other details of your OS. What you will want to do here is add a new vector for your OS to bfd, and then modify the elfxx-ia64.c file, in the function elfNN_ia64_relax_section to check the vector, and disable the LTOFF22X and LDXMOV optimizations when this vector is true. See for instance how the ia64_hpux_big_vec stuff works. Just grep for that and write something very similar for your target. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2809 --- 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 elf32-i386 R_386_PC32 done wrong
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. > >GNU ld is correct according to the ELF ABI Processor Supplement for >i386 Processors. Thank you for your reply, Ian. The first smoking gun was described in my first email: ld overshoots the target for rel relocs within module by 4 bytes. This is undeniably a linker failure. The processor adds the value in the rel relocated address to eip ... and, period; that's it. ld does not know how i386 and essentially all other microprocessors work. There is no other credible explanation. >In typical use, the .o file will contain a 0xfffc in the four >bytes affected by R_386_PC32. Yes, this is what I predicted in my previous email and found in files such as acquirew.o; and which you now admit -- that all .o and .so files have to have a -4 fudge factor placed in such locations by compilers since ld knows not how to do rel relocs. If not fixed, the ld manual should, I think, "come clean" on this an state plainly that ld fails on rel relocs since it requires object files to contain a fudge factor to prevent this failure. The one and only formula for rel relocs is: S - (A + 4) where S is the symbol address and A is the location to be relocated relatively (the 4 byte field after E8 for example). Notice that the contents of that E8 field in the .obj or .o is irrelevant, it should be overwritten. [This is why it looks ridiculous (!) to see -4 in these locations in existing linux .o and .so files -- really looks like people have no idea what they are doing -- KeyStone Cops. I would like to be an advocate/promoter of Linux, but this, my friend, is totally second-class.] All the compiler has to do is allocate a 4-byte field with *any* value in the .obj or .o file and make an entry for it in the rel reloc table. The linker should *never* read the value in this rel reloc address; rather it should put the correct offset in it. This table contains entries of three values and the third is a code that the entry is absolute or relative relocation. So we are down to two values, which are precisely the S and A values above. For each module in the link, both values are referenced to the beginning of the .text (code) section -- 0. Thus, if a linker is concatenating .text sections from multiple modules (aligned 16 as we have seen), the "0" address for both S and A needs to be adjusted (but only when S and A are in different modules originally). Anyway, once you have the right S and A values, the formula above is applied and the result is stored at the A address. And you know why the formula works -- it is the way the processors work -- purely hardware related. Knowledge of how microprocessors work (re adding the offset to eip) goes back the beginning of the very first microprocessors of any kind. This is why it is amazing that *both* compiler writers and linker writers in linux seem to be completely uninformed about how the processors they use work, even in their best known and simplest aspects. Anyone who sees those -4's in existing .o and .so files cannot conclude anything other than "this Linux is bound together with rubber bands." SUMMARY: The two S and A values in the rel reloc table entries are the only thing needed to write the relocs into the executable. So I humbly ask again: Where is this code, so e might best find this code in ld, rewrite it correctly, and then ld would link all i386 formats, for both good and existing (contain the -4 gibberish) input files. This code might be buried in some include or bfd (?) module called by ld, but whatever it is, it seems to be feasible to do a completely general and complete fix to the benefit of all linux users. Since a rel-reloc-fixed ld would not read the -4 values, it would work both for good and fudge-factored (existing Linux) input files. As it is, this ld failure prevents porting valid object files into a Linux environment. Surely, Linux people do not intend to say, "Do not enter here", to the public looking at Linux. >R_386_PC32 is defined to add the PC relative offset from the start of the 4 >byte field >to the existing contents of the 4 byte field. Above is wrong. What could possibly be the "trial and error" origin of this definition? [Scenario: In early days of ld and linux-based compilers, someone found that a program ran it -4 was stuck in the object file. If this is true: This is "design by random trial and error"; why not use the real definition of rel relocs? Your statement is a crystal clear acknowledgment that ld is wrong. Thank you. I rest my case. The correct definition, I give above. Let's fix it! Then, gee whiz! People could bring compilers like mine to Linux -- compilers that produce correct object files, and
[Bug ld/2729] ld terminated with signal 11 [Segmentation fault]
--- 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 linked exactly the same files (besides libgcc.a) with --cref, once on original interix with their version of gnu ld, where linking succeeds, and once with my cross compiled ld, and produced 2 cref tables. There is a difference just at these 2 symbols. Could you please have a look? Martin -- http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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 ld/2729] ld terminated with signal 11 [Segmentation fault]
--- 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=1119&action=view) cref table from working interix ld -- http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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 ld/2729] ld terminated with signal 11 [Segmentation fault]
--- 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=1120&action=view) cref table from failing cross ld -- http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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 elf32-i386 R_386_PC32 done wrong
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. > > > >GNU ld is correct according to the ELF ABI Processor Supplement for > >i386 Processors. > > Thank you for your reply, Ian. The first smoking gun was > described in my first email: ld overshoots the target for rel > relocs within module by 4 bytes. This is undeniably a linker > failure. The processor adds the value in the rel relocated > address to eip ... and, period; that's it. ld does not know how > i386 and essentially all other microprocessors work. There is > no other credible explanation. Please allow me to repeat: GNU ld is correct according to the ELF ABI Processor Supplement for i386 Processors. If you want to convince anybody, you need to start by reading that document and explaining where GNU ld fails to follow it precisely. > The one and only formula for rel relocs is: > > S - (A + 4) That turns out not to be the case. Read the ABI. > Notice that the contents of that E8 field in the > .obj or .o is irrelevant, it should be overwritten. That turns out not to be the case. Read the ABI. > [This is why it looks ridiculous (!) to see -4 in these > locations in existing linux .o and .so files -- really looks > like people have no idea what they are doing -- KeyStone Cops. > I would like to be an advocate/promoter of Linux, but this, my > friend, is totally second-class.] I note that when we wrote this code Eric Youngdale and I tested it against the ELF linker independently developed for i386 UnixWare (an SVR4 port). The GNU linker correctly handled UnixWare .o files, and vice-versa. So this is hardly a Linux-specific issue. > So I humbly ask again: Where is this code, so e might best find > this code in ld, rewrite it correctly, and then ld would link > all i386 formats, for both good and existing (contain the -4 > gibberish) input files. Look for R_386_PC32 in bfd/elf32-i386.c. But consider the alternatives: 1) Every single existing i386 ELF object file is wrong, every existing i386 ELF linker is wrong, every existing i386 ELF assembler is wrong, the i386 ELF ABI is wrong. or 2) You are wrong. Between those two, I know which one I would pick. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
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 eax,[esi] We need to change that one statement to the equivalent of x = -4 ...or... mov eax,-4 Would you be so kind as to inform us of the file/line number of that statement? If so, we'll recompile (I have a friend who can do that) and test the fixed ld on both my and existing object files. TIA, Jim ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BUG elf32-i386 R_386_PC32 done wrong
> Knowledge of how microprocessors work (re adding the offset to
> eip) goes back the beginning of the very first microprocessors
> of any kind. This is why it is amazing that *both* compiler
> writers and linker writers in linux seem to be completely
> uninformed about how the processors they use work, even in their
> best known and simplest aspects. Anyone who sees those -4's in
> existing .o and .so files cannot conclude anything other than
> "this Linux is bound together with rubber bands."
Interesting. Then your next task is to convince the dumb guys at Sun too
because their toolchain behaves exactly like the Linux toolchain...
bash-2.03$ uname -a
SunOS xxx.xxx.xxx 5.8 Generic_108529-13 i86pc i386 i86pc
bash-2.03$ cat t.s
.text
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
callfoo
leave
ret
bash-2.03$ as -V
as: Sun WorkShop 6 99/08/16
Usage: as [-V] [-Q{y,n}] [-s]
[-S[aAbBcClL]] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-xF] [-F] [-b] [-i] file.s ...
bash-2.03$ as -o t.o t.s
bash-2.03$ dis t.o
DISASSEMBLER
disassembly for t.o
section .text
bar()
0: 55 pushl %ebp
1: 8b ec movl %esp,%ebp
3: 83 ec 08 subl $0x8,%esp
6: e8 fc ff ff ff call
b: c9 leave
c: c3 ret
bash-2.03$ elfdump -r t.o
Relocation Section: .rel.text
type offset sectionwith
respect to
R_386_PC32 0x7 .rel.text foo
http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl28?q=Solaris+10+&s=t&a=view
--
Eric Botcazou
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
