debugger plugin feature request about the initial command of GDB

[ollydbg]

Under Windows, it seems the GDB can't find it's mingw/share/gdb files, so as a workaround, I would like to start gdb using this command:

Code Select Expand


gdb --data-directory=e:/test/unix_gdb/install/mingw/share/gdb

the above code will tell gdb that absolute path of "share/gdb", currently, if you install a more recent G++ or GDB, you will find that under "share/gdb", there are python pretty printres for "std c++ library" and the "gdb command support for pretty printer".

In Codelblocks, we have no such way to run GDB, There is a "debugger initializtion commands" edit control, but it can't set the parameters when gdb started. what I want is something like:

Code Select Expand


gdb --data-directory=$(TARGET_COMPILER_DIR)/share/gdb


But I found that currently, the GDB start command is hard coded in file:

Code Select Expand

wxString GDB_driver::GetCommandLine(const wxString& debugger, const wxString& debuggee)
{
   wxString cmd;
   cmd << debugger;
   cmd << _T(" -nx");          // don't run .gdbinit
   cmd << _T(" -fullname ");   // report full-path filenames when breaking
   cmd << _T(" -quiet");       // don't display version on startup
   cmd << _T(" -args ") << debuggee;
   return cmd;
}

wxString GDB_driver::GetCommandLine(const wxString& debugger, int pid)
{
   wxString cmd;
   cmd << debugger;
   cmd << _T(" -nx");          // don't run .gdbinit
   cmd << _T(" -fullname ");   // report full-path filenames when breaking
   cmd << _T(" -quiet");       // don't display version on startup
   cmd << _T(" -pid=") << wxString::Format(_T("%d"), pid);
   return cmd;
}

So, is it possible to add an extra option on the start up command??

such as:

Code Select Expand

wxString GDB_driver::GetCommandLine(const wxString& debugger, const wxString& debuggee)
{
   wxString cmd;
   cmd << debugger;
   cmd << _T(" -nx");          // don't run .gdbinit
   cmd << _T(" -fullname ");   // report full-path filenames when breaking
   cmd << _T(" -quiet");       // don't display version on startup
   cmd << extraStartupCommand; //************************************
   cmd << _T(" -args ") << debuggee;
   return cmd;
}

Then, I would simply add extraStartupCommand with below string

Code Select Expand

--data-directory=$(TARGET_COMPILER_DIR)/share/gdb

thanks.

[oBFusCATed]

As far as I know the correct place for the pretty printers is next to the headers of the stl.
Also I think after gcc 4.5 the pretty printers are included with the stl distribution (at least on linux).

[ollydbg]

the stl pretty printer for 4.6.1 under Windows is installed in:

Code Select Expand

MinGW_gcc4.6.1release_static_win32\share\gcc-4.6.1\python\libstdcxx

Also, the gdb command support python scripts is installed in:

Code Select Expand

MinGW_gcc4.6.1release_static_win32\share\gdb\python\gdb

[reckless]

the reason is that gdb expects a posix emultion shell eg. bash or sh to get its environment. in say msys or cygwin shell it works mostly (allthough i had a few problems with some projects under msys).

most gnu utils use getenv("somepath") to get there install location but getenv does not work under a windows environment instead you need to put the files in the same dir as gdb eg c:\gdb\gdb.exe\share\gdb files. or if the files are in lib then its c:\gdb\lib\gdb files. an example of the directory structure for windows use can be seen in the xmms2 project. its some times different than what i explained so you need to expperiment a bit.

[oBFusCATed]

reckless: I'm not sure I've understand the second part of your post...

[ollydbg]

Yes, gdb was not friendly handle windows style path.
I have manually hack the GDB's source code, and adjust the "data-directory" under Win32.  Now, it works OK.

I suppose that we have such file structure
gdb executable is located under:

Code Select Expand

PathToMinGW\bin
and the python script was located under

Code Select Expand

PathToMinGW\share\gdb

the patch can be found in gdb2011-08-08.patch, it includes other windows path handling problem fix.

[ironhead]

Yes, gdb was not friendly handle windows style path.
I have manually hack the GDB's source code, and adjust the "data-directory" under Win32.  Now, it works OK.

I suppose that we have such file structure
gdb executable is located under:

Code Select Expand

PathToMinGW\bin
and the python script was located under

Code Select Expand

PathToMinGW\share\gdb

the patch can be found in gdb2011-08-08.patch, it includes other windows path handling problem fix.

This fixes the issue, but it's getting to the point where gdb (at least for windows) needs to be heavily customized to play nice with C::B.  Wouldn't an option also be to make the start command for the debugger configurable (or at least allow additional parameters), as per ollydbg's original post?

[oBFusCATed]

Yes, I'll add an option, but I guess it won't happen soon.

[oBFusCATed]

BTW: have you tried this command: "set data-directory" http://sourceware.org/gdb/onlinedocs/gdb/Data-Files.html ?

[reckless]

reckless: I'm not sure I've understand the second part of your post...

just trying to explain how it could be made to work without hacking the code most times if not in a posix shell i found that the tools could be made to work if i moved the folders containing data to where the executable is.

[xunxun]

I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:

Code Select Expand


set data-directory E:\MyPack\MinGW\share\gdb

Then gdb will use this data directory.

[ironhead]

I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:

Code Select Expand


set data-directory E:\MyPack\MinGW\share\gdb

Then gdb will use this data directory.

Unfortunately this won't help due to how gdb is started within C::B.  As per ollydbg's original post, gdb is started with "-nx" meaning .gdbinit is not sourced.

[xunxun]

I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:

Code Select Expand


set data-directory E:\MyPack\MinGW\share\gdb

Then gdb will use this data directory.

Unfortunately this won't help due to how gdb is started within C::B.  As per ollydbg's original post, gdb is started with "-nx" meaning .gdbinit is not sourced.

so we can use the command ：
gdb -ex "set data-directory e:\mypack\mingw\share\gdb"
？
but I try to use "info pretty-printer", and this doesn't work.

[xunxun]

I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:

Code Select Expand


set data-directory E:\MyPack\MinGW\share\gdb

Then gdb will use this data directory.

Unfortunately this won't help due to how gdb is started within C::B.  As per ollydbg's original post, gdb is started with "-nx" meaning .gdbinit is not sourced.

so we can use the command ：
gdb -ex "set data-directory e:\mypack\mingw\share\gdb"
？
but I try to use "info pretty-printer", and this doesn't work.

I test this, this method can modify the gdb's data directory, but not python's.

[oBFusCATed]

Unfortunately this won't help due to how gdb is started within C::B.  As per ollydbg's original post, gdb is started with "-nx" meaning .gdbinit is not sourced.

You can source ~/.gdbinit manually.
You can even import the pretty printers manually.
This is what I was doing not long ago.

so we can use the command ：
gdb -ex "set data-directory e:\mypack\mingw\share\gdb"

Why would you do this instead of passing --data-dir?