Re: gdb segv in arm disassembler

[Daniel Jacobowitz <dan at codesourcery dot com>]

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