This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: msg00044/pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]