Created attachment 5913 [details]
Patch to fix printf argument types

The change to using bfd_vma for offset computations, described in the fix for PR/12752 (CVS revision 1.146 of opcodes/arm-dis.c) causes the code to crash in configurations where the size of bfd_vma is different than the size of "int", because the code is now passing values of type bfd_vma to a "%d" format specifier.

For instance one such code snippet in print_insn_coprocessor looks like:

   1876                     bfd_vma offset = given & 0xff;
 ...
   1892                         if (offset)
   1893                           func (stream, ", #%d]%s",
   1894                                 offset,
   1895                                 WRITEBACK_BIT_SET ? "!" : "");

When this code passes "offset" as a 64-bit value, the printf function will interpret the low 32 bits as the %d argument, and the high 32 bits as the %s argument, but if the value is negative, the high bits will be equivalent to -1, which causes a segfault when used as character pointer.

For instance, I see this when I compile a version of the binutils that supports 32-bit x86, 64-bit AMD64, and ARM on a 32-bit x86/Linux host system; then "int" is 32 bits, but bfd_vma is 64 bits.

This is the sort of error that is supposed to be caught by GCC's format string checking. I see that that checking was enabled at the relevant place in 2005 (change 1.54 to include/dis-asm.h), but then it was disabled again (perhaps inadvertently; I don't see anything about it in the log message) in 2007 (change 1.67 to the same file).

I've attached a proof-of-concept patch which re-enables the warnings, and then adds casts on all the printf arguments in arm-dis.c that cause warnings under this configuration. I've verified that this fixes all the crashes I've seen in my configuration; objdump can now disassembly 50MB of random bytes without crashing. However I haven't investigated whether this problem occurs elsewhere, and I haven't checked whether this respects all the signs correctly, which was the issue in PR/12752. (For instance, could there be a configuration where bfd_vma is 32 bits but int is 64?)