Author Topic: debugger plugin feature request about the initial command of GDB  (Read 23728 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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
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
gdb --data-directory=$(TARGET_COMPILER_DIR)/share/gdb

But I found that currently, the GDB start command is hard coded in file:
Code
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
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
--data-directory=$(TARGET_COMPILER_DIR)/share/gdb

thanks.
« Last Edit: August 08, 2011, 10:15:44 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin feature request about the initial command of GDB
« Reply #1 on: August 08, 2011, 10:10:29 am »
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).
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin feature request about the initial command of GDB
« Reply #2 on: August 08, 2011, 10:19:41 am »
the stl pretty printer for 4.6.1 under Windows is installed in:
Code
MinGW_gcc4.6.1release_static_win32\share\gcc-4.6.1\python\libstdcxx

Also, the gdb command support python scripts is installed in:
Code
MinGW_gcc4.6.1release_static_win32\share\gdb\python\gdb


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline reckless

  • Regular
  • ***
  • Posts: 338
Re: debugger plugin feature request about the initial command of GDB
« Reply #3 on: August 08, 2011, 03:45:39 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin feature request about the initial command of GDB
« Reply #4 on: August 08, 2011, 04:39:51 pm »
reckless: I'm not sure I've understand the second part of your post...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: debugger plugin feature request about the initial command of GDB
« Reply #5 on: August 08, 2011, 05:15:40 pm »
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
PathToMinGW\bin
and the python script was located under
Code
PathToMinGW\share\gdb

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


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: debugger plugin feature request about the initial command of GDB
« Reply #6 on: August 08, 2011, 06:20:58 pm »
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
PathToMinGW\bin
and the python script was located under
Code
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin feature request about the initial command of GDB
« Reply #7 on: August 08, 2011, 06:31:35 pm »
Yes, I'll add an option, but I guess it won't happen soon.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin feature request about the initial command of GDB
« Reply #8 on: August 08, 2011, 06:34:17 pm »
BTW: have you tried this command: "set data-directory" http://sourceware.org/gdb/onlinedocs/gdb/Data-Files.html ?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline reckless

  • Regular
  • ***
  • Posts: 338
Re: debugger plugin feature request about the initial command of GDB
« Reply #9 on: August 08, 2011, 07:37:05 pm »
Quote
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.

Offline xunxun

  • Almost regular
  • **
  • Posts: 187
Re: debugger plugin feature request about the initial command of GDB
« Reply #10 on: August 09, 2011, 01:17:01 pm »
I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:
Code
set data-directory E:\MyPack\MinGW\share\gdb
Then gdb will use this data directory.
Regards,
xunxun

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: debugger plugin feature request about the initial command of GDB
« Reply #11 on: August 09, 2011, 02:13:58 pm »
I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:
Code
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.


Offline xunxun

  • Almost regular
  • **
  • Posts: 187
Re: debugger plugin feature request about the initial command of GDB
« Reply #12 on: August 09, 2011, 02:31:23 pm »
I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:
Code
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.
Regards,
xunxun

Offline xunxun

  • Almost regular
  • **
  • Posts: 187
Re: debugger plugin feature request about the initial command of GDB
« Reply #13 on: August 09, 2011, 02:43:57 pm »
I have an another method.
Create a new file named ".gdbinit" at the gdb.exe directory.
Content:
Code
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.
Regards,
xunxun

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: debugger plugin feature request about the initial command of GDB
« Reply #14 on: August 09, 2011, 02:46:55 pm »
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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]