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


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

In my original post I made two points:

> Ugly? This bit:
>> +      static asymbol *symbols = NULL;
> is wrong.  There is more than one instance of an architecture.  The symbols lifetime is different to that of the architecture (assuming that the symbol's lifetime is tied to the corresponding bfd).

An architecture can't point at anything tied to the lifetime of an 
instance of a BFD.

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

It is wrong to assume that there is a BFD.  GDB needs to be able to work 
correctly vis:

$ gdb
(gdb) set architecture <mips-variant>
(gdb) set mips disassembler <disassembler-variant>
(gdb) target remote
(gdb) disassemble

and this is identical to the situtation that objdump encounters when 
presented with an srecord.

Please first fix objdump, and then we can see about fixing GDB.

Andrew



  parent reply	other threads:[~2003-04-09 14:52 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
2003-04-09 13:57         ` Daniel Jacobowitz
2003-04-09 14:52         ` Andrew Cagney [this message]
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=3E94339A.8030405@redhat.com \
    --to=ac131313@redhat.com \
    --cc=aoliva@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