Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Contributions to C::B => Topic started by: Feneck91 on June 01, 2011, 12:12:21 pm

Title: Debugger initialization commands to debug in wxWidgets
Post by: Feneck91 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" ?
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg on June 02, 2011, 03:10:36 am
which wxWidgets library did you link?
It should be a debug wx library.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: Feneck91 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 ?
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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 (http://forums.codeblocks.org/index.php/topic,9792.msg68451.html#msg68451)

And the remaining problem: how to debug into wxwidget source code? (http://forums.codeblocks.org/index.php/topic,9744.msg68216.html#msg68216)

hope someone have other solutions. :D
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg on June 02, 2011, 09:28:17 am
The final explanation is from jens, see here:
Re: Debugger cannot open files (http://forums.codeblocks.org/index.php/topic,11546.msg78907.html#msg78907)
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: Feneck91 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  :?
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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

Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg on June 03, 2011, 08:39:04 am
look at jens' reply
Re: GDB path problem (http://forums.codeblocks.org/index.php/topic,9673.msg67923.html#msg67923)
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
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg on June 03, 2011, 08:47:05 am
Well, look at the screen below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2011-06-03143829.png)

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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: Feneck91 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 ?
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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.


Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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



Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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???
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed 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:
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=176636#c23)
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed on June 10, 2011, 02:39:03 pm
Unfortunately, I can't, I've not save the link. Sorry.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg on June 10, 2011, 04:23:14 pm
Ok, I also found that this post (http://forums.codeblocks.org/index.php/topic,13306.msg89692.html#msg89692) 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed on June 11, 2011, 10:08:30 am
No, I have no debug info in wxGTK. And I'm on windows :( at the moment.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: 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).
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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.
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: oBFusCATed 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 :)
Title: Re: Debugger initialization commands to debug in wxWidgets
Post by: ollydbg 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);
  }