View Bug Activity | Format For Printing
While linking some big c++ project (Latest LLVM CVS snapshot) using mingw32's binutils (2.16.91 20060119) I've got the folowing message: f:\research\mingw\bin\ld.exe: BFD 2.16.91 20060119 assertion fail ../../src/bfd/ cofflink.c:1926 It seems, that some other projects GeOs) have just same problems. I've reduced huge set of object files just to 2. The same assertion is triggered with the latest binutils snapshot both on mingw32 and cygwin platforms.
Created an attachment (id=1023) Set of object files on which link failed.
I've digged into the problem some more deep. The main problem is in file named LLVMSelectionDAG.o, which can be found in the prev. attach. This file was produced as 'ld -r' output from 9 object files. I've reduced the full set to just 2 files, running ld on which produces an assertion. So, if I do: ld -r -o LLVMSelectionDAG.o ScheduleDAGList.o ScheduleDAGRRList.o ld -o LLVMSelectionDAG.o I'm getting an assertion (even more, if I just do ld -r LLVMSelectionDAG.o -o LLVMSelectionDAG_1.o, I'm getting an exception). Seems, that something is broken in the partial link...
Created an attachment (id=1027) First object file
Created an attachment (id=1028) Second object file
Created an attachment (id=1047) Add check for missing aux entries
Hi Anton, I think that this is a case of a missing check in bfd_coff_link_input_bfd, so please could you try the uploaded patch and let me know if it works on a real world test, (ie your build environment). Cheers Nick
Unfortunately, patch doesn't work for me. Assertion is still triggered. I'm attaching the file from the first linker pass (ld -r -o LLVMSelectionDAG.o ScheduleDAGList.o ScheduleDAGRRList.o).
Created an attachment (id=1048) Output from the first pass This is the output from 'ld -r -o LLVMSelectionDAG.o ScheduleDAGList.o ScheduleDAGRRList.o'
Created an attachment (id=1049) The second pass output The output from the second pass: `ld -r -o LLVMSelectionDAG_1.o LLVMSelectionDAG.o`. Assertion is triggered, but file is actually not null.
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
Created an attachment (id=1114) Improved check for missing aux entries.
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.
Nick! Everything is building ok. So, this bug is definitely fixed by now. Thanks alot!
Hi Anton, Great - I have checked the revised patch in together with this ChangeLog entry. Cheers Nick bfd/ChangeLog 2006-07-05 Nick Clifton <nickc@redhat.com> PR ld/2659 * cofflink.c (_bfd_coff_link_input_bfd): Fix selection of aux entry when multiple definitions of a symbol are encountered.