ld from cvs segfaults on i386pe and elf_i386 object mix

[H . J . Lu]

On Thu, Sep 14, 2000 at 06:14:33PM +0200, Emmanuel Michon wrote:
> Hi,
> 
> so far I have made small elf executable test programs mixing 
> microsoft VC6 COFF object files and linux object files with success, 
> testing only on int, float, very simple malloc/free functions, etc.
> It was ok with GNU ld 2.10.90 (binutils-2.10.0.12-1)
> 
> I have now to link a much bigger project; object have been created
> by Intel assembly compiler. No C++ used, nor do those objects call
> 90% of the Windows API. Everything is closed and there are very
> few entry points. (maybe setjmp/longjmp will cause some trouble but not
> during the linking step I imagine).
> 
> ld 2.10.90 segfaults.
> I upgraded to sep 13th cvs snapshot (compiled with --enable-targets=i386-pe)
> and ld is now GNU ld version 2.10.91 (with BFD 000913)
> 
> My command line is (usually I would use gcc but since I'm not sure
> which ld gcc calls --- I use directly:)
> 
> ld ctrl.o toto.o llarith.o os.o fromwindows.objmod /usr/lib/crt1.o \
>  /usr/lib/crti.o -lc -o toto
> 
> and the program segfaults on:
> Program received signal SIGSEGV, Segmentation fault.
> coff_i386_reloc (abfd=0x80e4fe0, reloc_entry=0x80e6c68, symbol=0x81bed98, 
>     data=0x8116eb8, input_section=0x80ea73c, output_bfd=0x0, 
>     error_message=0xbffff85c) at coff-i386.c:132
> (gdb) 
> 
> the corresponding code excerpt is:
> 
> #ifdef COFF_WITH_PE
>   /* FIXME: How should this case be handled?  */
>   if (reloc_entry->howto->type == R_IMAGEBASE)
> --here-->    diff -= pe_data (output_bfd)->pe_opthdr.ImageBase;
> #endif

I am not sure if it can happen in a relocatable file.

> 
> and output_bfd is 0x0.
> 
> I first had to run objcopy (same cvs version) to change object
> names from
>          U __imp__CTRL_SomeFunction@20
>  to
>          U CTRL_SomeFunction
> 
> and then implement these functions in ctrl.c (you cannot put a ``@''
> in a function name in C), that's why fromwindows.obj is changed to
> fromwindows.objmod.
> 
> 1. Is the fact of changing object names a risky process in itself?
> 
> There are about 200 item in ``nm fromwindows.obj''. I created replacements
> for _malloc, _free, and other calls tagged ``U'' so that all the
> object codes can be found. ld crashes right after that step.

# "objcopy --remove-leading-char foo.obj

should be ok.

> 
> 2. Is this bug report useful, or what should I add to allow further
> investigation?

No. I need to a testcase. If you send me a testcase, I will look into
it.

> 
> 3. What's the difference between i386-pe and i386-pei?
> 

I think i386-pei is for executables and i386-pe is for relocatables.


H.J.