This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf*
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