From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6933 invoked by alias); 7 Apr 2011 21:19:40 -0000 Received: (qmail 6925 invoked by uid 22791); 7 Apr 2011 21:19:39 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Apr 2011 21:19:35 +0000 Received: (qmail 13490 invoked from network); 7 Apr 2011 21:19:34 -0000 Received: from unknown (HELO wren.localnet) (paul@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Apr 2011 21:19:34 -0000 From: Paul Brook To: Paul Carroll Subject: Re: [PATCH] ARM: objdump produces incorrect disassembly on multiple inputs Date: Thu, 07 Apr 2011 21:19:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.38-2-amd64; KDE/4.4.5; x86_64; ; ) Cc: binutils@sourceware.org References: <4D76BA21.90708@codesourcery.com> <201104071427.24516.paul@codesourcery.com> <4D9DEF45.7010504@codesourcery.com> In-Reply-To: <4D9DEF45.7010504@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201104072219.32532.paul@codesourcery.com> Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00109.txt.bz2 > 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