Developer forums (C::B DEVELOPMENT STRICTLY!) > Contributions to C::B
Debugger initialization commands to debug in wxWidgets
Feneck91:
--- Quote from: ollydbg on June 03, 2011, 05:09:37 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
--- End code ---
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)
--- End quote ---
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 ?
ollydbg:
--- Quote from: Feneck91 on June 03, 2011, 09:35:57 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.
--- End quote ---
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.
oBFusCATed:
--- Quote from: ollydbg on June 03, 2011, 09:42:53 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.
--- End quote ---
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.
ollydbg:
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;
}
--- End code ---
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
ollydbg:
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;
}
--- End code ---
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:
--- End code ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version