News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

Debugger initialization commands to debug in wxWidgets

Started by Feneck91, June 01, 2011, 12:12:21 PM

Previous topic - Next topic

ollydbg

Ok, here is my hard-coded change to let setting break point on wxWidgets 's source.


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.

oBFusCATed

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!]

ollydbg

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.

ollydbg

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.

oBFusCATed

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!]

ollydbg

Quote from: oBFusCATed on June 09, 2011, 10:13:43 AM
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.

oBFusCATed

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!]

ollydbg

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

ollydbg

#23
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.
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.

oBFusCATed

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!]

ollydbg

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.

MortenMacFly

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: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

ollydbg

Quote from: MortenMacFly 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).
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.

ollydbg

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.

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.