public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Andrew Cagney <cagney@redhat.com>
Cc: binutils@sources.redhat.com, cgen@sources.redhat.com
Subject: Re: include/dis-asm.h patch for cgen disassemblers
Date: Tue, 05 Feb 2002 11:29:00 -0000	[thread overview]
Message-ID: <20020205142931.D2399@redhat.com> (raw)
In-Reply-To: <3C601DB8.7080700@cygnus.com>; from ac131313@cygnus.com on Tue, Feb 05, 2002 at 01:00:24PM -0500

Hi -

cagney wrote:
> [...]
> 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.  [...]

That's good (except that persistent "isa" == "processor architecture"
confusion).  gdb still ranks bfd_arch above arch/mach pairs in some
contexts (e.g., gdbarch_register), but that looks changeable should
the desire arise.


> 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.

Dude, you're the one who brought up PS2, an irrelevant aside
to my original posting!  If gdb has no multiarch problem with
the current arrangement after all, then I have little residual
curiosity toward further discussions.  Please carry it off to
another thread.


> >> 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.  

(What, by saying "no such intent"?  I wish others "ducked questions"
with as much clarity.)

> Please clearly document this as a comment 
> that goes with the addition of this field.

Right.  Here is the version I'm about to commit.  Wording
quibbles are welcome, I guess as follow-up patches.


- FChE


Index: opcodes/ChangeLog
===================================================================
@@ -1,3 +1,7 @@
+2002-02-04  Frank Ch. Eigler  <fche@redhat.com>
+
+	* cgen-dis.in (print_insn_@arch@): Support disassemble_info.insn_sets.
+

Index: opcodes/cgen-dis.in
===================================================================
@@ -386,7 +386,7 @@
 #ifdef CGEN_COMPUTE_ISA
   isa = CGEN_COMPUTE_ISA (info);
 #else
-  isa = 0;
+  isa = info->insn_sets;
 #endif
 
   /* If we've switched cpu's, close the current table and open a new one.  */

Index: include/ChangeLog
===================================================================
+2002-02-04  Frank Ch. Eigler  <fche@redhat.com>
+
+	* dis-asm.h (disassemble_info): New field `insn_sets'.
+	(INIT_DISASSEMBLE_INFO): Clear it.
+

Index: include/dis-asm.h
===================================================================
@@ -73,6 +73,11 @@
   unsigned long mach;
   /* Endianness (for bi-endian cpus).  Mono-endian cpus can ignore this.  */
   enum bfd_endian endian;
+  /* An arch/mach-specific bitmask of selected instruction subsets, mainly
+     for processors with run-time-switchable instruction sets.  The default,
+     zero, means that there is no constraint.  CGEN-based opcodes ports
+     may use ISA_foo masks.  */
+  unsigned long insn_sets;
 
   /* Some targets need information about the current section to accurately
      display insns.  If this is NULL, the target disassembler function
@@ -271,6 +276,7 @@
   (INFO).flavour = bfd_target_unknown_flavour, \
   (INFO).arch = bfd_arch_unknown, \
   (INFO).mach = 0, \
+  (INFO).insn_sets = 0, \
   (INFO).endian = BFD_ENDIAN_UNKNOWN, \
   (INFO).octets_per_byte = 1, \
   INIT_DISASSEMBLE_INFO_NO_ARCH(INFO, STREAM, FPRINTF_FUNC)

  parent reply	other threads:[~2002-02-05 19:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-31  9:43 Frank Ch. Eigler
2002-01-31 12:22 ` Doug Evans
2002-01-31 13:21   ` Frank Ch. Eigler
2002-01-31 13:41     ` Doug Evans
2002-02-01 10:13       ` Frank Ch. Eigler
2002-02-01 10:22         ` Doug Evans
2002-02-01 10:28         ` Andrew Cagney
2002-02-01 10:36           ` Frank Ch. Eigler
2002-02-01 11:00             ` Andrew Cagney
2002-01-31 13:55     ` Andrew Cagney
2002-01-31 15:42       ` Frank Ch. Eigler
2002-01-31 16:03         ` Andrew Cagney
2002-01-31 16:57           ` Frank Ch. Eigler
2002-01-31 22:33             ` Andrew Cagney
     [not found]               ` <20020201092827.H6166@redhat.com>
     [not found]                 ` <3C5AE910.4090009@cygnus.com>
2002-02-01 11:56                   ` Frank Ch. Eigler
2002-02-01 12:02                     ` Andrew Cagney
2002-02-01 12:10                       ` Frank Ch. Eigler
2002-02-01 12:44                         ` Andrew Cagney
2002-02-01 12:56                           ` Andrew Cagney
2002-02-01 13:23                             ` Frank Ch. Eigler
     [not found]                               ` <3C5B1E19.8030405@cygnus.com>
2002-02-04  8:32                                 ` Frank Ch. Eigler
     [not found]                                   ` <3C601DB8.7080700@cygnus.com>
2002-02-05 11:29                                     ` Frank Ch. Eigler [this message]
2002-02-05 12:42                                       ` Doug Evans
     [not found]                     ` <3C5AF9D1.8070607@cygnus.com>
2002-02-01 12:39                       ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020205142931.D2399@redhat.com \
    --to=fche@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=cagney@redhat.com \
    --cc=cgen@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).