Re: include/dis-asm.h patch for cgen disassemblers

["Frank Ch. Eigler" <fche@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

Hi - 

cagney wrote:
> [...]
> > Referring to BFD misses the point!  The BFD library barely cares about
> > individual instructions or instruction sets.  [...]
> 
> BFD sets the scene for its clients - LD, GDB, ...  It defines an 
> architecture / machine relationship (abet slighly broken in parts)
> and applications use that.

Yes.

> My understanding of CGEN/SID is that they turned their back on BFD and 
> defined a new set of architecture / machine relationships.

Your understanding is incorrect.

> GDB certainly doesn't want to go down that path.

No one is asking.  If the "isas" field extension goes in,
and you prefer future gdb ports to continue using only the
informal disassemble_options string, that's your prerogative.


> [...]
> > I need a way of identifying the list of sets of instructions ("instruction
> > sets", get it?) valid in some current context (processor state, mode,
> > environment, whatever).  I think the term "isas" is better than "mode",
> > which is in turn better than "environment", to refer to this.  Are we
> > down to a mere choice-of-terminology issue?
> 
> Where is the fire?
> See above, there is, I think a more fundamental problem here.  The 
> definition of bfd-architecture and machine are being quietly changed.

No.  A concept that already broadly exists outside bfd is being
formally identified in the opcodes disassemble_info structure.
Nothing in bfd is changing, and given this thread, even this lack
of change is happening exceedingly un-quietly.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]