Modularize gdbinit #6
Conversation
The old layout is difficult to maintain due to the size of gdbinit and the fact that it is difficult to identify various components. The file has now been broken up into multiple submodules which are loaded by the main gdbinit file. .gdb and .gdbinit has to be symbolically linked to the users home directory for this to work.
Reindented code so that every module follows the same syntax.
Attempt to autodetect the target architecture and set up the global flags accordingly. This will make it unneccessary to try to figure this out manually and hardcode the values in .gdbinit.
Restructures the architecture-specific code to never assume that a certain architecture is being used. Adds a $MIPS global that when set to 1 identifies that the debugged target is MIPS. Also breaks out the script for detecting a target and places it as a bash-script in the .gdb-directory to make it easier to debug.
When passing an expression containing spaces as an argument to a GDB command it will be interpreted as multiple arguments even when enclosed in parentheses. In order to follow the general coding style these arguments are broken out and set in local variables that are then passed as arguments instead.
Having the ChangeLog in the .gdbinit-file now that it has been modularized made little sense since the user will need a .gdb-directory anyway. Moved the ChangeLog into a file of the same name and reflowed it so that it can be read without going bonkers.
Since hooks are general and there might be commands defined in multiple modules that need to install something into the same hook they have been moved to the .gdbinit-file instead.
|
I have added support for MIPS64 now as well. |
Updates the README to contain a list of contributors to gdbinit. Also adds documentation on many of the commands that it defines.
Copy the solution used for mips to ensure that only registers that are valid will be printed. I.e. if a register is set to "void" print zero instead of bailing out.
The commands were a bit difficult to read, hopefully this will make the documentation a little better.
Renames the GDB command files to separate them from the shell scripts etc. Also, this makes it easier for the editor to figure out what indentation, syntaxt highlighting etc to use. Also renames the CPU-specific modules to cpu-<architecture>.gdb to make it more obvious that they are submodules to cpu.gdb.
|
Hello, Thanks! |
|
I agree the single file has its benefits but I found it a bit difficult to maintain. One idea I had was to have it split up for development and then have a Makefile that would merge them into one file for release but I never got round to that. Looking forward to your work on the script! :D |
|
I would also prefer to see it modularized |
- the old `gdbinit-MacsBug-without-plugin` file that Apple ships with their gdb - the `kgmacros` that Apple ships with their kernel debug kit
add some gdb macros from Apple
found some more .gdb files in Apple's version of gdb
|
As you can see from these last commits, I find it easier to submit pull requests to @dholm's fork instead of this one, because dholm's is modularized, and this one isn't. If this repo were modularized, too, it would be easier for people to submit other pull requests to it, too. (although if that's by design and you don't want pull requests, then feel free to ignore) |
|
I'm still not sold to the modularize idea. Need to rethink about it since gdb is phased out by Apple and lldb is the future. |
|
Just because Apple says that Also, I don't see how |
|
Well, I will make the switch as soon as I find time to evaluate and write a gdbinit equivalent to lldb. Gdb being phased out is connected because I'm not sure if it's worth the time to modularize and improve some areas. |
|
Isn't lldb less functional than gdb? |
|
From what I have been hearing that's not true anymore. For most stuff it was already ok last time I tested it. |
|
Soon after I started using As an experiment I started rewriting just the context display as a The code is all here on github, https://github.com/dholm/voidwalker Since Apple's GDB is ancient you will have to install something newer (and sadly without their modifications). Personally I am using GDB 7.6 from Even though |
Unfortunately, gdb under Snow Leopard doesn't give a useful doublet. So let's go the extra step and grab the osabi and use it to determine what processor we're using and the size.
Attempt to detect the correct processor type under Snow Leopard's gdb.
Do not show [code] if CONTEXTSIZE_CODE is set to 0.
prompt: bug in prompt overwrite itself
Allow user to override config options
This is why I started my own version, btw: https://github.com/cooljeanius/apple-gdb-1824 (although I've broken it and could use some help fixing it...) |
The old layout is difficult to maintain due to the size of gdbinit and the fact that it is difficult to identify various components. The file has now been broken up into multiple submodules which are loaded by the main gdbinit file. .gdb and .gdbinit has to be symbolically linked to the users home directory for this to work.