Author Topic: Debugger initialization commands to debug in wxWidgets  (Read 41632 times)

Offline Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
Debugger initialization commands to debug in wxWidgets
« on: June 01, 2011, 12:12:21 pm »
I have a projet with paths :
Quote
RootProjet
   |--------Application-----Debug
   |                            |--Release
   |--------MyProjet
   |--------wxWidgets-2.8.12
All compiled dll/exe/resouce (xrc)/translation(mo) are copied to Application/Debug (or release) by project post build steps
All is working fine.
WxWidgets is compiled with :
Code
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=debug VENDOR=%WX_WIDGETS_VENDOR_NAME% USE_XRC=1
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release VENDOR=%WX_WIDGETS_VENDOR_NAME% USE_XRC=1
The problem I have, is I cannot debug into wxWidgets source code, only inline code (into header only), all wxWidgets-2.8.12\src are not taken into account into the debugger.
How can I make gdb know where read source code of WxWidgets to be able to debug into this lib ?
I have see,  into settings/compiler and debugger/debugger setting that there is a Debugger initialization commands that should run command at gdb start. What kind of command should I put ? Like "source $(#wx)\src" ?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #1 on: June 02, 2011, 03:10:36 am »
which wxWidgets library did you link?
It should be a debug wx library.
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 Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
Re: Debugger initialization commands to debug in wxWidgets
« Reply #2 on: June 02, 2011, 08:22:48 am »
Of course I link with debug dynamic library.
I think it is a path problem, gdb doesn't found where src are loated. I'm trying to add :
Code
directory [i]"D:\Dev\TTGest\trunk\wxWidgets-2.8.12\lib\gcc_dll"[/i]
where the are compiled wxWidgets but no effect !
I know the source are located to "D:\Dev\TTGest\trunk\wxWidgets-2.8.12\src" When I write command
Code
info sources
I can see that all wxWidgets .cpp sources are located to "../../xxxxxxx"
The only thing that working is inline functions present into header files
Other idea ?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #3 on: June 02, 2011, 08:59:40 am »
I encountered the same problem before.
one solution is report the Debugger problem about the tracking into wxWidgets source

And the remaining problem: how to debug into wxwidget source code?

