This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] ARM: objdump produces incorrect disassembly on multiple inputs
- From: Paul Brook <paul at codesourcery dot com>
- To: Paul Carroll <pcarroll at codesourcery dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 7 Apr 2011 22:19:31 +0100
- Subject: Re: [PATCH] ARM: objdump produces incorrect disassembly on multiple inputs
- References: <4D76BA21.90708@codesourcery.com> <201104071427.24516.paul@codesourcery.com> <4D9DEF45.7010504@codesourcery.com>
> On 4/7/2011 7:27 AM, Paul Brook wrote:
> >> The 'objdump' utility will not disassembly instructions correctly when
> >> it processes multiple ARM input files.
> >>
> >> This is due to the ARM disassembler using a couple of global symbols to
> >> track symbol entries in a given input file.
> >>
> >>
> >> This patch adds a call to initialize those 2 values at the start of
> >> processing each ARM input file. This fix is ARM-specific.
> >
> > Wouldn't it be better to use info->private_data ?
>
> Possibly.
> As a test, I implemented the fix using 'info->private_data'.
> That moves the 3 global variables, used by the ARM disassembler, into
> this private structure.
> But, the initialization call before starting disassembly is still
> necessary since those variables need to be reset back to their initial
> values.
Rubbish.
The disassemble() function is documented to return an appropriate disassembly
callback. Having it also reset unspecified state is at somewhat surprising.
Putting the state in private_data will do exactly what you want. If fact it's
more reliable as it's linked to the actual disassembler state (of which there
may be many), rather than when the user happens to request the callback
function. Note how a new instance of struct disassemble_info is created for
each object.
Paul