* include/dis-asm.h patch for cgen disassemblers @ 2002-01-31 9:43 Frank Ch. Eigler 2002-01-31 12:22 ` Doug Evans 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-01-31 9:43 UTC (permalink / raw) To: binutils, cgen Hi - I have a scenario where I need a (cgen-based) disassembler to select a given list of instruction sets of a multi-ISA processor, based on a run-time condition. This is something like the arm/thumb or mips/mips16 split (odd PC), except that there is no trivial way to encode the run-time condition. The raw arch/mach parameters are fixed, and there is no object file for the disassembler to look into to guess from (based on PC). So, I can either expand the disassemble_info structure, or overload an existing field. I went with the latter for this patch. It adds a new .flags option, which tells cgen-based disassemblers to pull out the ISA bitmask out of the .mach field. This is no great loss, since the mach field is not normally used for such purposes in cgen ports, and can be overridden on a per-target basis for exceptions. Any comments / objections? - FChE Index: opcodes/ChangeLog =================================================================== @@ -1,3 +1,8 @@ +2002-01-25 Frank Ch. Eigler <fche@redhat.com> + + * cgen-dis.in (print_insn_@arch@): Support HAVE_CGEN_ISA_NOT_MACH + disassemble_info flag. + Index: opcodes/cgen-dis.in =================================================================== @@ -380,13 +380,19 @@ #ifdef CGEN_COMPUTE_MACH mach = CGEN_COMPUTE_MACH (info); #else - mach = info->mach; + if (info->flags & HAVE_CGEN_ISA_NOT_MACH) + mach = 0; + else + mach = info->mach; #endif #ifdef CGEN_COMPUTE_ISA isa = CGEN_COMPUTE_ISA (info); #else - isa = 0; + if (info->flags & HAVE_CGEN_ISA_NOT_MACH) + isa = info->mach; + else + isa = 0; #endif /* If we've switched cpu's, close the current table and open a new one. */ Index: include/ChangeLog =================================================================== @@ -1,3 +1,8 @@ +2002-01-25 Frank Ch. Eigler <fche@redhat.com> + + * dis-asm.h (HAVE_CGEN_ISA_NOT_MACH): New possible bitmask for + disassemble_info flags. + Index: include/dis-asm.h =================================================================== @@ -93,6 +93,7 @@ The bottom 16 bits are for the internal use of the disassembler. */ unsigned long flags; #define INSN_HAS_RELOC 0x80000000 +#define HAVE_CGEN_ISA_NOT_MACH 0x40000000 /* .mach is really a cgen isa bitmask. */ PTR private_data; /* Function used to get bytes to disassemble. MEMADDR is the ^ permalink raw reply [flat|nested] 24+ messages in thread
* include/dis-asm.h patch for cgen disassemblers 2002-01-31 9:43 include/dis-asm.h patch for cgen disassemblers Frank Ch. Eigler @ 2002-01-31 12:22 ` Doug Evans 2002-01-31 13:21 ` Frank Ch. Eigler 0 siblings, 1 reply; 24+ messages in thread From: Doug Evans @ 2002-01-31 12:22 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: binutils, cgen Frank Ch. Eigler writes: > I have a scenario where I need a (cgen-based) disassembler to select > a given list of instruction sets of a multi-ISA processor, based on > a run-time condition. This is something like the arm/thumb or > mips/mips16 split (odd PC), except that there is no trivial way to > encode the run-time condition. The raw arch/mach parameters are > fixed, and there is no object file for the disassembler to look > into to guess from (based on PC). So, I can either expand the > disassemble_info structure, or overload an existing field. > > I went with the latter for this patch. It adds a new .flags option, > which tells cgen-based disassemblers to pull out the ISA bitmask out > of the .mach field. This is no great loss, since the mach field is > not normally used for such purposes in cgen ports, and can be > overridden on a per-target basis for exceptions. > > Any comments / objections? Blech. Down the road: "Oh. This is a cgen port. Maybe `mach' means `mach', maybe it doesn't. :-(" methinks `mach' is too well established to overload. I'd go with the first possibility, and not overload `mach'. Instead of arch/mach in disassemble_info, have arch/mach/mumble where mumble is up to each port. [by "mumble" I mean "you pick the name", not "each port gets to pick the name" ...] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 12:22 ` Doug Evans @ 2002-01-31 13:21 ` Frank Ch. Eigler 2002-01-31 13:41 ` Doug Evans 2002-01-31 13:55 ` Andrew Cagney 0 siblings, 2 replies; 24+ messages in thread From: Frank Ch. Eigler @ 2002-01-31 13:21 UTC (permalink / raw) To: Doug Evans; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 1998 bytes --] Hi - dje wrote: > [...] > Blech. > [...] > I'd go with the first possibility, and not overload `mach'. > Instead of arch/mach in disassemble_info, have arch/mach/mumble > [...] OK. How about this? It is simpler, but it furthers disassemble_info field sprawl. - FChE Index: opcodes/ChangeLog =================================================================== @@ -1,3 +1,7 @@ +2002-01-31 Frank Ch. Eigler <fche@redhat.com> + + * cgen-dis.in (print_insn_@arch@): Support disassemble_info.isas. + Index: opcodes/cgen-dis.in =================================================================== @@ -386,7 +386,7 @@ print_insn_@arch@ (pc, info) #ifdef CGEN_COMPUTE_ISA isa = CGEN_COMPUTE_ISA (info); #else - isa = 0; + isa = info->isas; #endif /* If we've switched cpu's, close the current table and open a new one. */ Index: include/ChangeLog =================================================================== @@ -1,3 +1,8 @@ +2002-01-31 Frank Ch. Eigler <fche@redhat.com> + + * dis-asm.h (isas): New field in disassemble_info. + (INIT_DISASSEMBLE_INFO): Clear it. + Index: include/dis-asm.h =================================================================== @@ -73,6 +73,8 @@ typedef struct disassemble_info { unsigned long mach; /* Endianness (for bi-endian cpus). Mono-endian cpus can ignore this. */ enum bfd_endian endian; + /* A target-specific indication of applicable instruction sets. */ + unsigned long isas; /* Some targets need information about the current section to accurately display insns. If this is NULL, the target disassembler function @@ -271,6 +273,7 @@ extern int generic_symbol_at_address (INFO).flavour = bfd_target_unknown_flavour, \ (INFO).arch = bfd_arch_unknown, \ (INFO).mach = 0, \ + (INFO).isas = 0, \ (INFO).endian = BFD_ENDIAN_UNKNOWN, \ (INFO).octets_per_byte = 1, \ INIT_DISASSEMBLE_INFO_NO_ARCH(INFO, STREAM, FPRINTF_FUNC) [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 13:21 ` Frank Ch. Eigler @ 2002-01-31 13:41 ` Doug Evans 2002-02-01 10:13 ` Frank Ch. Eigler 2002-01-31 13:55 ` Andrew Cagney 1 sibling, 1 reply; 24+ messages in thread From: Doug Evans @ 2002-01-31 13:41 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: binutils, cgen Frank Ch. Eigler writes: > > I'd go with the first possibility, and not overload `mach'. > > Instead of arch/mach in disassemble_info, have arch/mach/mumble > > OK. How about this? I recognize wanting to have a clear name ("isas"), but methinks for the task at hand this just repeats the problem. The goal is (or was) to add a target specific annotation to control disassembly. Naming it "isas" kinda confines its usage unless one does further hackyness as in your original patch. [The name "isas" just seems too confining, but maybe not. I can't think of a better anme, though methinks one is out there. I certainly wouldn't spend much time on it.] At any rate, IMO this patch is better than the originally proposed patch. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 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 0 siblings, 2 replies; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 10:13 UTC (permalink / raw) To: Doug Evans; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 761 bytes --] Hi - dje wrote: > [...] > I recognize wanting to have a clear name ("isas"), but methinks for > the task at hand this just repeats the problem. The goal is (or was) to add > a target specific annotation to control disassembly. > [...] A general hook is the "char* disassembler_options" field, which is used as a catch-all. Where this field is used (arm, i386, ppc), it's almost exclusively to encode the ISA selection. I'd prefer to formalize the isa switch than continue to deformalize to a string option, especially as isa switching is a correctness issue. (Some of these disassembleres use the string also for rendering preferences.) > At any rate, IMO this patch is better than the originally proposed patch. OK. Anyone with objections? - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 10:13 ` Frank Ch. Eigler @ 2002-02-01 10:22 ` Doug Evans 2002-02-01 10:28 ` Andrew Cagney 1 sibling, 0 replies; 24+ messages in thread From: Doug Evans @ 2002-02-01 10:22 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: binutils, cgen Frank Ch. Eigler writes: > A general hook is the "char* disassembler_options" field, which is used > as a catch-all. Where this field is used (arm, i386, ppc), it's almost > exclusively to encode the ISA selection. This is used to pass in disassembler options from the user too though, right? If so, it's definately not what you want here. > I'd prefer to formalize the > isa switch than continue to deformalize to a string option, especially > as isa switching is a correctness issue. (Some of these disassembleres > use the string also for rendering preferences.) As I said, I can't think of a better name. No more objections here. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 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 1 sibling, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-02-01 10:28 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Doug Evans, binutils, cgen > Hi - > > > dje wrote: > >> [...] >> I recognize wanting to have a clear name ("isas"), but methinks for >> the task at hand this just repeats the problem. The goal is (or was) to add >> a target specific annotation to control disassembly. >> [...] > > > A general hook is the "char* disassembler_options" field, which is used > as a catch-all. Where this field is used (arm, i386, ppc), it's almost > exclusively to encode the ISA selection. I'd prefer to formalize the > isa switch than continue to deformalize to a string option, especially > as isa switching is a correctness issue. (Some of these disassembleres > use the string also for rendering preferences.) I would put it the other way round. Users use disassembler_options to principaly do select assembly syntax and the like. They override the default mode. >> At any rate, IMO this patch is better than the originally proposed patch. > > > OK. Anyone with objections? You mean like my constant questioning? Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 10:28 ` Andrew Cagney @ 2002-02-01 10:36 ` Frank Ch. Eigler 2002-02-01 11:00 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 10:36 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 662 bytes --] Hi - cagney wrote: > [...] > I would put it the other way round. Users use disassembler_options to > principaly do select assembly syntax and the like. They override the > default mode. Have you looked at the opcodes/ code? Most of the disassembler_option substrings enable and disable groups of opcodes (instruction sets) for decoding. That's deeper than assembly syntax. How an end-user performs this picking, and why she should have to pick manually at all, are separate issues. > > OK. Anyone with objections? > You mean like my constant questioning? Nah, those are more like cries for general elucidation. :-) - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 10:36 ` Frank Ch. Eigler @ 2002-02-01 11:00 ` Andrew Cagney 0 siblings, 0 replies; 24+ messages in thread From: Andrew Cagney @ 2002-02-01 11:00 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Andrew Cagney, binutils, cgen > Hi - > > cagney wrote: > > >> [...] >> I would put it the other way round. Users use disassembler_options to >> principaly do select assembly syntax and the like. They override the >> default mode. > > > Have you looked at the opcodes/ code? Most of the disassembler_option > substrings enable and disable groups of opcodes (instruction sets) for > decoding. That's deeper than assembly syntax. How an end-user performs > this picking, and why she should have to pick manually at all, are > separate issues. GDB is only going to be changed to support a ``set disassembler-options <list>'' command. To know GDB needs this change suggests someone read the source code. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 13:21 ` Frank Ch. Eigler 2002-01-31 13:41 ` Doug Evans @ 2002-01-31 13:55 ` Andrew Cagney 2002-01-31 15:42 ` Frank Ch. Eigler 1 sibling, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-01-31 13:55 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Doug Evans, binutils, cgen > Index: opcodes/ChangeLog > =================================================================== > @@ -1,3 +1,7 @@ > +2002-01-31 Frank Ch. Eigler <fche@redhat.com> > + > + * cgen-dis.in (print_insn_@arch@): Support disassemble_info.isas. > + What is the difference between an architecture, isa and machine? Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 13:55 ` Andrew Cagney @ 2002-01-31 15:42 ` Frank Ch. Eigler 2002-01-31 16:03 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-01-31 15:42 UTC (permalink / raw) To: cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 337 bytes --] Hi - cagney wrote: > What is the difference between an architecture, isa and machine? architecture ~= bfd architecture ~= family of processors machine ~= bfd machine ~= implementation of an architecture isa ~= instruction set ~= group of machine instructions decodable; can be a function of cpu state - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 15:42 ` Frank Ch. Eigler @ 2002-01-31 16:03 ` Andrew Cagney 2002-01-31 16:57 ` Frank Ch. Eigler 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-01-31 16:03 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: cagney, binutils, cgen > Hi - > > cagney wrote: > >> What is the difference between an architecture, isa and machine? > > > architecture ~= bfd architecture ~= family of processors Hmm, archures.c contains: This enum gives the object file's CPU architecture, in a global sense---i.e., what processor family does it belong to? Another field indicates which processor within the family is in use. The machine gives a number which distinguishes different versions of the architecture, containing, for example, 2 and 3 for Intel i960 KA and i960 KB, and 68020 and 68030 for Motorola 68020 and 68030. > machine ~= bfd machine ~= implementation of an architecture > isa ~= instruction set ~= group of machine instructions decodable; > can be a function of cpu state Er, ISA == Instruction Set Architecture which to me is bfd_architecture. I think, here you're looking for something else. For instance, Arm has thumb and MIPS has MIPS16. They are modes but sill part of a single ISA. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 16:03 ` Andrew Cagney @ 2002-01-31 16:57 ` Frank Ch. Eigler 2002-01-31 22:33 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-01-31 16:57 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 1040 bytes --] Hi - cagney wrote: > [...] > > isa ~= instruction set ~= group of machine instructions decodable; > > can be a function of cpu state > > Er, ISA == Instruction Set Architecture which to me is bfd_architecture. > I think, here you're looking for something else. > > For instance, Arm has thumb and MIPS has MIPS16. They are modes but > sill part of a single ISA. Yes, but not in an interesting sense. It's much like the IA32 engine inside IA64: they surely aren't the same ISA, despite being executable by the same hardware, and operating partly on the same registers. Sure, arm & thumb are closer together, and they may be documented in the same publication, but that's not substantial to this question. The conceptual issue is whether or not the choice of instructions available is a function of processor state. For the purposes of tools like disassemblers and simulators, and really even assemblers and compilers, each such group forms a separate instruction set. - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-01-31 16:57 ` Frank Ch. Eigler @ 2002-01-31 22:33 ` Andrew Cagney [not found] ` <20020201092827.H6166@redhat.com> 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-01-31 22:33 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Andrew Cagney, binutils, cgen > Hi - > > cagney wrote: > >> [...] > >> > isa ~= instruction set ~= group of machine instructions decodable; >> > can be a function of cpu state > >> >> Er, ISA == Instruction Set Architecture which to me is bfd_architecture. >> I think, here you're looking for something else. >> >> For instance, Arm has thumb and MIPS has MIPS16. They are modes but >> sill part of a single ISA. > > > Yes, but not in an interesting sense. It's much like the IA32 engine > inside IA64: they surely aren't the same ISA, despite being executable > by the same hardware, and operating partly on the same registers. > Sure, arm & thumb are closer together, and they may be documented in > the same publication, but that's not substantial to this question. Yes, and both bfd_arch_ia64 and bfd_arch_i386 are defined as separate bfd_architectures. > The conceptual issue is whether or not the choice of instructions > available is a function of processor state. For the purposes of > tools like disassemblers and simulators, and really even assemblers > and compilers, each such group forms a separate instruction set. Sorry, can you try that again. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20020201092827.H6166@redhat.com>]
[parent not found: <3C5AE910.4090009@cygnus.com>]
* Re: include/dis-asm.h patch for cgen disassemblers [not found] ` <3C5AE910.4090009@cygnus.com> @ 2002-02-01 11:56 ` Frank Ch. Eigler 2002-02-01 12:02 ` Andrew Cagney [not found] ` <3C5AF9D1.8070607@cygnus.com> 0 siblings, 2 replies; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 11:56 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 2989 bytes --] Hi - cagney wrote: > [...] > >> Yes, and both bfd_arch_ia64 and bfd_arch_i386 are defined as separate > >> bfd_architectures. > > > > That's something else, explained by other factors, such as the > > ~12-year delay between their development, and a reluctance to > > build any given program with both pieces. > > It is also explained by someone making the rational decision that these > two ISA's really are different and hence deserve separate > bfd_architecture designations. It is a sensible modelling decision, given that executables are unlikely to mix ia64 and ia32 code. The point of the example was to show that the same piece of hardware can implement distinct instruction sets, contrary to your possible desire to lump them all into one mega-isa and calling them insubstantial "modes". (BTW, I wonder whether ia64 OS kernels need to have some of each, and if so, whether linker tricks are required to make that work.) > Consider the PS2. It contains a number of compute engines (for want of > a better term), each with their own ISA. Do they each get their own > bfd_architecture or does something else happen? [...] We did whatever must have seemed most useful at the time for their treatment ... one bfd_arch, a bunch of bfd_mach's. Note that all those coprocessors have a static set of instructions. > > Think about it. If the processor has modes, each of which has a > > different set of instructions available to it, then for many > > purposes, those sets need to be formally identified as distinct > > groups. That's what an instruction set is, in the deeper sense. > > To me thi appears to be subverting what I understand to be the original > intent of BFD's architecture / machine model. The subverting might be a > good thing, however, it needs to be carefully considered and in a > context that doesn't assume CGEN or SID. Referring to BFD misses the point! The BFD library barely cares about individual instructions or instruction sets. (The only example I can come up with off the top of my head is linker relaxation -- about as inspiring a module as gdb prologue decoding. :-) Instruction sets as such show up in the gas, opcodes, gcc, simulators, and so on. Look there for enlightenment. > [...] > My guess is ``environment'' (stolen from the PPC ISA manual). For instance: > > bfd_powerpc - the ISA or ISA family > ppc620 - the specific implementation - supports two modes (or as > you like to call them ISA) > environment - 32/64, operating/user, altivec, ... 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? - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 11:56 ` Frank Ch. Eigler @ 2002-02-01 12:02 ` Andrew Cagney 2002-02-01 12:10 ` Frank Ch. Eigler [not found] ` <3C5AF9D1.8070607@cygnus.com> 1 sibling, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-02-01 12:02 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Andrew Cagney, binutils, cgen > Consider the PS2. It contains a number of compute engines (for want of >> a better term), each with their own ISA. Do they each get their own >> bfd_architecture or does something else happen? [...] > > > We did whatever must have seemed most useful at the time for their > treatment ... one bfd_arch, a bunch of bfd_mach's. Note that all > those coprocessors have a static set of instructions. I'll take that as a royal we. I don't know what you did for the PS2 and will probably regret finding out. However, please expand. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 12:02 ` Andrew Cagney @ 2002-02-01 12:10 ` Frank Ch. Eigler 2002-02-01 12:44 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 12:10 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 616 bytes --] Hi - cagney wrote: > > We did whatever must have seemed most useful at the time for their > > treatment ... one bfd_arch, a bunch of bfd_mach's. Note that all > > those coprocessors have a static set of instructions. > > I'll take that as a royal we. I don't know what you did for the PS2 and > will probably regret finding out. It wasn't that bad. > However, please expand. In the context of discussing that port on a public mailing list, and its iffy relevance to the current thread, I don't see why I should do go into any more detail. You know where to find the sources. - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 12:10 ` Frank Ch. Eigler @ 2002-02-01 12:44 ` Andrew Cagney 2002-02-01 12:56 ` Andrew Cagney 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-02-01 12:44 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Andrew Cagney, binutils, cgen > Hi - > > cagney wrote: > > >> > We did whatever must have seemed most useful at the time for their >> > treatment ... one bfd_arch, a bunch of bfd_mach's. Note that all >> > those coprocessors have a static set of instructions. > >> >> I'll take that as a royal we. I don't know what you did for the PS2 and >> will probably regret finding out. > > > It wasn't that bad. > > >> However, please expand. > > > In the context of discussing that port on a public mailing list, > and its iffy relevance to the current thread, I don't see why I > should do go into any more detail. You know where to find the > sources. I chose the PS2 because its architecture is public and, I think, it very much illustrates the underlying issue of the current discussion. The PS2 has a number of ISAs on a single chip. What is the correct way to define this from bfd? If you don't feel comfortable with answering this, then hopefully someone else will. Off the top of my head I can think of several ways: bfd_arch_mips bfd_mach_mips_ps2mips bfd_mach_mips_ps2video bfd_arch_ps2 bfd_mach_ps2mips bfd_mach_ps2video bfd_arch_mips bfd_mach_mips_ps2 bfd_arch_ps2video I think BFD to clearly document how this should be done, your isas is very much part of this. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 12:44 ` Andrew Cagney @ 2002-02-01 12:56 ` Andrew Cagney 2002-02-01 13:23 ` Frank Ch. Eigler 0 siblings, 1 reply; 24+ messages in thread From: Andrew Cagney @ 2002-02-01 12:56 UTC (permalink / raw) To: Andrew Cagney; +Cc: Frank Ch. Eigler, Andrew Cagney, binutils, cgen > I chose the PS2 because its architecture is public and, I think, it very much illustrates the underlying issue of the current discussion. > > The PS2 has a number of ISAs on a single chip. What is the correct way to define this from bfd? If you don't feel comfortable with answering this, then hopefully someone else will. Off the top of my head I can think of several ways: > > bfd_arch_mips > bfd_mach_mips_ps2mips > bfd_mach_mips_ps2video > > bfd_arch_ps2 > bfd_mach_ps2mips > bfd_mach_ps2video > > bfd_arch_mips > bfd_mach_mips_ps2 > bfd_arch_ps2video > > I think BFD to clearly document how this should be done, your isas is very much part of this. Sorry, you did answer this. >> We did whatever must have seemed most useful at the time for their >> treatment ... one bfd_arch, a bunch of bfd_mach's. Note that all >> those coprocessors have a static set of instructions. that would be #2 above. The question is then, is this the most applicable model and acceptable to BFD/BINUTILS? It definitly means a sideways twist since ps2mips is a member of the bfd_arch_mips family. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-01 12:56 ` Andrew Cagney @ 2002-02-01 13:23 ` Frank Ch. Eigler [not found] ` <3C5B1E19.8030405@cygnus.com> 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 13:23 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 1336 bytes --] Hi - cagney wrote: > The PS2 has a number of ISAs on a single chip. [...] I hope you're not just yanking my chain. You should realize that the PS2 processor chip is more of a system-on-a-chip, with distinct processors on one die. The fact that they are on the same chip is a fabrication decision, absurd to contemplate during bfd modelling. > that would be #2 above. The question is then, is this the most > applicable model and acceptable to BFD/BINUTILS? [...] I don't really care -- it has no bearing on the current issue. Maybe you are confusing the term "ISA" with the concept of a "manual" or "book". Maybe you are confusing an overall architecture by a list of instructions that some implementation of some architecture may execute in some modes. Maybe you are confusing my intent of using the "isas" field (to identify subsets of the instruction sets implemented by the current arch/mach) with some imagined plan to replace arch/mach. Please get unconfused, for example by thinking about the relationship between arm & thumb instructions. Hint: a single program can contain both. Such an executable file can be marked with a single bfd_arch/mach tag pair. The processor switches its interpretation of instruction memory contents based upon internal run-time state. - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <3C5B1E19.8030405@cygnus.com>]
* Re: include/dis-asm.h patch for cgen disassemblers [not found] ` <3C5B1E19.8030405@cygnus.com> @ 2002-02-04 8:32 ` Frank Ch. Eigler [not found] ` <3C601DB8.7080700@cygnus.com> 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-04 8:32 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- Attachment #1: Type: text/plain, Size: 3445 bytes --] Hi - cagney wrote: > [...] > What has a fabrication decision got to do with this? The PS2 is a > number of different ISAs that happen to be on a single chip. Good, we agree. > I'm contending that this is correctly modeled within BFD as separate > BFD_ARCH's. If it isn't then the documentation, at least, for BFD is wrong. > > You appear to contend that it is correctly modeled as a single bfd_arch > and a number of different bfd_machs. [...] It is correct in the sense that it works (and has been working for, oh, three years now?), it's reasonably compact in code, and it doesn't obviously contradict any important rules. If you prefer a new "correctness" criterion that it fails, the it's not "correct", but the onus is on you to justify your criterion. > > I don't really care -- it has no bearing on the current issue. > > It has direct bearing on the current issue. Your response to the above > illustrates this. I wish you simply read what I wrote. There is no connection between this PS2 modelling issue and the new one. I'll put it in a table so you can't miss it: PS2 MULTIPLE-ISA CHIP * multiple processors * single processor * one instruction set per * multiple instruction sets processor * one bfd_arch, multiple * one bfd_arch, one bfd_mach bfd_machs 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. In the mean time, I expect that people recognize the second column as a distinct situation, with a distinct problem (run-time selection among several instruction sets a la arm/thumb), for which my patch is a reasonable solution. > [...] > Who knows what you're doing. You haven't posted any thing updating the > documentation and clarifying this. AFAIK (and I at least have looked), the disassemble_info struct is not separately documented. I will expand on the inline comments though. > [...] Try, instruction_subsets then? I have strong reservations over > isa as it and bfd_architecture are badly overloaded. So -- it is the "a" in "isa" that concerns you. I will for now dodge the issue whether it makes sense to talk about the architecture of an instruction set per se, as opposed to the larger architecture of a processor. I propose to adopt the shortened "insn_sets" as the new disassemble_info field name in question. > 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. - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <3C601DB8.7080700@cygnus.com>]
* Re: include/dis-asm.h patch for cgen disassemblers [not found] ` <3C601DB8.7080700@cygnus.com> @ 2002-02-05 11:29 ` Frank Ch. Eigler 2002-02-05 12:42 ` Doug Evans 0 siblings, 1 reply; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-05 11:29 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen 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) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: include/dis-asm.h patch for cgen disassemblers 2002-02-05 11:29 ` Frank Ch. Eigler @ 2002-02-05 12:42 ` Doug Evans 0 siblings, 0 replies; 24+ messages in thread From: Doug Evans @ 2002-02-05 12:42 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Andrew Cagney, binutils, cgen Frank Ch. Eigler writes: > 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. > + I like "insn_sets" _much_ better than "isa". I can see countless more disagreements avoided. :-) Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <3C5AF9D1.8070607@cygnus.com>]
* Re: include/dis-asm.h patch for cgen disassemblers [not found] ` <3C5AF9D1.8070607@cygnus.com> @ 2002-02-01 12:39 ` Frank Ch. Eigler 0 siblings, 0 replies; 24+ messages in thread From: Frank Ch. Eigler @ 2002-02-01 12:39 UTC (permalink / raw) To: Andrew Cagney; +Cc: binutils, cgen [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2002-02-05 20:42 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-31 9:43 include/dis-asm.h patch for cgen disassemblers 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 2002-02-05 12:42 ` Doug Evans [not found] ` <3C5AF9D1.8070607@cygnus.com> 2002-02-01 12:39 ` Frank Ch. Eigler
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).