[Bug ld/2659] Problem with partial linking [Was: Assertion triggered in cofflink.c]
--- Additional Comments From asl at math dot spbu dot ru 2006-06-24 12:15 --- Nick, Now no assertions at all. Files look fine. However, I don't have a complete build system & sources which the attached .o files was taken from. So I don't know the results of linking. I'll let you know the results of linking the whole program (I hope, everything will be ok) in 4-5 days. -- 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 binutils/2842] New: Objcopy fails on AIX 5.1
I would like to localize symbols within an unlinked object file on AIX 5.1.
However it seems that the symbols doesn't really get localized by
examining 'nm' output:
test.cpp:
#include
#include
void foo()
{
printf("foo\n");
}
void bar()
{
printf("bar\n");
}
int main()
{
foo();
bar();
return 0;
}
bash-3.00# nm test.o
0148 d .data
0148 D _GLOBAL__F__Z3foov
U __gxx_personality_v0
0208 d LC..0
0210 d LC..2
0130 D main
0130 d main
00a0 T .main
U .printf
00f0 t _test.rw_cpp
t .text
0208 d TOC
0118 d _Z3barv
0118 D _Z3barv
0050 T ._Z3barv
0100 d _Z3foov
0100 D _Z3foov
T ._Z3foov
bash-3.00# objcopy -G main test.o test2.o
bash-3.00# nm test2.o
0148 d .data
0148 D _GLOBAL__F__Z3foov
U __gxx_personality_v0
0208 d LC..0
0210 d LC..2
0130 D main
0130 d main
00a0 T .main
U .printf
00f0 t _test.rw_cpp
t .text
0208 d TOC
0118 d _Z3barv
0118 D _Z3barv
0050 T ._Z3barv
0100 d _Z3foov
0100 D _Z3foov
T ._Z3foov
Looking at the last output foo and bar symbols are the same as before.
Also when compiling with 'g++ -maix64' switch on large objects (around 1 mb)
objcopy fails by generating bad code:
(objcopy -G main in.o out.o was invoked prior to this command)
gcc -maix64 -lpthread -o test-broken broken.o
ld: 0711-590 SEVERE ERROR: Object lmxserverrtw.o cannot be processed.
The length field at the beginning of the string table is invalid.
collect2: ld returned 12 exit status
A broken object file (which worked fine prior to being processed with objcopy)
can be given upon request to [EMAIL PROTECTED]
--
Summary: Objcopy fails on AIX 5.1
Product: binutils
Version: 2.17
Status: NEW
Severity: enhancement
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: henrik_goldman at mail dot tele dot dk
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=2842
--- 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: AIX 5.1 objcopy copy problem in 64 bit mode.
Hi Nick, Try checking out the latest binutils sources from the CVS repository. It is possible that this bug has already been fixed. I have tried it with the latest release 2.17 and the problem still remains. If not, then please could you open an official bug report and include a test case which reproduces the problem ? (A copy of the corrupt test.o file would also help as we could examine it ourselves to see what has happened to the string table). A bug report has been filed: http://sourceware.org/bugzilla/show_bug.cgi?id=2842 A corrrupted object file can be given upon to request. Unfortunatly I cannot upload this to public download. However I'd be happy to give it to anyone who want a copy for debugging purposes. Thanks in advance. -- Henrik ___ 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
> As you might see in Ian's thoughtful reply, I don't think he > gets the point (maybe my failure to communicate well): The latter, really, I'm afraid. > Clearly, ld is using the correct formula; the issue is *where* > it gets the constant -4. If it did not try to read this from > the input file, then all object files would be correctly > relocated -- not just the ones that have -4 in them. I argue > that this would be beneficial to Linux (Sun would be forced to > follow on the quality upgrade in OS flag-ship linker). Maybe, but you are 20 years late. The ABI was set in stone "long, long ago" as you write it in your messages and neither you nor us can change it now. > If, as Ian pointed out in his second reply (thank you), this is > a very pervasive problem -- requiring all inputs to have -4 > constants inserted by third party (compiler) programs, and now > you add Sun, too, this is a big, news-worthy story -- involving > issues of the "image" or "appearance" of competence and > integrity in the Linux OS. It's not Linux, it's Solaris, FreeBSD, QNX, Interix... you name it. -- Eric Botcazou ___ 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, Eric Botcazou, a life form in far off space, emitted: >Interesting. Then your next task is to convince the dumb guys at Sun too >because their toolchain behaves exactly like the Linux toolchain... Thanks for this info, Eric. As you might see in Ian's thoughtful reply, I don't think he gets the point (maybe my failure to communicate well): ld can get the -4 on its own, rather than read it from "typical" input files and thereby conform to the rel reloc formula *and* remove the requirement that .o files contain -4 at all those locations, which must be a continuing source of shame and embarrassment to writers of existing Linux compilers (nasm, C, etc). Note that if ld coughs up its own -4 (per the formula I posted), all the existing .o/.so files would still link -- the -4 is a *constant* in the hardware-based formula and its presence in those .o/.so files should properly be ignored [so correct input files with any arbitrary value (e.g., 0) in those locations would also link]. Think about it, it is not so much as being right or wrong, smart or dumb (ld covers a huge range of architectures and formats; clearly its writers are very "smart"). ld's problem is that it must get the constant -4 from input files, when in fact, it does not need to be in the input files (the compiler making those only needs to allocate the "place-holder" 4 bytes addressed in the rel reloc entry). Clearly, ld is using the correct formula; the issue is *where* it gets the constant -4. If it did not try to read this from the input file, then all object files would be correctly relocated -- not just the ones that have -4 in them. I argue that this would be beneficial to Linux (Sun would be forced to follow on the quality upgrade in OS flag-ship linker). Does it not seem lame to require compiler writers to put a -4 gibberish in their object file outputs for the only reason that ld can't cough up a -4 all by itself? If, as Ian pointed out in his second reply (thank you), this is a very pervasive problem -- requiring all inputs to have -4 constants inserted by third party (compiler) programs, and now you add Sun, too, this is a big, news-worthy story -- involving issues of the "image" or "appearance" of competence and integrity in the Linux OS. Notice Ian gave no rationale beyond what I might call "This is the way we do it" and "Some ABI document covers us", as if any document changes how existing processors work. Nor did Ian even challenge my formula (which is really the formula of microprocessor makers). Rather he seemed to me to rely on "We all say this is it so it must be it", instead of addressing the absurdity of reading the constant -4 from input files in the first place, and thereby requiring third parties (compiler writers) to, in essence, corrupt their output files by mindlessly inserting this -4 constant at rel reloc addresses. SUMMARY: Your Sun data only confirms my analysis and augments the dimension of this big story. When and if this becomes public, so to speak, what are proponents of requiring the -4 constants in object files going to say? From what we see in this thread of posts, will they have nothing credible that makes any sense -- other than some ABI doc says it's OK? The enquiring public will want more substance than that. Me, I think we on this end can fix ld. So if Linux developers don't want to fix this; that's fine, the loss is reduced Linux credibility, I think. Worst, your compiler developers are hung out to dry: they are "innocent", so to speak, but are forced by ld developers to take the hit because they have no rational explanation of the -4's in their output files other than ld can't do rel relocs all by itself. The implications of an article -- "Scandal in Linux Cyberspace" -- documenting this "big story" are many. Why was this not fixed years ago? How could such an ill-conceived design (an object file must have a constant for a linker) ever have become a "canon of Linux"? Did these developers not realize that the linker outputs run only because the linker itself seems unaware of the correct formula and just needs to make its own -4 and not read it from object files? It seems that on historic development day 2, this constant would have be "moved" into linker code -- but that did not happen -- why? Why do Linux developers appear to want to keep correct .o files (no -4 constants in there) out of the Linux environment? Is the intent to keep quality software out of the Linux environment? The larger computing world outside Linux/Sun, etc, also has smart people producing useful object files -- in business, math, science, you name it. But ld does not know how to link them! What message are you sending? Is the message that objcopy writers now must also go in and insert the -4's in .text sections when converting from .obj to .o? All because ld can't find its own -4? [Free gift, cut and paste any -4 in this post and put it in ld source code!] In the absence o
Re: BUG elf32-i386 R_386_PC32 done wrong
> If so, the market will decide; is a corrected ld favored or not. It's already decided: your proposed change would break the ABI, hence break binary compatibility by definition. > That's the marvel. Why was this not corrected 20 years ago? Because, if you really think about it, the current definition of R_386_PC32 is the right one. > Are you saying, "Linux cannot be improved?" Seems so. IMHO, > not good public relations re promoting the OS. Again, it's not Linux, the i386 ABI predates Linux, Linux only conformed to the existing ABI. -- Eric Botcazou ___ 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 you might see in Ian's thoughtful reply, I don't think he > gets the point (maybe my failure to communicate well): I completely understood what you said. > ld can get the -4 on its own, rather than read it from "typical" > input files and thereby conform to the rel reloc formula *and* > remove the requirement that .o files contain -4 at all those > locations, which must be a continuing source of shame and > embarrassment to writers of existing Linux compilers (nasm, C, > etc). Note that if ld coughs up its own -4 (per the formula I > posted), all the existing .o/.so files would still link -- the > -4 is a *constant* in the hardware-based formula and its > presence in those .o/.so files should properly be ignored [so > correct input files with any arbitrary value (e.g., 0) in those > locations would also link]. If you ignore the contents of the .o file, then how do you propose to handle the assembler code call foo + 16 ? With the ELF ABI as designed and implemented, it is easy. This type of code can arise when the compiler implements alternate entry points for functions: one external to the file and one internal. > Notice Ian gave no rationale beyond what I might call "This is > the way we do it" and "Some ABI document covers us", as if any > document changes how existing processors work. We have an ABI so that all tools agree on the processing of i386 ELF input files. The ABI was written at AT&T, the designers of the ELF format, back in 1990 when the ELF object file format was first designed. In order for tools to interoperate, they must all implement the same ABI. And they do. And that ABI says that R_386_PC32 is implemented by adding the offset from the address to the contents of the four byte field. There is no -4 in the formula. Note that 1990, when these rules were laid down, was before the Linus had even started working on the Linux kernel, and long before the Linux kernel supported ELF (Linux originally used the a.out object file format). So when you describe this as a Linux issue, you just sound ignorant of history. There are several systems besides Linux which implement the i386 ELF ABI, and .o files for those systems all interoperate correctly. > From what we see in this thread of posts, will they have nothing > credible that makes any sense -- other than some ABI doc says > it's OK? The enquiring public will want more substance than > that. OK, now you're just being a troll. > Why do Linux developers appear to want to keep correct .o files > (no -4 constants in there) out of the Linux environment? Is the > intent to keep quality software out of the Linux environment? > The larger computing world outside Linux/Sun, etc, also has > smart people producing useful object files -- in business, math, > science, you name it. But ld does not know how to link them! If those object files are ELF, then ld knows how to link them. If they are not ELF, then ld follows the rules appropriate for the object file format. > What message are you sending? That we know how to follow published standards and interoperate with other tools. > Is the message that objcopy writers now must also go in and > insert the -4's in .text sections when converting from .obj to > .o? All because ld can't find its own -4? [Free gift, cut and > paste any -4 in this post and put it in ld source code!] Is that the context of all this babble? You want to convert from .obj files, presumably in the Windows PE/COFF object file format, to object files in the ELF file format? If you want to do that conversion, then subtracting 4 from the contents of the section for PC relative relocs is the least of the issues you are going to have to deal with. Or, if you have a compiler which generates PE/COFF and you want to generate ELF, then just produce assembly code and feed it into an ELF assembler. The right thing will happen. 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
> The ABI states linkers cannot make -4 themselves, they have to > read it from a file? Heck, let's break it! Come on, be serious, the ABI gives the reloc's formula, which de facto prescribes assembler's and linker's behaviour. > I gave the current definition in my previous emails (the only > valid one is based on how microprocessors work) and yet ld fails > to link as stated above. [hint: microprocessors don't know what > we are saying or what ABI says; ld has no need whatsoever to get > -4 from input files; ld writers should know that.] There is no "valid one". The ABI is a convention, agreed upon by OS and compiler vendors. You don't like it, fine, but it's here to stay. > ABI again? Are you saying ABI doesn't know how to do rel > relocs? Again, the location must contain the offset to the > symbol from the current contents of the CPU eip register. Are > you saying ABI contradicts that? Yes, it's not the formula of R_386_PC32. Read the docs on the Sun site. -- Eric Botcazou ___ 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, Eric Botcazou, a life form in far off space, emitted: >neither you nor us can change it now Thanks for your further thoughts -- and even bigger story! The answer to that is pending; I hope we can edit ld to not require -4 in those rel reloc locations in input files. If so, the market will decide; is a corrected ld favored or not. >but you are 20 years late That's the marvel. Why was this not corrected 20 years ago? IMHO, it is never too late to upgrade quality -- and my proposed correction would have a practical effect: (1) you could announce to compiler makers they don't need the -4 gibberish in the object file outputs anymore (and they could optionally remove that from their compilers) and (2) a huge resource of countless object files in the outside world of computing would be linkable on Linux. And you wouldn't even have to edit your ABI document. With a fixed ld, compiler makers could put the -4's as before or 0 instead or even random numbers in those locations. Are you saying, "Linux cannot be improved?" Seems so. IMHO, not good public relations re promoting the OS. Only problem may be: while you are free to nurture a "We are defeated" attitude, there is, oops, nothing to prevent others from doing the obvious improvements -- especially when it comes to the OS's flag-ship linker. Take care, 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
Ian Lance Taylor wrote: Greetings, Ian, et all. You want to convert from .obj files, presumably in the Windows PE/COFF object file format, to object files in the ELF file format? If you want to do that conversion, then subtracting 4 from the contents of the section for PC relative relocs is the least of the issues you are going to have to deal with. Yes, that's the crux of it. As of late yesterday evening, we've been able to get this to work by linking the .obj (PE/COFF) files with ld emitting a PE executable, and then using objcopy to convert to the final ELF executable. Binutils 2.16.1 compiled with "--enable-targets=i386-pe" on a Linux box. What we had been doing prior was attempting to bypass the objcopy step and have ld perform the conversion from PE/COFF to ELF directly (with the appropriate switches, of course). It's at this point that the reloc issue popped up. So, is it safe to assume that attempting the conversion using ld alone will not produce a working ELF file in our case? That instead we should use objcopy to produce the final file? Thanks for your time and patience, Armando Rivera ___ 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, Eric Botcazou, a life form in far off space, emitted: >> If so, the market will decide; is a corrected ld favored or not. > >It's already decided: your proposed change would break the ABI, hence break >binary compatibility by definition. The ABI states linkers cannot make -4 themselves, they have to read it from a file? Heck, let's break it! What are we waiting for? I agree it's "already decided". Last time I looked, Linux and the others mentioned in this thread have well less than 10% market share both for number of computer users and number of computers. That percent can improve if upgrading quality was more important than some document written a generation ago. Fact: ld fails to rel reloc a .text section location if it does not contain -4. This fact == low quality. >> That's the marvel. Why was this not corrected 20 years ago? > >Because, if you really think about it, the current definition of R_386_PC32 is >the right one. I gave the current definition in my previous emails (the only valid one is based on how microprocessors work) and yet ld fails to link as stated above. [hint: microprocessors don't know what we are saying or what ABI says; ld has no need whatsoever to get -4 from input files; ld writers should know that.] >Again, it's not Linux, the i386 ABI predates Linux, Linux only conformed to >the existing ABI. ABI again? Are you saying ABI doesn't know how to do rel relocs? Again, the location must contain the offset to the symbol from the current contents of the CPU eip register. Are you saying ABI contradicts that? What exactly does ABI have to do with ld's failure to do rel reloc? Or are you saying, ld should fail? I say, why? Why not do it right? Success is not as bad as it might seem! ;) j ___ 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: >If you ignore the contents of the .o file, then how do you propose to >handle the assembler code >call foo + 16 >? Very good question. Thank you. Apparently the ABI assemblers would put foo's address in the rel reloc Symbol entry and (16-4) in the location to be relocated. I get it. [But would vote for such compilers to evaluate foo + 16 and use that value ;)] I was wrong to assume that all assemblers would put the actual destination (foo + 16) in the rel reloc symbol entry and that therefore, -4 was a constant. Thanks for clarifying that really the -4 value is not (always) a constant, at least given the behavior of assemblers you describe. hmmm. OK, for my object files, alternate entry points all have labels, so for those the -4 is a constant and an ld assuming that (which would not work for the call you cite above) would still be of interest in my project. Let's see. Thanks again and best wishes, j ___ 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
Airr <[EMAIL PROTECTED]> writes: > As of late yesterday evening, we've been able to get this to work by > linking the .obj (PE/COFF) files with ld emitting a PE executable, and > then using objcopy to convert to the final ELF executable. Yes, that is the usual technique. Of course it only works with a fully statically linked program. > So, is it safe to assume that attempting the conversion using ld alone > will not produce a working ELF file in our case? That instead we > should use objcopy to produce the final file? Yes. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
