Re: segfault here (bfd), segfault there, segfault segfault segfault

[H. J. Lu]

Sorry, I don't use windows. I suggest you use a combined gcc/binutils
tree if you aren't familiar with cross tools.


H.J.
On Tue, Apr 08, 2003 at 06:56:47PM +0200, Bernd Jendrissek wrote:
> Hello, world.  BTW this is with *"linux"* binutils 2.13.90.0.20
> 
> Oh boy, long story.  I've been trying to make a cross-compiler so I *never*
> have to develop under Windows again, and it seems to be a rocky road.
> 
> So now finally I can coax GCC into using the assembler *I* want (gross
> hack running sed over makefile).  But now there's assembler weirness.  And
> if there isn't, it's ar weirdness.
> 
> Now, I've installed the binutils libraries in /usr and ./configure'd with
> --enable-targets=all, --host=i686-pc-linux-gnu.  That seems okay - native
> tools work just fine.
> 
> But:
> 
> 1. binutils/configure --target=i386-pc-pe doesn't do what I expected.
>    [BTW patchlet at end for something only tangentially related]
> 
>    The resulting assembler outputs a.out: file(1) reports
>    "Linux/i386 impure executable (OMAGIC)" on the output.
> 
>    I thought i386-pc-pe would have caused the output to be coff of some
>    sort?  In fact, in gas/configure.in:
> 
>     # assign object format
>     case ${generic_target} in
>       ...
>       i386-*-pe)                        fmt=coff em=pe ;;
> 
> 2. binutils/configure --target=i386-winnt *does* generate coff output.
>    Strange.  I don't see *any* ix86-specific mention of winnt anywhere in
>    gas.  Anyone care to explain?  How does *this* as know to output coff?
> 
> 3. Using PATH=/usr/cross/i386-pc-pe/bin:$PATH but with xgcc using
>    i386-winnt-as, I'm trying to build mingw-runtime so that I can get
>    further with GCC.  But now dlltool bombs (segfault).
> 
> (gdb) bt
> #0  0x40086626 in bfd_check_format_matches (abfd=0x8073bf0, 
> format=1077479232, matching=0x0) at format.c:309
> #1  0x400863fe in bfd_check_format (abfd=0x4038f7a4, format=1077475236) at 
> format.c:93
> #2  0x4007f6e5 in _bfd_write_archive_contents (arch=0x806f6d0) at 
> archive.c:1721
> #3  0x40087d2b in bfd_close (abfd=0x806f6d0) at opncls.c:425
> #4  0x0804db0c in gen_lib_file () at dlltool.c:2903
> #5  0x0804ea6f in main (ac=9, av=0x0) at dlltool.c:3480
> 
> (gdb) list
> 304           while ((right_targ = *assoc++) != NULL)
> 305             {
> 306               int i = match_count;
> 307
> 308               while (--i >= 0)
> 309                 if (matching_vector[i] == right_targ)
> 310                   break;
> 311
> 312               if (i >= 0)
> 313                 {
> 
> (gdb) print matching_vector 
> $6 = (const struct bfd_target **) 0x0
> 
> Huh?  NULL?
> 
> I can reproduce this no problem: it happens every time.  Need more info?
> I'll give it gladly.
> 
> 
> 
> Patchlet: recognise i[3-6]86-pc-pe* to which i[3-6]86-pe is canonicalized.
> 
> --- binutils-2.13.90.0.18/binutils/configure.in       Mon Dec 16 22:22:52 2002
> +++ binutils-2.13.90.0.18/binutils/configure.in       Wed Apr  2 16:12:48 2003
> @@ -260,7 +260,7 @@
>         OBJDUMP_DEFS="-DDISASSEMBLER_NEEDS_RELOCS"
>         ;;
>  changequote(,)dnl
> -     i[3-6]86-pe* | i[3-6]86-*-cygwin* | i[3-6]86-*-mingw32** | 
> i[3-6]86-*-netbsdpe*)
> +     i[3-6]86-*-pe* | i[3-6]86-*-cygwin* | i[3-6]86-*-mingw32** | 
> i[3-6]86-*-netbsdpe*)
>  changequote([,])dnl
>         BUILD_DLLTOOL='$(DLLTOOL_PROG)$(EXEEXT)'
>         DLLTOOL_DEFS="$DLLTOOL_DEFS -DDLLTOOL_I386"