Author Topic: Debugger initialization commands to debug in wxWidgets  (Read 24528 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: [Select]
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: 5219
  • 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: [Select]
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: [Select]
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: 5219
  • 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: 5219
  • 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  :?

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • 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: 5219
  • 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: [Select]
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: [Select]
>>>>>>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: [Select]
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: 5219
  • 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: 5219
  • 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: [Select]
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: 5219
  • 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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • 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: 5219
  • 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: [Select]
/ 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: 5219
  • 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: [Select]
// 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: [Select]
> 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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #15 on: June 07, 2011, 08:15:45 am »
Ok, here is my hard-coded change to let setting break point on wxWidgets 's source.

Code: [Select]
wxString DebuggerState::ConvertToValidFilename(const wxString& filename)
{
    wxString fname;

    if( filename.StartsWith(_T("D:\\code\\wxWidgets-2.8.12"))
       && filename.EndsWith(_T(".cpp")))
    {
        wxFileName f(filename);
        wxString base = _T("D:\\code\\wxWidgets-2.8.12\\build\\msw");
        f.MakeRelativeTo(base);
        fname = f.GetFullPath();
    }
    else
        fname = filename;

    fname.Replace(_T("\\"), _T("/"));
    return fname;
} // end of ConvertToValidFilename

So, the final step is: If we supply database which contains all the candidate "base" file paths, we can solve the problem. :D
Any ideas???
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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #16 on: June 07, 2011, 08:46:29 am »
My idea was to provide a GUI for setting relative path breakpoints.
Example steps:
1. set the breakpoint by clicking in the margin
2. right click in on the dot
3. a menu is shown with option: make relative
4. clicking this option shows a dialog or submenus with all the available paths or option to add new one
5. you choose a path and this path is used to calculate the relative path for the breakpoint

Forget about your idea of a database and such hacky staff!!!!!

p.s. the best solution is to hack gdb and add support for such breakpoints. Ollydbg I know you have some understanding of gdb internals.  :lol:
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #17 on: June 07, 2011, 02:04:43 pm »
I would like to help, but just not sure I can implement those things. That's seems a little complex.
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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #18 on: June 09, 2011, 08:22:16 am »
It seems under linux, the gdb can do very good job on both relative and absolute paths, so I guess this is only a Windows issue.
See more details on:
Comment 23
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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #19 on: June 09, 2011, 10:13:43 am »
Yes, windows only issue it is.
There is a message on GDB's mail list about the problem (the message is 2006 or older), but nothing have been done.
Olly if you're interested in this being fixed, please talk to the GDB guys and see what they will say.
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #20 on: June 10, 2011, 01:53:55 pm »
There is a message on GDB's mail list about the problem (the message is 2006 or older), but nothing have been done.
Can you show me the link? I would like to see this message, thanks.
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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #21 on: June 10, 2011, 02:39:03 pm »
Unfortunately, I can't, I've not save the link. Sorry.
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #22 on: June 10, 2011, 04:23:14 pm »
Ok, I also found that this post has some analysis on gdb source.
I just dig into the gdb source and found that in the file "symtab.c" and in function:
Code: [Select]
/* Check for a symtab of a specific name; first in symtabs, then in
   psymtabs.  *If* there is no '/' in the name, a match after a '/'
   in the symtab filename will also work.  */

struct symtab *
lookup_symtab (const char *name)
{
...


I will report to gdb maillist about this issue. Hopefully some one interests in gdb can look into it.
thanks.
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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #23 on: June 11, 2011, 08:23:29 am »
Here is my research on setting breakpoint:
Quote
info sources
Source files for which symbols have been read in:
E:\code\cb\test_code\debug_wx_library\debug_wx_libraryMain.cpp, E:/code/cb/wx/wxWidgets-2.8.12/include/wx/generic/textdlgg.h,
...
e:/code/cb/gcc/mingw_gcc4.5.4.20110428_static_win32/mingw/bin/../lib/gcc/i686-pc-mingw32/4.5.4/include/c++/i686-pc-mingw32/bits/gthr-default.h,
E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../include/wx/filefn.h, E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../include/wx/filename.h,
...
Source files for which symbols will be read in on demand:

../.././libgcc/../gcc/gthr-win32.h,

...

E:/code/cb/wx/wxWidgets-2.8.12/include/wx/list.h, E:/code/cb/wx/wxWidgets-2.8.12/include/wx/object.h,
...
../../include/wx/vector.h, ../../include/wx/clntdata.h,

...

../../src/richtext/richtextstylepage.cpp,
...


then set breakpoint using several method:
Quote
>>>>>>cb_gdb:
> b "../../include/wx/spinbutt.h:20"
Breakpoint 2 at 0x67109942: file ../../include/wx/spinbutt.h, line 40. (3 locations)
>>>>>>cb_gdb:
> b "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/string.cpp:161"
Breakpoint 3 at 0x66d89efd: file ../../src/common/string.cpp, line 161.
>>>>>>cb_gdb:
> b "../../src/common/string.cpp:161"
Breakpoint 4 at 0x66d89efd: file ../../src/common/string.cpp, line 161.
>>>>>>cb_gdb:
> b "E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp:164"
No source file named E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp.
Breakpoint 5 ("E:\code\cb\wx\wxWidgets-2.8.12\src/common/string.cpp:164) pending.
>>>>>>cb_gdb:
> b "../../src/common/datetime.cpp:100"
Breakpoint 6 at 0x66d47ba5: file ../../src/common/datetime.cpp, line 100.
>>>>>>cb_gdb:
> b "E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp:101"

the strange thing is:
setting a break point using:
"E:\code\cb\wx\wxWidgets-2.8.12\build\msw/../../src/common/datetime.cpp:101"
works.
This is not an normal absolute path.

@obf, can you show me the same thing on linux? thanks.
« Last Edit: June 11, 2011, 08:35:01 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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #24 on: June 11, 2011, 10:08:30 am »
No, I have no debug info in wxGTK. And I'm on windows :( at the moment.
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #25 on: June 12, 2011, 09:51:05 am »
I have dig into the gdb source, and found the reason, but I'm not sure I can fix it.
See the more details in both MinGw maillist and gdb mailist. (different peoples there).

Hope some one can help to solve this issue.

see:
http://sourceware.org/ml/gdb/2011-06/msg00079.html
and
http://sourceforge.net/mailarchive/forum.php?thread_name=4DF4513A.3090902%40gmail.com&forum_name=mingw-users
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: Debugger initialization commands to debug in wxWidgets
« Reply #26 on: June 12, 2011, 11:57:54 am »
Just for the record (actually for my understanding): This bug is only for 3rd party sources like wxWidgets that are not effected by the advanced compiler switch "UseFullSourcePaths", right? Because we did this to have compiled the full source path's in as a GDB workaround for own sources (i.e. the once of your project).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #27 on: June 12, 2011, 12:08:41 pm »
Just for the record (actually for my understanding): This bug is only for 3rd party sources like wxWidgets that are not effected by the advanced compiler switch "UseFullSourcePaths", right? Because we did this to have compiled the full source path's in as a GDB workaround for own sources (i.e. the once of your project).
Yes, the issue only happens when debugging the wx library. (the wx library was build from make -f makfile.gcc , and has relative source paths embedded in the dll).

In other cases, c::b use full paths, so we don't have such issue.
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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #28 on: June 14, 2011, 05:20:51 am »
FYI:
I found that gdb internally can locates any symbol source file, but it just do not do a canonization on the returned string.
See my research on
http://sourceware.org/ml/gdb/2011-06/msg00099.html
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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #29 on: June 14, 2011, 07:28:57 am »
Great news!!!

I have solved the setting breakpoint problem, look at the patch in:

http://sourceware.org/ml/gdb/2011-06/msg00102.html

 :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.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11777
    • Travis build status
Re: Debugger initialization commands to debug in wxWidgets
« Reply #30 on: June 14, 2011, 08:32:08 am »
Lets see if they approve it and you have the nerves to fill in the FSF Copyright assignment :)
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger initialization commands to debug in wxWidgets
« Reply #31 on: June 15, 2011, 04:16:18 am »
Lets see if they approve it and you have the nerves to fill in the FSF Copyright assignment :)
Aha, indeed nerves :D.

By the way, I have create another patch to let the backtrace showing the full file name when debugging wx debug library. This way, it can fix the problem I post here: http://forums.codeblocks.org/index.php/topic,14792.msg99218.html#msg99218

see:
Quote
> bt 30
#0  test_debug_wx_libFrame::OnAbout (this=0xb77570, event=...) at f:\cb\test_code\test_debug_wx_lib\test_debug_wx_libmain.cpp:103
#1  0x66d41acc in wxAppConsole::HandleEvent (this=0xb69fa0, handler=0xb77570, func=(void (wxEvtHandler::*)(wxEvtHandler * const, wxEvent &)) 0x401e66 <test_debug_wx_libFrame::OnAbout(wxCommandEvent&)>, event=...) at d:\code\wxwidgets-2.8.12\src\common\appbase.cpp:322
#2  0x66dc1107 in wxEvtHandler::ProcessEventIfMatches (entry=..., handler=0xb77570, event=...) at d:\code\wxwidgets-2.8.12\src\common\event.cpp:1239
#3  0x66dc1734 in wxEvtHandler::SearchDynamicEventTable (this=0xb77570, event=...) at d:\code\wxwidgets-2.8.12\src\common\event.cpp:1421
#4  0x66dc12ad in wxEvtHandler::ProcessEvent (this=0xb77570, event=...) at d:\code\wxwidgets-2.8.12\src\common\event.cpp:1297
#5  0x66e7be55 in wxFrameBase::ProcessCommand (this=0xb77570, id=101) at d:\code\wxwidgets-2.8.12\src\common\framecmn.cpp:224
#6  0x66e248f8 in wxFrame::HandleCommand (this=0xb77570, id=101, cmd=0, control=0x0) at d:\code\wxwidgets-2.8.12\src\msw\frame.cpp:974
#7  0x66e24c1e in wxFrame::MSWWindowProc (this=0xb77570, message=273, wParam=101, lParam=0) at d:\code\wxwidgets-2.8.12\src\msw\frame.cpp:1051
#8  0x66e05ad6 in wxWndProc (hWnd=0x12052c, message=273, wParam=101, lParam=0) at d:\code\wxwidgets-2.8.12\src\msw\window.cpp:2618
#9  0x7e418724 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#10 0x0012052c in ?? ()
#11 0x00000111 in ?? ()
warning: (Internal error: pc 0x110 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x110 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x110 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x64 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x64 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x64 in read in psymtab, but not in symtab.)
#12 0x00000065 in ?? ()
#13 0x00000000 in ?? ()
>>>>>>cb_gdb:
Now, double click on the call stack window will open the associated wx source file.

here is the patch
Code: [Select]
569a0e63c18e2fe9dfa82e7feaf51b191669ded4
 gdb/stack.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/gdb/stack.c b/gdb/stack.c
index 0888b69..9635e57 100644
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -835,15 +835,21 @@ print_frame (struct frame_info *frame, int print_level,
   ui_out_text (uiout, ")");
   if (sal.symtab && sal.symtab->filename)
     {
+      const char *fullname;
       annotate_frame_source_begin ();
       ui_out_wrap_hint (uiout, "   ");
       ui_out_text (uiout, " at ");
       annotate_frame_source_file ();
-      ui_out_field_string (uiout, "file", sal.symtab->filename);
-      if (ui_out_is_mi_like_p (uiout))
- {
-  const char *fullname = symtab_to_fullname (sal.symtab);
+      
 
+ fullname = symtab_to_fullname (sal.symtab);
+        if (fullname != NULL)
+           ui_out_field_string (uiout, "file", fullname);
+        else
+           ui_out_field_string (uiout, "file", sal.symtab->filename);
+        
+        if (ui_out_is_mi_like_p (uiout))
+ {
   if (fullname != NULL)
     ui_out_field_string (uiout, "fullname", fullname);
  }
« Last Edit: June 15, 2011, 04:19:11 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.