This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA] New substitute-path commands


Hello,

Following up on a discussing that took place on the gdb@ mailing list:

        http://sources.redhat.com/ml/gdb/2006-06/msg00192.html

I implemented a new set of commands that should be useful in the case
when a developer debugs a program of which the source tree has been
moved to a different location from where it was compiled.

The new commands are:

        (gdb) substitute-path add <from> <to>
        (gdb) substitute-path remove
        (gdb) substitute-path

  * "substitute-path add" adds a substitution rule, where the first
    instance of <from> is replaced by <to>.

  * "substitute-path remove" removes the current substitution rule
    if one was specified. No effect otherwise.

  * "substitute-path" prints the current substitution rule.

Some users argued that "substitute-path show" should also be added.
I think it's mostly aesthetic, and hence passed on this suggestion,
but I can do that as well if others think it'd be nice to have it.

At least one user suggested that we provide the possibility of applying
a list of substitution rules as opposed to one. I'm not against that
idea, but this makes the design and implementation slightly more complex
for something that I think will be little used. I suspect that most
people will use it in a very specific context where the entire source
tree has been moved - so one substitution rule should be enough.

Nonetheless, should anybody require this feature, there is an upward
compatible way of enhancing my implementation later on. The "add"
command remains the same. The "remove" command without any argument
would delete all substitution rules. And with a "from" argument, it
would remove the rule that matches "from". The "substitute-path"
command would print all substitution rules, not just the one.

Here is how I tested it:

        * In a root directory, I have some sources in src/
        * cd to src/, and compile the sources
        * cd <root>, cp -R src dup
        * cd src/, modify one line of my source file
        * gdb dup/my_program
          (gdb) substitute-path add src dup
          (gdb) list my_program.c:1

With the current debugger, GDB will list src/my_program.c. But in
fact, this is no longer the file that was used to build the program
we're actually debugging. With the patch I am suggesting, the debugger
lists dup/my_program.c.

The "substitute-path" has two uses that I can see, each of them when
the path to the source tree available to GDB is different from the path
when the program was built:

  . 1: The path to the source tree is no longer valid for whatever
       reason. In that case, the "dir" command can be used to point
       GDB to the current location. But larger programs may use a
       full tree of directories, making it painful because one has
       to use a series of "dir" commands, one per directory. This
       new command makes it easier.

  . 2: The path to the source tree is still valid. This is the case
       I explained in my message on gdb@. Please refer to it for more
       details. In this case, this new command is the only way to make
       sure GDB uses the right sources.

Question: Is a MI equivalent needed?

2006-07-05  Joel Brobecker  <brobecker@adacore.com

        * source.c (substitute_path_from): New static variable.
        (substitute_path_to): Likewise.
        (substitute_path_cmdlist): Likewise.
        (xrewrite_source_path): New function.
        (find_and_open_source): Add source path rewriting support.
        (substitute_path_command): New function.
        (xextract_path_argument): New function.
        (substitute_path_remove_command): New function.
        (substitute_path_add_command): New function.
        (_initialize_source): Add new substitute-path commands.

Tested on x86-linux, no regression. I wouldn't mind adding a testcase
for this new feature, but I'm not sure yet how to achieve this.

Documentation & NEWS update will be sent if the feature is accepted.

Thanks,
-- 
Joel

Attachment: subst.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]