Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: use MIPS NewABI register names when disassembling NewABI code
Date: Wed, 09 Apr 2003 03:45:00 -0000	[thread overview]
Message-ID: <or1y0cbag7.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <3E93391F.2050005@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Apr  8, 2003, Andrew Cagney <ac131313@redhat.com> wrote:

>> On Apr  8, 2003, Andrew Cagney <ac131313@redhat.com> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mips-gdb-abi-disassemble.patch --]
[-- Type: text/x-patch, Size: 2751 bytes --]

Index: gdb/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* 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;

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
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

  reply	other threads:[~2003-04-09  3:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08  2:31 Alexandre Oliva
2003-04-08  7:35 ` Andrew Cagney
2003-04-08 11:59   ` Alexandre Oliva
2003-04-08 21:03     ` Andrew Cagney
2003-04-09  3:45       ` Alexandre Oliva [this message]
2003-04-09 13:57         ` Daniel Jacobowitz
2003-04-09 14:52         ` Andrew Cagney
2003-04-11  5:43           ` Alexandre Oliva
     [not found]             ` <mailpost.1050039798.9718@news-sj1-1>
2003-04-11  6:03               ` cgd
2003-04-11  7:47                 ` Alexandre Oliva
2003-04-11 15:06                   ` Andrew Cagney
2003-04-12  0:31                     ` Alexandre Oliva
2003-04-28 21:13                       ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or1y0cbag7.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox