Re: pathmap or dir command on drugs

[jtc at redback dot com (J.T. Conklin)]

>>>>> "David" == David Taylor <taylor@cygnus.com> writes:
David> It has been requested that GDB support the ability to move the
David> source tree used to build the program being debugged -- without
David> having to type in lots of directories for a really long dir
David> command.

Yes.  This gets old very fast, especially if your image is built from
sources in many subdirectories.

David> The idea is that there would be a command which would take two
David> path arguments and would arrange that whenever gdb was asked to
David> list source code, it would replace the 'from' prefix with the
David> 'to' prefix before opening the file.

Should this facility be limited only to prefixes?  A regex based
transformation scheme like used by the pax utility would be more
general.  While most of the time I've used pax's transformations to
change prefixes, once or twice I've done "more interesting" things.

David> The real value of such a mechanism is when there are many
David> directories it can save some typing.

s/some/lots and lots and lots and lots/

David> If you had multiple trees, you could set up multiple mappings.
David> If you made a typo when typing in a pathmap, you could delete
David> that one pathmap.

How do you envision multiple mappings work?  Does GDB process mappings
in order and terminate when the first successful substitution?  This
seems to be the only sane behavior to me, but it requires the ability
to maintain an ordered list from the CLI.

David> There seems to be at least two camps on what the interface should be:
David>
David> One camp, by comparison with breakpoints and displays, is:
David>
David>     pathmap <from-prefix> <to-prefix>
David>     show pathmaps <optional-list>
David>     delete pathmaps <optional-list>
David>
David> The other camp is
David>
David>     pathmap add <from-prefix> <to-prefix>
David>     pathmap list <optional-list>
David>     pathmap delete <optional-list>

Both interfaces are essentially the same, and neither handles a sorted
list very well.  After thinking about it as I've been composing this
message, I think this is a feature that must be provided for.

Imagine a situation where you have a product built from a tree like
the below, where third-party code is in a separate subdirectory.

        /foo/vendor/dir1
        /foo/dir2
        /foo/dir3

But then you have to process it on another machine where the third-
party code is on another filesystem (perhaps it's archived on a
cdrom).

        /cdrom/dir1
        /bar/dir2
        /bar/dir2

A pathmap like this:
        pathmap /foo/vendor     /cdrom
        pathmap /foo            /bar

will work fine, while:
        pathmap /foo            /bar
        pathmap /foo/vendor     /cdrom

will fail because the first map will match first.


An ordered pathmap is sort of like access-lists on Cisco's IOS.
Anyone know what kind of CLI they offer to edit them?  I can't recall
off hand.


David> By further analogy with breakpoints and displays, we could also have:
David>
David>     disable pathmaps <optional-list>
David>     enable pathmaps <optional-list>
David>
David> or
David>
David>     pathmap disable <optional-list>
David>     pathmap enable <optional-list>
David>
David> [Though I have yet to hear a convincing argument for the need to have
David> enable and disable options.]

I agree.  

If I was writing the code, I'd do it to not preclude adding enable and
disable options, but skip it until it's proven to be useful.  While
you could argue that because breakpoints, displays, etc. have enable
and disable options and this should to be orthogonal, I'm not convinced
that pathmaps are really that similar.

        --jtc

-- 
J.T. Conklin
RedBack Networks