hope someone have other solutions. :D
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #4 on: June 02, 2011, 09:28:17 am »
The final explanation is from jens, see here:
Re: Debugger cannot open files
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 Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
Re: Debugger initialization commands to debug in wxWidgets
« Reply #5 on: June 02, 2011, 11:46:37 pm »
2 years and the problem is not solved  :(
If wxWidgets is compile as static library I know it's work but with dynamic library it's not work.
I cannot move my projects to another location because I'm using SVN and linking and compiling with :
My project: 
- TTGest.exe
Libraries :
- TTGestLib (dynamic library that contains engine of TTGest if one day I want to port to iPhone, only the GUI to write)
   + Need source of Lua because I use scripting into this software
   + Need wxSQLite3 + SQLite 3 for the database managment
- wxCAnsiPortETK : file transmission by socket using wxETK and CAnsiPort
- wxETK : (wxWidgets Extended Tool Kit) personnal lib that adding features to wxWidgets like log file / log window / CheckBoxListComboBox / Colored Gauge / Automaton & Socket automaton / HTTP managment
- CAnsiPort : C Ansi code based on C++ lib and STL implementing serialization, extended string, MD5 checksum, file and mem file managment

I's not really an "hello word" not really simple to move.
No way, ok I don't track source code into wxWidgets  :?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #6 on: June 03, 2011, 12:49:16 am »
This is a gdb problem. There is no way C::B to use "..\..\src\common\string.cpp:200", sorry.
Please report this problem to the GDB devs.

Another options is to modify the wx build commands to use fullpaths, I don't know if this is possible.
(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: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #7 on: June 03, 2011, 05:09:37 am »
This is a gdb problem. There is no way C::B to use "..\..\src\common\string.cpp:200", sorry.
Please report this problem to the GDB devs.

Another options is to modify the wx build commands to use fullpaths, I don't know if this is possible.

@obf, I found a way (maybe a workaround)

1, I build wxWidgets library my self, with the command:
Code
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=debug

2, now, I create a wx app project under C::B, which link to wx debug library.

3, now, debug the app, set a breakpoint in the app's source.
with the "step into" command, I can trace into the wx's source (both header files and cpp files)

4, If I use c::b to add a break point in wx's cpp source file, like(Note, c::b use absolute path to set a breakpoint)
Code
>>>>>>cb_gdb:
> break "D:/code/wxWidgets-2.8.12/src/common/string.cpp:158"
Then, gdb.exe will crash and showing a alert message box(application error)

5, If I add a break point manually, through the command below(send it from the debug-log edit control)
Code
 break ../../src/common/string.cpp:167
Breakpoint 2 at 0x66d89f57: file ../../src/common/string.cpp, line 167.
Then, this break point works and the app can stops there. But as this breakpoint is added manually, so debugger's breakpoint windows does not have a line about this breakpoint. But this "relative path breakpoint" works fine.

As a conclusion:
for debugging wx's source under Windows system
absolute path break point failed.
relative path break point works OK.


Is it possible that c::b can maintain a "relative path breakpoint", so we can smoothly debug the wx source under Windows. :D :D

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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #8 on: June 03, 2011, 08:39:04 am »
look at jens' reply
Re: GDB path problem
Quote
About the problem with the absolute path:
I played a little bit:
If a prgram is compiled with absolute paths, gdb also needs them and if you compile it with relative paths gdb only works if you set the bp with relative path, too.

So, currently, the debugger plugin always use an absolute path for a breakpoint. So, if the debugger plugin is smart enough, I mean for debugging the wx library which is build with relative paths, the debugger plugin need to generate the relative path breakpoint command, then our problem can solved nicely.  :D
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #9 on: June 03, 2011, 08:47:05 am »
Well, look at the screen below:


it seems the "relative path" is not correctly solved if I double click on the call stack entry.

I'm using a recently debugger branch nightly build.
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 Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
Re: Debugger initialization commands to debug in wxWidgets
« Reply #10 on: June 03, 2011, 09:35:57 am »
@obf, I found a way (maybe a workaround)

1, I build wxWidgets library my self, with the command:
Code
cd wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=debug

2, now, I create a wx app project under C::B, which link to wx debug library.

3, now, debug the app, set a breakpoint in the app's source.
with the "step into" command, I can trace into the wx's source (both header files and cpp files)
I have an application with debug mode linked with wxWidgets in debug too. If I use the step into from a wxWidgets source code it doesn't work if the source is a into a cpp file.
I didn't understand correctly your reply ?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #11 on: June 03, 2011, 09:42:53 am »
If I use the step into from a wxWidgets source code it doesn't work if the source is a into a cpp file.
It works here, I can step into the wx source. But I can't set a breakpoint on the wx's cpp source file through C::B. Because my wx debug library is build with relative source paths, but C::B always send break point command to gdb with absolute paths.


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 initialization commands to debug in wxWidgets
« Reply #12 on: June 03, 2011, 10:19:38 am »
It works here, I can step into the wx source. But I can't set a breakpoint on the wx's cpp source file through C::B. Because my wx debug library is build with relative source paths, but C::B always send break point command to gdb with absolute paths.
Works here, too, gdb 7.1.xx (I'm not really sure).

ollydbg: your conclusions about setting the breakpoints are correct, but as I said earlier setting relative path breakpoints from inside C::B won't be supported ever.
This is because there are too many ambiguities (what dir we make the path relative to?) and this is a gdb problem and should be fixed in gdb.
I think GDB devs know about it, but the info I've found was very scarce and I think they weren't sure how to fix it.
I have no time, nor energy to dig in their sources and fix it...

p.s. I would accept a patch with GUI improvements (related to setting breakpoint in a relative path) if someone is interested, to do it.
(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: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #13 on: June 07, 2011, 06:54:09 am »
take a time at how break point was added.
Mostly, in plugins\debuggergdb\debuggerstate.cpp

Code
/ The compiler now uses absolute paths to source files so we don't need
// any absolute->relative filename conversions here anymore.
// Just adjust the path separators...
wxString DebuggerState::ConvertToValidFilename(const wxString& filename)
{
    wxString fname = filename;
    fname.Replace(_T("\\"), _T("/"));
    return fname;
} // end of ConvertToValidFilename

//......


DebuggerBreakpoint* DebuggerState::AddBreakpoint(const wxString& file, int line, bool temp, const wxString& lineText)
{
    wxString bpfile = ConvertToValidFilename(file);

    // do we have a bp there?
    int idx = HasBreakpoint(bpfile, line);
    // if yes, remove old breakpoint first
    if (idx != -1)
        RemoveBreakpoint(idx, true);

    // create new bp
//    Manager::Get()->GetLogManager()->DebugLog(F(_T("DebuggerState::AddBreakpoint() : bp: file=%s, bpfile=%s"), file.c_str(), bpfile.c_str()));
    DebuggerBreakpoint* bp = new DebuggerBreakpoint;
    bp->type = DebuggerBreakpoint::bptCode;
    bp->filename = bpfile;
    bp->filenameAsPassed = file;
    bp->line = line;
    bp->temporary = temp;
    bp->lineText = lineText;
    bp->userData = FindProjectForFile(file);
    AddBreakpoint(bp);

    return bp;
}
So,  from the comments, I can see that the c::b developers did a absolute path -> relative path conversion before, and later, it was removed. :D
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5906
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #14 on: June 07, 2011, 07:10:04 am »
blame the file, I found an old revision use this kind of code:
Code
// when the project file is in a subdir, breaking with full filenames
// doesn't work.
// so we check this here and use the file's relative filename if possible.
wxString DebuggerState::ConvertToValidFilename(const wxString& filename)
{
    wxString fname = filename;
    fname.Replace(_T("\\"), _T("/"));

    cbProject* prj = Manager::Get()->GetProjectManager()->GetActiveProject();
    if (!prj)
        return fname;

    bool isAbsolute = false;
#ifdef __WXMSW__
    isAbsolute = (filename.GetChar(1) == _T(':')) ||
                filename.GetChar(0) == _T('/') ||
                filename.GetChar(0) == _T('\\');
#else
    isAbsolute = filename.GetChar(0) == _T('/') ||
                filename.GetChar(0) == _T('~');
#endif

    if (isAbsolute)
    {
        ProjectFile* pf = prj->GetFileByFilename(UnixFilename(filename), false, true);
        if (pf)
        {
            fname = pf->relativeFilename;
            fname.Replace(_T("\\"), _T("/"));
        }
        else
        {
        // for foreign files, we still should use a relative path
        //~ wxFileName f(filename);
        //~ f.MakeRelativeTo(prj->GetBasePath());
        //~ fname = f.GetFullPath();
        }
    }
    return fname;
}

So, I think if the absolute file path is:
see the debug log:

Code
> step
wxStringBase::InitWith (this=0x23f9b4, psz=0x41221c L"wxWidgets 2.8.12", nPos=0, nLength=4294967295) at ../../src/common/string.cpp:158
D:\code\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:158:4882:beg:0x66d89ef2
>>>>>>cb_gdb:

absolute file path
D:\code\wxWidgets-2.8.12\src\common\string.cpp
then we supply a base file path
D:\code\wxWidgets-2.8.12\build\msw
Then, we should give a relative file:
../../src/common/string.cpp

Is it easy to calculate? :D

By the way: from the debug log, you can see that the "step" command works fine.  :D



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.