Several days ago, I tried executing objdump -x on a function archive, whose format is an extended m68k-coff, used by the TIGCC development environment. I needed to locate a label in the file. I had compiled the 2.16 release binutils for that target under Cygwin, probably with GCC 3.4.4. The program crashes (segfault - STATUS_ACCESS_VIOLATION), and the stack trace has only one line: Stack trace: Frame Function Args 66 [main] m68k-coff-objdump 3872 handle_exceptions: Error while dumping state (probably corrupted stack) This is reproducable. Although one cannot expect the vanilla objdump to handle the extended file fully correctly, it should not crash that way... I checked that the executables resulting from compiling the 20050813 snapshot (which doesn't compile entirely due to an implicit function definition in readelf, BTW) still crash. This time, I tried compiling on both Cygwin (GCC 3.4.4, exception caught by own handler) and MSYS (GCC 3.4.2, exception caught by Windows handler, error code 0xC0000005). I'm running Windows XP SP2. When I'm rebooting my computer under Linux (SimplyMEPIS), I can try under Linux too. At http://tict.ticalc.org/transfer/crash_m68k_coff_objdump.7z you will find the offending file, scripts to reproduce the crash, stack dumps and stripped executables.
Under Linux (MEPIS using the GCC 4.0.0 from Debian unstable), the BFD reports invalid relocation data (which is natural, given that the format is extended) and exits properly, instead of doing a segfault.
Does that still happen with the latest version?
I had completely forgotten about this bug report posted several days after I first installed Linux on my computer :) In the meantime: * I switched to Linux near-full-time in 2006, for both home and work usage. This computer cannot easily run VirtualBox VMs anymore. The simplest way to perform native Windows builds and tests is now to use another computer from work, which could take a bit of time, possibly not before the end of next week. * I co-created the GCC4TI development environment out of the aforementioned TIGCC. Among the various bugfixes and improvements we made, the following ones are relevant to this discussion: 1) the custom build scripts do not delete ar, objcopy, objdump, size and strip any longer (better having incomplete tools for expert usage than none at all !); 2) GCC4TI's gcc and binutils use a program prefix, so that they don't collide with system gcc and binutils; 3) the local patch to binutils was expanded one hack-ish hunk, so as to mask out the offending flag and make the binutils more usable, though not necessarily in the way upstream would do it. See the first hunk of https://github.com/debrouxl/gcc4ti/blob/4a0341f02f9d95a205b8601ca7be39cd876c5b1c/trunk/tigcc/gcc/gas-2.16-tigcc-patch.diff . * binutils, like many other programs, went through rounds of fuzzing and subsequent bugfixing, while GCC's Windows support further improved. The problem might therefore well be gone from modern binutils versions, only testing will tell - but I can't do that today :)
Alright, I've now been able to spend some time setting up 32-bit Cygwin on a Windows computer (Win 7 x64 VM), and building several binutils versions :) The results are as follows: * for sanity checking: binutils 2.16.1a, successfully built by Cygwin GCC 5.2.0, segfaults on the file I posted 10 years ago if its prefix is /tmp/m68k-coff-binutils or /tmp/m68k-coff-binu2161, but reports invalid relocation data and exits with proper 1 value if the prefix is /home/<7-letter username>/prefix/m68k-coff-binutils2161. * binutils 2.25.1 (need to use -i for make) doesn't barf, when installed at /tmp/m68k-coff-binutils, /tmp/m68k-coff-binu2251 or /home/<7-letter username>/prefix/m68k-coff-binutils2251: they print that the file contains invalid relocation data, as binutils 2.16 did under Linux (with unknown prefix) 10 years ago. * binutils 2.21.1, 2.22, 2.23.2 don't build under that setup, even with make -i; * binutils 2.24 didn't barf at /home/<7-letter username>/prefix/m68k-coff-binutils224, I haven't tested /tmp/m68k-coff-binutils or /tmp/m68k-coff-binut224. I suppose I'll mark this bug resolved, all the more the m68k-coff (m68k-unknown-coff) target was made unsupported for gas years ago :)