Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: David Taylor <taylor@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@france.sun.com>,
	gdb@sourceware.cygnus.com
Subject: Re: pathmap or dir command on drugs
Date: Tue, 07 Nov 2000 10:19:00 -0000	[thread overview]
Message-ID: <200011071818.NAA00809@texas.cygnus.com> (raw)

    Date: Tue, 07 Nov 2000 12:59:54 +0000
    From: Fernando Nasser <fnasser@cygnus.com>

    Stephane Carrez wrote:
    > 
    > David Taylor wrote:
    > > The other camp is
    > >
    > >    pathmap add <from-prefix> <to-prefix>
    > >    pathmap list <optional-list>
    > >    pathmap delete <optional-list>
    > 
    > Looks good,
    > 
    > As for dbx, I suggest to give numbers to each pathmap so that deletion is
    > made on the index rather than on some path.

When I last used dbx it didn't have a pathmap command.  And my current
system doesn't have dbx on it -- would you be willing to summarize the
current dbx pathmap command?

    Yes, the idea is that you can have

    pathmap delete 3
    pathmap delete 4-6
    pathmap delete all

    Deletions on the path are not very practical.

When I said <optional-list> I was thinking of the way breakpoints and
displays are handled -- you give the numbers you want deleted.

    > I guess we need some optional argument to 'add' to tell the position of
    > the new pathmap in the list. After that, the old pathmaps after the new
    > one, will have their index incremented. Well, like dbx :-)
    > 

    I suggest an "insert" subcommand:

    pathmap insert <index> <from> <to>

    It is like add but it lets the user specify after which entry it 
    should be added.

Actually, if there is an insert, then either it should be an insert
before or that should be an option or you need to allow <index> to
be 0 -- otherwise you cannot insert before the first element.

    This way there will be no parsing madness trying to decide if something
    is a path or a number.

This could also be done based on 2 vs 3 arguments, but I prefer an
approach of having you say what you mean... so I like 'insert' better.


             reply	other threads:[~2000-11-07 10:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-07 10:19 David Taylor [this message]
2000-11-07 10:37 ` Fernando Nasser
  -- strict thread matches above, loose matches on Subject: below --
2000-11-07  3:11 Stephane Carrez
2000-11-07  5:01 ` Fernando Nasser

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=200011071818.NAA00809@texas.cygnus.com \
    --to=taylor@cygnus.com \
    --cc=Stephane.Carrez@france.sun.com \
    --cc=fnasser@cygnus.com \
    --cc=gdb@sourceware.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