Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf*

[Elena Zannoni <ezannoni@redhat.com>]

Nick Clifton writes:
 > Hi Elena,
 > 
 > >  > > The tdep gdb file is going to be built for all the sh targets. And
 > >  > > that file requires the sh64 disassembly functions.
 > >  > 
 > >  > In which case there may well be a problem.  As it stands configuring
 > >  > BFD as, eg, sh3-elf will not bring in the sh64 architecture or
 > >  > disassembly functions.  Can the tdep file be made conditional on the
 > >  > SH architecture specified on the configure command line ?
 > >  > 
 > > 
 > > No, it wouldn't be accepted. We are going towards unifying all the
 > > targets for a given architecture, so that we can switch at runtime
 > > with multiarch.  I mean, it is not technically impossible, but it is
 > > philosophically inconsistent with where gdb is going nowadays. We are
 > > even going to build multiple architectures together, like sh and ppc,
 > > in a single executable.  As a matter of fact I had such defines when I
 > > first submitted the port, and I removed them.
 > 
 > Hmm, OK - in which case would it be acceptable to say that in order to
 > obtain GDB support an SH toolchain should be configured as "sh-elf"
 > and not "sh3-elf" even if the intended default processor is the SH3 ?
 > ie that configurations such as "sh3-elf" are becoming obsolete and
 > will one day be removed ?
 > 

Yes, kind of. The sh3-elf support (for instance) is in there, together
with all the rest.  sh-elf gets you the whole shebang, in theory. Gdb gets the
list of available architectures from bfd:

(gdb) set architecture 
Requires an argument. Valid arguments are sh, sh2, sh-dsp, sh3, sh3-dsp, sh3e, sh4, sh5, auto.

Now, this happens in theory only, because the sh5 disassembly support
is not always integrated.  So if you configure with sh3-elf at the
moment, gdb tries to build *everything*, treating it just like
sh-elf. But the build will barf because of the disassembly function.
(never mind that at present I forgot to add a sh* target, I'll do it now).

To be even clearer, the real problem is the disassembly function interface.
Right now gdb does this (more or less):

if (machine is sh5)
{
  if (target is big endian)
     call print_insn_sh64()
  else
     call print_insn_sh64l()
}
else
{
  if (target is big endian)
     call print_insn_sh()
  else
     call print_insn_shl()
}

It shouldn't. It should just call a print_insn_sh() function that
based on the contents of the info parameter decides what to do.
I.e., the opcodes/sh-dis.c should have something like this:

int
print_insn_sh (memaddr, info)
     bfd_vma memaddr;
     struct disassemble_info *info;
{
  int r;

  if (info->mach == bfd_mach_sh5)
    {
      if (info->endian == BFD_ENDIAN_LITTLE)
	r = print_insn_sh64_little (memaddr, info);
      else
	r = print_insn_sh64_big (memaddr, info);
    }
  else
    {
      if (info->endian == BFD_ENDIAN_LITTLE)
	r = print_insn_sh_little (memaddr, info);
      else
	r = print_insn_sh_big (memaddr, info);
    }

  return r;
}

opcodes/disassemble.c should also use this generic 'wrapper' like most
of the other targets do, instead of using the INCLUDE_SHMEDIA macro.

This way the interface into the disassembler would just be one function.
Right now there are a lot of sh disassembly functions:

extern int print_insn_sh64		PARAMS ((bfd_vma, disassemble_info *));
extern int print_insn_sh64l		PARAMS ((bfd_vma, disassemble_info *));
extern int print_insn_sh64x_media	PARAMS ((bfd_vma, disassemble_info *));
extern int print_insn_sh		PARAMS ((bfd_vma, disassemble_info*));
extern int print_insn_shl		PARAMS ((bfd_vma, disassemble_info*));


Elena