From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1704 invoked by alias); 9 Apr 2003 03:45:32 -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 1693 invoked from network); 9 Apr 2003 03:45:32 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 9 Apr 2003 03:45:32 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h393jTu24291; Tue, 8 Apr 2003 23:45:29 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8) with ESMTP id h393jSjt014760; Wed, 9 Apr 2003 00:45:28 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8/Submit) id h393jSSY014756; Wed, 9 Apr 2003 00:45:28 -0300 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: use MIPS NewABI register names when disassembling NewABI code References: <3E927BCA.1080702@redhat.com> <3E93391F.2050005@redhat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Wed, 09 Apr 2003 03:45:00 -0000 In-Reply-To: <3E93391F.2050005@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2003-04/txt/msg00150.txt.bz2 --=-=-= Content-length: 1894 On Apr 8, 2003, Andrew Cagney wrote: >> On Apr 8, 2003, Andrew Cagney wrote: >> >>> Ugly? This bit: >> >>>> + static asymbol *symbols = NULL; >> >>> is wrong. There is more than one instance of an architecture. >> Uh. I see. So much for trying to get rid of one more call to >> bfd_alloc. This is easy to fix, though. > What about the problem of lifetimes? What do you mean? I plan to use bfd_alloc for it, like bfd_make_empty_symbol does, which means it's allocated on the bfd's obstack, which gets it deallocated at the right time. >>> How does objdump manage to correctly disassemble something like an >>> srecord? >> Presumably, it doesn't. If it's not an ELF bfd, it has no way to >> tell which ABI to disassemble for. > Fixing that will cause the gdb side of this problem to fall out. I don't see what's there to be fixed, really, and I can't see how to change it either. n32 and n64, the only ABIs that use different register naming conventions, don't support anything other than ELF, so it's only fair for it to use information from the ELF headers to decide which naming convention to use. The only missing bit in gdb is to pass the needed information (namely the pointer to the bfd) to the disassembler. I don't have strong feelings against an approach such as disassembly-flavor or so, I just think it's overkill in this case. objdump already has code to figure it out itself, it's just that gdb is not giving it means to obtain the information. Or, put another way, I see gdb may want to standardize the way it passes information to the disassembler, but my take is that, before imposing changes on another module that already offers means to implement a feature, an attempt should be made to implement the needed feature that doesn't require changes in other modules. Here's a revised patch. Ok to install? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=mips-gdb-abi-disassemble.patch Content-length: 2751 Index: gdb/ChangeLog from Alexandre Oliva * Makefile.in (libbfd_h): New. (mips-tdep.o): Depend on it. * mips-tdep.c: Include it. (mips_gdbarch_init): Set tm_print_insn_info.symbols to at least an empty symbol. Index: gdb/Makefile.in =================================================================== RCS file: /cvs/uberbaum/gdb/Makefile.in,v retrieving revision 1.360 diff -u -p -r1.360 Makefile.in --- gdb/Makefile.in 6 Apr 2003 01:13:58 -0000 1.360 +++ gdb/Makefile.in 9 Apr 2003 03:44:40 -0000 @@ -574,6 +574,7 @@ elf_sh_h = $(INCLUDE_DIR)/elf/sh.h elf_arm_h = $(INCLUDE_DIR)/elf/arm.h $(elf_reloc_macros_h) elf_bfd_h = $(BFD_SRC)/elf-bfd.h libaout_h = $(BFD_SRC)/libaout.h +libbfd_h = $(BFD_SRC)/libbfd.h remote_sim_h = $(INCLUDE_DIR)/gdb/remote-sim.h demangle_h = $(INCLUDE_DIR)/demangle.h obstack_h = $(INCLUDE_DIR)/obstack.h @@ -1955,7 +1956,7 @@ mips-tdep.o: mips-tdep.c $(defs_h) $(gdb $(language_h) $(gdbcore_h) $(symfile_h) $(objfiles_h) \ $(gdbtypes_h) $(target_h) $(arch_utils_h) $(regcache_h) \ $(osabi_h) $(mips_tdep_h) $(block_h) $(opcode_mips_h) \ - $(elf_mips_h) $(elf_bfd_h) $(symcat_h) + $(elf_mips_h) $(elf_bfd_h) $(libbfd_h) $(symcat_h) mipsm3-nat.o: mipsm3-nat.c $(defs_h) $(inferior_h) $(regcache_h) mipsnbsd-nat.o: mipsnbsd-nat.c $(defs_h) $(inferior_h) $(regcache_h) \ $(mipsnbsd_tdep_h) Index: gdb/mips-tdep.c =================================================================== RCS file: /cvs/uberbaum/gdb/mips-tdep.c,v retrieving revision 1.187 diff -u -p -r1.187 mips-tdep.c --- gdb/mips-tdep.c 8 Apr 2003 19:21:15 -0000 1.187 +++ gdb/mips-tdep.c 9 Apr 2003 03:44:43 -0000 @@ -45,6 +45,7 @@ #include "opcode/mips.h" #include "elf/mips.h" +#include "libbfd.h" #include "elf-bfd.h" #include "symcat.h" @@ -5656,6 +5657,26 @@ mips_gdbarch_init (struct gdbarch_info i if (info.abfd) { + /* The disassembler uses *info.symbols to get to the bfd elf + flags, which it uses to tell the executable ABI, so we have + to give it at least one symbol. */ + if (tm_print_insn_info.symbols == NULL) + { + asymbol *symbol = NULL; + + /* It would be nice if we could bfd_release the previous + symbol, but we'd need a pointer to its bfd then. */ + symbol = bfd_make_empty_symbol (info.abfd); + if (symbol != NULL) + { + tm_print_insn_info.symbols = bfd_alloc (info.abfd, + sizeof (symbol)); + if (tm_print_insn_info.symbols != NULL) + *tm_print_insn_info.symbols = symbol; + tm_print_insn_info.num_symbols = 0; + } + } + /* First of all, extract the elf_flags, if available. */ if (bfd_get_flavour (info.abfd) == bfd_target_elf_flavour) elf_flags = elf_elfheader (info.abfd)->e_flags; --=-=-= Content-length: 289 -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer --=-=-=--