From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: "Brown, Rodney" Cc: RDBrown@mira.net, Geoff Keating , "'gdb@sources.redhat.com'" Subject: Re: Preferred format of Copyright statement Date: Mon, 06 Nov 2000 04:10:00 -0000 Message-id: <3A069E39.850BA570@cygnus.com> References: <40D1CB7FA1EAD311BD610008C733141C1DE0E8@aus-msg-02.au.pmsc.com> X-SW-Source: 2000-11/msg00023.html > "Brown, Rodney" wrote: > > For the patches supplied I found it easiest to run the script, > correct the (few) errors it diagnosed and then walk through the > changes > doing some minor reformatting. The ChangeLog entries took almost as > long. Since the changes are mainly in comments a big bang approach is > less risky than for PARAMS. Once the distraction of Roy & HG is over I > should be able to > supply patches with a few days turn around at most, so whenever it > is convenient for you guys. The big bang theory sounds fine. Andrew >From taylor@cygnus.com Mon Nov 06 13:25:00 2000 From: David Taylor To: gdb@sourceware.cygnus.com Subject: pathmap or dir command on drugs Date: Mon, 06 Nov 2000 13:25:00 -0000 Message-id: <200011062125.QAA00561@texas.cygnus.com> X-SW-Source: 2000-11/msg00024.html Content-length: 2134 It has been requested that GDB support the ability to move the source tree used to build the program being debugged -- without having to type in lots of directories for a really long dir command. The idea is that there would be a command which would take two path arguments and would arrange that whenever gdb was asked to list source code, it would replace the 'from' prefix with the 'to' prefix before opening the file. So, if you had a source tree /old/top/dir sub/dir1/file1.c subdir2/file2.c sub3/dir3/file3.c when you built your program, but you were now debugging on a different system where it was mounted as /new/top/dir Then to tell gdb how to find the source code you wouldn't have to give a dir command with all the subdirectories /new/top/dir/sub/dir1 /new/top/dir/subdir2 /new/top/dir/sub3/dir3 you could instead just give one command which said that when presented with /old/top/dir replace it with /new/top/dir The real value of such a mechanism is when there are many directories it can save some typing. If you had multiple trees, you could set up multiple mappings. If you made a typo when typing in a pathmap, you could delete that one pathmap. There seems to be at least two camps on what the interface should be: One camp, by comparison with breakpoints and displays, is: pathmap show pathmaps delete pathmaps The other camp is pathmap add pathmap list pathmap delete By further analogy with breakpoints and displays, we could also have: disable pathmaps enable pathmaps or pathmap disable pathmap enable [Though I have yet to hear a convincing argument for the need to have enable and disable options.] So, is this functionality people would like to see gdb have? Is this the form it should take? And what interface do people feel it should have? -- one of the above? or something else altogether? Other comments are also welcome. >From fnasser@cygnus.com Mon Nov 06 13:48:00 2000 From: Fernando Nasser To: David Taylor Cc: gdb@sourceware.cygnus.com Subject: Re: pathmap or dir command on drugs Date: Mon, 06 Nov 2000 13:48:00 -0000 Message-id: <3A072726.BB42BEA3@cygnus.com> References: <200011062125.QAA00561@texas.cygnus.com> X-SW-Source: 2000-11/msg00025.html Content-length: 1667 David Taylor wrote: > > One camp, by comparison with breakpoints and displays, is: > > pathmap > show pathmaps > delete pathmaps > > The other camp is > > pathmap add > pathmap list > pathmap delete > I vote for the second one for a few reasons: 1) I think displays and breakpoints are objects related to the inferior program execution. Let's say they are of the Exec class. This "pathmap" facility is related to the source level debugging capabilities of gdb, lets say they are from the "Symbol" class. I would rather not mix. 2) These commands that have a show without a set are confusing (if we can say "show pathmap" we would expect to be able to say "set pathmap"). I know that we already have may of those, but I would rather not add one more. 3) The second option keeps this feature completely independent and completely out of the way of someone who doesn't want to map paths. It doesn't show in help delete, as a show command option. It is neatly separated. But people may have arguments to the first option as well, so I will wait to see what the general preference is. As to the functionality, it is not my call, but I find it an interesting to have around. I have the feeling that I may have used this if it existed before. P.S.: I guess one can say "pathmap delete all", right? (or "delete pathmap all") -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From jtc@redback.com Mon Nov 06 14:20:00 2000 From: jtc@redback.com (J.T. Conklin) To: David Taylor Cc: gdb@sourceware.cygnus.com Subject: Re: pathmap or dir command on drugs Date: Mon, 06 Nov 2000 14:20:00 -0000 Message-id: <5m1ywo68v8.fsf@jtc.redback.com> References: <200011062125.QAA00561@texas.cygnus.com> X-SW-Source: 2000-11/msg00026.html Content-length: 3709 >>>>> "David" == David Taylor 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 David> show pathmaps David> delete pathmaps David> David> The other camp is David> David> pathmap add David> pathmap list David> pathmap delete 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 David> enable pathmaps David> David> or David> David> pathmap disable David> pathmap enable 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 >From Fabrice_Gautier@sdesigns.com Mon Nov 06 15:41:00 2000 From: Fabrice Gautier To: "GDB (E-mail)" Subject: finish breakpoints not deleted. Date: Mon, 06 Nov 2000 15:41:00 -0000 Message-id: X-SW-Source: 2000-11/msg00027.html Content-length: 430 Hi, When I use "finish" to return from the current function, it works but then gdb will always stop at this point as if a breakpoint was set for the "finish" and never deleted after. The only way I have to delete this invisble breakpoint is to set and delete another one a the same point. I'm using gdb (insight) do debug a remote i386 target running an eCos program. Thanks -- Fabrice Gautier fabrice_gautier@sdesigns.com