From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10931 invoked by alias); 28 Jan 2010 18:27:49 -0000 Received: (qmail 10914 invoked by uid 22791); 28 Jan 2010 18:27:48 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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, 28 Jan 2010 18:27:43 +0000 Received: (qmail 12968 invoked from network); 28 Jan 2010 18:27:42 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jan 2010 18:27:42 -0000 Date: Thu, 28 Jan 2010 18:27:00 -0000 From: Daniel Jacobowitz To: Nick Clifton Cc: Doug Evans , dgutson@codesourcery.com, gdb@sourceware.org, binutils@sourceware.org Subject: Re: gdb segv in arm disassembler Message-ID: <20100128182736.GA15693@caradoc.them.org> Mail-Followup-To: Nick Clifton , Doug Evans , dgutson@codesourcery.com, gdb@sourceware.org, binutils@sourceware.org References: <20100126022255.344B284414@ruffy.mtv.corp.google.com> <20100126023652.GA14474@caradoc.them.org> <4B618767.30408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B618767.30408@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00211.txt.bz2 On Thu, Jan 28, 2010 at 12:47:35PM +0000, Nick Clifton wrote: > Hi Daniel, > > >>On Mon, Jan 25, 2010 at 06:22:55PM -0800, Doug Evans wrote: > >>I'm getting a segv in the arm disassembler when invoked from gdb, > > >Yes. Sorry - I have a patch for this but I have got stuck travelling > >instead of finishing the patch series it's part of. > > > >I think this is the appropriate fix: > >- int is_data = (bfd_asymbol_flavour (*info->symtab) > >- == bfd_target_elf_flavour) ? TRUE : FALSE; > >+ int is_data = FALSE; > > Unfortunately this introduces a new failure into the GAS testsuite. > > How about this version instead ? I looked at this a bit. It's more complicated than I expected. I thought our two patches would do the same thing. It turns out that the difference is caused by info->symtab != NULL but info->symtab_size == 0. In this case the test case has no symbols, but the caller does claim to have provided the symbol table. This gets the right result for the gas test, but can lead to a crash depending on what happens to be in info->symtab (I discovered that with a stripped binary). There are a couple of cases. * No symbols. For instance, a stripped binary. IMO the most useful thing to do is to default to code; objdump will already not call the disassembler for sections without SEC_CODE. Unfortunately, we can not distinguish that situation from the current gas test case. * Symbols, but no mapping symbols. Produced by an old assembler. Again, I think defaulting to code is reasonable; we expect that most of a code section / symbol will be code. Adding a label or function symbol to the existing gas testsuite will simulate this. The existing code does not behave as intended when there is a function symbol, but no mapping symbol; the function symbol overrides. * Mapping symbols. If there are any mapping symbols in the section (or object), then we should obey them. This is the only case in which we can detect leading data with the default-$d omitted mapping symbol. The best compromise I've thought of is: * If there are any mapping symbols in the symbol table, honor them. Ignore other symbols. * If there are no mapping symbols, default to code using the existing legacy search. This will mishandle recent files iff they have a code section containing only literal pools. Outside of test cases, this is unlikely. I'm working on this (it's taking me a while...). -- Daniel Jacobowitz CodeSourcery