Author Topic: some c::b/gdb file/path issues (encountered branch "splitting debugger in two")  (Read 10660 times)

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
The following encountered working with the splitting debugger in two branch, may be applicable to trunk as well, don't know.  (Didn't seem to find any references to this problem when searching for "pending breakpoint" c::b or gdb issues with google, within first few pages, so if its a known problem already, sorry.  One of them did give me the "objdump -dl" command that helped me see what seems to be going on in my case.  If there is a known resolution to this problem, please advise with solution.)

some c::b/gdb file/path issues

SUMMARY:
GDB is inconsistent in its return of path information between stack frame info requests and breakpoint/traps.

C::B cannot properly set breakpoints in files, and/or access files (from callstack window), in projects (wxwidgets) that involve relative path(segment)s, where the access involves a hybrid abs/rel path.

(some) POSSIBILITIES:
If GDB changes the callstack (path) info it returns to be consistent with breakpoint/trap operations, C::B would probably be able to access appropriate file from a callstack selection.  But, other GDB clients would probably now fail, so such a change probably needs to be subject to some option.

C::B needs some method of being able to set a breakpoint in a module it has opened (in the particular case as a result of a single-step into wxwidgets src/msw/timer.cpp) that GDB knows only by a hybrid abs/rel path, or GDB needs to try resolving such hybrid/abs paths into non-hybrid absolute paths for the purposes of breakpoint comparison (seems to me that would be a good idea, but is out of C::B control).

EXPLORATORY PROCESS:
stepping into (dynamic wxwidgets) module, gdb will return breakpoint/trap info with hybrid abs/rel path containing possibly relative segments, as in:
C:\dev\wxwidgets\wxWidgets-2.8.10\build\msw/../../src/msw/timer.cpp:130:3892:beg:0x627f341c

C::B will find and open that file.  If user then tries to set a breakpoint in that file, C::B tries to set the breakpoint with an absolutized path that does not contain the relative and other unnecessary segments, and FAILs.  Since the debugging info (apparently) does not contain an actual reference to such a path, it "pend"s the breakpoint - the debugging info contains the compilation directory, and the "filename" (which apparently can be a partial/relative path, try "objdump -dl wxmsw28u_gcc_custom.dll" where built with DEBUG_INFO=1), and creates the hybrid absolute/relative path by combining them, but does not match an absolutized path that has removed the (somewhat redundant, unnecessary) intervening path segments.  If one enters the breakpoint command directly into the debugger command line, such as "break ../../../src/msw/timer.c:134", then the debugger will find and set the breakpoint.  And the breakpoint set as such does seem to work.

Requesting a callstack, gdb returns, seemingly, only the "relativized" filename, which C::B hangs onto, and if you double-click on the callstack item, it appears that C::B tries to (maybe) "syncedit" against that file, and FAILS, because it doesn't have any idea where "../../../src/msw/timer.c" is.  Even though, it actually already has the file open, because of the previous trap that had returned the hybrid abs/rel path...

[edit]
environment:
winxp sp2
"gcc (TDM-2 mingw32) 4.4.1" from codelite (with mingw) 4189 version
wxwidgets 2.8.10 (built locally with above gcc, "mingw32-make -B -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 DEBUG_INFO=1")
codeblocks from splitting debugger in two branch (built with above gcc)
gdb 7.1, both from that codelite installation, and built locally (under non-codelite mingw installation) with same results
« Last Edit: September 14, 2010, 07:27:09 pm by cbexaminr »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Can you provide simple project where this behaviour can be easily reproduced?
(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 cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Oh you developers ;), always wanting scenarios simplified - you're already using codeblocks.

but oh well, the attached should also be familiar...  but it still requires (well maybe not, but that's how I've produced it), release builds of dynamic (dll) wxwidgets with symbols.

.......
context:

A project with the attached source as main content.  I built it withOUT unicode, but orig discovery was from C::B which I believe is unicode.

winxp sp2 (presumed generally irrelevant)

codelite revision 4189 installed (for the mingw-4.4.1 installation)

wxwidgets-2.8.10, built with above toolset, dos command prompt with path including:
path c:\MinGW-4.4.1\bin;c:\MinGW-4.4.1\mingw32\bin;c:\dev\wxwidgets\wxWidgets-2.8.10\lib\gcc_dll

command used to build wxwidgets:
mingw32-make -B -f makefile.gcc BUILD=release UNICODE=1 SHARED=1 MONOLITHIC=1 DEBUG_INFO=1
(may want to remove the -B if you have to restart - although wxwidgets is one of the few open source projects I recall getting to buiild out-of-box without problems)

wxpropgrid_debugger branch fetched and built (orig. with 10.05, set to use above 4.4.1, later with self set to use same)
codeblocks variables set to reference the mingw-4x above, and the locally built wxwidgets-2.8.10
(my current svn revision of that branch is at 6574 - it has my tipwindow experiments, but I believe they are irrelevant to this problem)

STEPS To Reproduce:

set breakpoint on call to HoverTimer.stop() in DataItem::ActivateItem(QVDIFrame *p_item) (panels.cpp:118)
start panels project
press "Hover test" button, then open the second level (from first '+'), should hit breakpoint
use "step into" operation, should step into the wxwidgets timer.c module - if step 'over' occurs, then prob. don't have symbols correctly available
step once more (just for good measure)
attempt to set a breakpoint on last active line of function, m_id = 0 ; //or something like that...
check debugger(debug) log, expect it will eventually report break point pending.
open debug/debugging windows/callstack
double-click on topmost item, should be referencing wxTimer::Stop() - expect to get error reporting unable to open the file

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Oh you developers ;), always wanting scenarios simplified - you're already using codeblocks.
Yes, on linux  :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 cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
FWIW, I've now also tried this with gdb-7.2.1 mingw32, and encountered the same problems.

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Well, poking at this a bit further, I now believe the way gdb handles its canonicalization of paths is not the most reliable approach for all platforms.

It appears to try to canonicalize them according to the platform its hosted on.  Unfortunately, in the case of windows, the canonical paths are not the only legitimate absolute paths, (basically, the difference between \ and /.)  And, codeblocks on windows, appears to construct its paths, at least those passed to gdb, with (forward) /'s.

I'm not sure of the depth of the problem, but some code I've hacked together in the (gdb) source.c/openp() routine, to perform 'internal' conversion of hybrid paths to absolute with all '/', results in my being able to set breakpoints from the codeblocks editor without having them pend(ing).  With the exception of one (breakpoint'd) line that appears to have an incorrect address locatiion, the breakpoints will trigger.  (So I currently assume there's something funky about that particular liine in the debug info, or something about the code generated.)

Even if codeblocks were to reverse the path segment separators it uses on windows from / to \, I don't know if that would help - I'm not sure gdb necessarily always attempts and achieves its (previously existing) internal conversions (by the point where I've hacked), and thus might still miss finding the paths passed by C::B...  I suspect such failure, because the paths I see passed back to c::b don't appear to have been corrected, at points that I think they should have been (i.e. not at all), suggesting there's some early exit from some of the paths in gdb's gdb_realpath() and xfullpath(), before its actually converted.

The path to a solution currently seems to be unpleasantly covered with thorns...

[edit: some of that is actually handled by routines in libiberty.]
« Last Edit: September 18, 2010, 02:20:48 am by cbexaminr »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Probably a better place to discuss the internals of gdb is the gdb's mailing list, here we could not help you much, unfortunately :(
(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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
@cbexaminr
Just a reminder, I found the same issue, with the relative path and absolute path problem.

see:
Re: Debugger initialization commands to debug in wxWidgets

and hopefully, it can be fixed :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.