This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: display in ~/.gdbinit does not work
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Ente <ducksource at duckpond dot ch>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 28 May 2012 09:09:01 -0700
- Subject: Re: display in ~/.gdbinit does not work
- References: <4FBDF2D0.3050108@duckpond.ch> <4FBDF3C0.8090908@duckpond.ch>
> [SOLUTION]
> therefore a simple solution is to move the processing of the commands
> in the '~/.gdbinit' file to a point after the other command-line
> arguments have been processed.
The order in which each step is performed during the startup is
detailed in the GDB manual:
http://www.sourceware.org/gdb/current/onlinedocs/gdb/Startup.html#Startup
Changing that order can have unwanted side effects.
The fact of the matter is that your command does require a program
to be loaded before the $pc register becomes something that makes
sense to GDB.
Let's imagine for a second that you started GDB without argument.
Your ~/.gdbinit should still make sense for that situation too,
but it doesn't, because your display command cannot work.
You might be able to achieve what you want using command hooks,
although it might not always work - I don't know how the hooks
are implemented in practice. But take a look at:
http://www.sourceware.org/gdb/current/onlinedocs/gdb/Startup.html#Startup
Another option is to use the Python API to connect hook yourself
up to the events.new_objfile event, which would then allow you to
execute your "display" command when an executable is being loaded
in memory.
http://www.sourceware.org/gdb/current/onlinedocs/gdb/Events-In-Python.html#Events-In-Python
--
Joel