public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@zembu.com>
To: nickc@cygnus.com
Cc: binutils@sourceware.cygnus.com
Subject: Re: Patch to change ARM register name set
Date: Thu, 01 Jul 1999 00:00:00 -0000	[thread overview]
Message-ID: <19990615163347.1080.qmail@daffy.airs.com> (raw)
In-Reply-To: <199906150957.KAA18137@pathia.cygnus.co.uk>

   Date: Tue, 15 Jun 1999 10:57:16 +0100
   From: Nick Clifton <nickc@cygnus.com>

   : However, adding a new disassembler2 function does not make sense to
   : me.  Adding new functions because you have a new parameter is an
   : approach that leads to ABI complexity.  It's part of what makes the
   : Win32 ABI so difficult to work with.  Don't tread that path.  Instead,
   : just change the existing function.

   OK - that is actually what I wanted to do in the first place, but I
   did not know if there were lots of utilities out there that use the
   current disassembler() function, so I did not want to change it.

I doubt anything uses disassembler other than the binutils and gdb.

   : In objdump.c, I think target_data is a poor choice of names.  This is
   : an option to the disassembler.  objdump does many things other than
   : disassemble, so using a word like `target_data' to describe something
   : which is specific to the disassembler is misleading.  Something like
   : `disassembler_options' makes more sense to me.  This should be changed
   : in the suggested documentation as well.

   OK - although I had hoped that this might turn into a more generic
   type of command line switch where the text could be passed to other
   components of objdump, not just its disassembler.

That's an interesting idea.  For most of what objdump does, though,
there is no code which could interpret the option.  It only makes
sense to have a generic option like that in cases where objdump
invokes target specific code.  The only case which comes to mind other
than disassembly is the -p option to print private data.  I could
imagine cases where it would be useful to pass an option to -p, but I
think that generally it would not make sense.  I don't really want to
go down the path of passing a lot of options to -p to control what it
prints.

However, perhaps there is something I am not thinking of.

Ian

  reply	other threads:[~1999-07-01  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 ` Ian Lance Taylor [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 ` Scott Bambrough
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 ` Richard Earnshaw
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 ` Richard Earnshaw
1999-07-01  0:00 ` Ian Lance Taylor
1999-07-01  0:00 Nick Clifton
1999-07-01  0:00 ` Richard Earnshaw

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=19990615163347.1080.qmail@daffy.airs.com \
    --to=ian@zembu.com \
    --cc=binutils@sourceware.cygnus.com \
    --cc=nickc@cygnus.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).