This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld from cvs segfaults on i386pe and elf_i386 object mix
- To: Emmanuel Michon <emmanuel_michon at sdesigns dot com>
- Subject: Re: ld from cvs segfaults on i386pe and elf_i386 object mix
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Sun, 17 Sep 2000 22:29:38 -0700
- Cc: binutils at sourceware dot cygnus dot com
- References: <7w4s3jvtli.fsf@bonnie.realmagic.com>
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.