[PATCH] ARM: objdump produces incorrect disassembly on multiple inputs

Paul Carroll pcarroll@codesourcery.com
Tue Mar 8 23:22:00 GMT 2011


(I don't have write permission into the Binutils CVS, so someone else 
will be merging the final patch.)

The 'objdump' utility will not disassembly instructions correctly when 
it processes multiple ARM input files.
That is, if you compare the disassembly of each file individually 
against the output produced by processing all of the files at once, the 
output is different.
This is due to the ARM disassembler using a couple of global symbols to 
track symbol entries in a given input file.
The problem is that these global symbols are initialized once, but never 
reset back to their starting values when a new input file begins 
processing.  As a result, 'objdump's view of the symbols for the new 
input file is messed up.

This patch adds a call to initialize those 2 values at the start of 
processing each ARM input file.  This fix is ARM-specific.

The added test case is the stripped-down assembly output for a C file.  
It is necessary to have ARM instructions in the test case, since this is 
for testing the ARM disassembler.

Out of the 67 disassemblers in the binutils/opcodes directory, it is 
possible that there are issues with global symbols in the CRIS, 
Microblaze, S390, and tic4x (TI TMS320C[34]X) files.  I won't say there 
is a problem, but there could be one.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 8363.log
URL: <https://sourceware.org/pipermail/binutils/attachments/20110308/a9dc479c/attachment.log>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 8363_upstream.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20110308/a9dc479c/attachment.ksh>


More information about the Binutils mailing list