From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26704 invoked by alias); 14 May 2002 15:17:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26666 invoked from network); 14 May 2002 15:17:15 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 May 2002 15:17:15 -0000 Received: from localhost.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA17605; Tue, 14 May 2002 08:17:08 -0700 (PDT) Received: by localhost.redhat.com (Postfix, from userid 469) id 0E2BD10FC9; Tue, 14 May 2002 11:16:35 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15585.10835.680930.43907@localhost.redhat.com> Date: Tue, 14 May 2002 08:17:00 -0000 To: Nick Clifton Cc: Elena Zannoni , thorpej@wasabisystems.com, binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf* In-Reply-To: References: <20020511115603.W3435@dr-evil.shagadelic.org> <20020513082324.R3435@dr-evil.shagadelic.org> <15584.11203.728429.774659@localhost.redhat.com> <15585.5715.936570.74188@localhost.redhat.com> X-SW-Source: 2002-05/txt/msg00539.txt.bz2 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