Re: Add new field to disassemble_info:

[Nick Clifton <nickc at redhat dot com>]

Hi Doug,

> There are users of the disassembler outside of binutils/gdb.
> While that needn't be of much concern, I'm hoping it is of some
> concern.
>
> This patch exports another function from libopcodes that apps
> are expected to call before using the disassembler.
> Now they have to call _two_ functions.
> [Well they don't _have_ to, but with such generic names they're
> going to feel compelled to.]
> Can a cover function be created for
> init_disassemble_info + disassemble_init_for_target?

Actually I did consider this exact problem.  I could have changed just
init_disassemble_info() so that it took a "bfd *" parameter.  This
would have immediately broken all of the non-binutils apps that use
this function, which I felt was a bad thing.  Instead I opted for
adding another, optional, interface function.  If apps do not call it,
then nothing will change[1].  Thus this approach provided the least
disruption to already existing users of the libopcodes library.


> Application specific init'n would still be left to the app of course.
> e.g.
>   disasm_info.symbol_at_address_func = objdump_symbol_at_address;
>
> OTOH, symbol_is_valid is only called from the app thus far (in this case
> objdump) not libopcodes, thus does it need to live in disassemble_info at all?
> libopcodes could certainly still export it for other apps to use,
> and if it is exported, ok, perhaps y'all will want to export it via
> disassemble_info, but it is odd for the app to stuff something
> in disassemble_info that only the app uses (ergo the issue
> of why put it there at all?).

Hmm, yes I guess that the function could exist outside of the
disassemble_info structure, but I felt that that structure was the
natural place for it.  (I also feel that the disassembler() function
ought to be removed and the function pointer it provides be moved into
the disassemble_info structure.  But that is a side issue).

My reasoning was that since this new function was intended basically
for disassemblers - ie to allow them to skip symbols which should not
be displayed - that putting it in disassemble_info was the logical
thing to do.

Cheers
        Nick

[1] Well nothing at the moment.  In the future this
disassemble_init_for_target() function may do more than just
initialise a workaround for the ARM port.  In fact even calling this
function will not help unless the app is also modified to make use of
the new symbol_is_valid function.  Something that I suspect will not
happen until/if users complain about mapping symbols appears in their
output.