This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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


> For the benefit of mystified binutils/cgen readers, I think the
> reason cagney is so interested in the first column, is a
> long-standing quixotic battle against gdb-ically incorrect
> bfd modelling.  Apparently, roughly speaking, gdb's multiarch
> system likes to map from bfd_arch numbers (and not bfd_arch/bfd_mach
> pairs) to a vector of target-specific functions.  Using multiple
> bfd_mach codes for dissimilar family members throws a monkey-wrench
> into this scheme, for the simpleminded "each bfd_mach is a strict
> subtype of the bfd_arch" view of the world.
> 
> Whether such a simple/rigid subtyping relationship is in fact
> reasonable to insist on is a legitimate question, and I invite
> Andrew to nudge the great ship bfd toward whatever heading he prefers.


GDB at the moment uses an arch/mach pair to select an architecture.  It 
assumes that, just like in FSF BFD, bfd_architecture indicates a related 
family of instruction set architectures.  I've certainly found nothing 
in the FSF BFD sources to suggest that this is a mistaken assumption. 
Still, that doesn't mean that the mechanism is set in stone.  If 
anything the oposite, it is known, for instance, that the current 
mechanism doesn't handle OS variants and hence will need to be changed.

Here I consider GDB to simply be reflecting the status quo.  I don't 
think what you've described of the PS2 is consistent with this, I don't 
see it as my problem to nudge the great bfd ship forward.  Rather it is 
your problem to change the the direction of the entire binutils+gdb 
toolchain.


>> Can I assume, for instance, that INSTRUCTION_SUBSETS, wouldn't be used 
>> to select orthogonal ISAs that run on different compute engines?
> 
> 
> I have no such intent -- as I've had to say too many times now, I need
> the field to further refine the set of instructions identified by some
> given bfd_arch/bfd_mach pair.


No, you ducked the question.  Please clearly document this as a comment 
that goes with the addition of this field.

Andrew


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