In earlier versions of Fedora I could use the "require" command to load things like the "pahole" command. E.g., "require command pahole". This is not possible in F15 because nothing loads the require command. I think the require command is a dead end. Instead we should change gdb startup to load all additional files from gdb.command and gdb.function. Alternatively we could support /usr/share/gdb/auto-load/startup/, with gdb loading each .py found there; then put our additional commands into that directory.
There is: ==> /etc/gdbinit <== # System-wide GDB initialization file. # FIXME: provide a wildcard. source /etc/gdbinit.d/gdb-heap.py I believe it can serve for the purpose of autoloading anything. Which Python commands should / should not be autoloaded is up to Phil.
(In reply to comment #1) > There is: > ==> /etc/gdbinit <== > # System-wide GDB initialization file. > > # FIXME: provide a wildcard. > source /etc/gdbinit.d/gdb-heap.py > > > I believe it can serve for the purpose of autoloading anything. > Which Python commands should / should not be autoloaded is up to Phil. Yes, I think we should have something more automatic, in particular a directory where a package can drop a .py and expect to have it loaded. This should be done upstream.
My plan is to just get the contents of command/ and function/ with os.list. Remove any entries that do not have a .py extension, any directories and __init__.py. Then I'll just iterate that list, calling execfile on each entry. That seems to most straightforward way to me. I do not think that we will encounter any delays in loading GDB with this approach. The number of commands/functions is very small. We can always address performance later, if it becomes an issue. What do you think?
The source command needs to be fixed anyway (for existing /etc/gdbinit), in such case one can use just the source command.
Right, but this is automated from within the Python loading code. Nobody would need to add anything to their own config, GDB would just "load" everything on startup
Iif the `source' command gets fixed anyway this Bug can be resolved by: echo 'source /usr/share/gdb/python/gdb/command/*.py' >>/etc/gdbinit Sure not a problem as the code in Python is less lines than our discussion here.
Ah, I was approaching it from an upstream point of view, not necessarily a Fedora view.
--with-system-gdbinit is a FSF GDB feature and being already used for some time also in Debian makes it used in most of the GDB deployments.
OK, I got it now that FSF GDB does not ship any default system gdbinit file which this Python feature would require. OK, I agree it is better to not reuse the `source' command functionality here.
Created attachment 516540 [details] Auto-load python commands and functions
Oops clicked submit in #10 before I could add a comment. I added a patch that does what is requested. There is no "function" directory in FSF GDB, so I decided to just to post it here. If it works, I can modify the patch for FSF just to load "commands" instead. Or we could just patch/carry this feature as a Fedora case only. What do you think?
(In reply to comment #10) > Created attachment 516540 [details] > Auto-load python commands and functions This should use os.path.join instead of "/". I think it would be preferable to use import instead of execfile, if possible. This should also fix up lib/gdb/__init__.py not to redundantly load gdb.command.pretty_printers; and also fix that file to auto-create its command (instead of having a function to do this). (In reply to comment #11) > Oops clicked submit in #10 before I could add a comment. > > I added a patch that does what is requested. There is no "function" directory > in FSF GDB, so I decided to just to post it here. If it works, I can modify > the patch for FSF just to load "commands" instead. Or we could just > patch/carry this feature as a Fedora case only. > > What do you think? This should go upstream. It needs a documentation update. We should ship some functions by default, so this should keep looking there.
*** This bug has been marked as a duplicate of bug 730976 ***