[M3devel] full paths to source files in debug info

[Jay]

You do now get like:
 
 
#0  Thread__Fork (M3_EMTrVz_closure=0x7ff9ef58)    at ..\src\thread\WIN32\ThreadWin32.m3:653#1  0x643cc0d5 in FileBrowserVBT_M3 (M3_AcxOUs_mode=1)    at ..\src\lego\FileBrowserVBT.m3:942#2  0x6bcd840e in RTLinker__RunMainBody (M3_DjPxE3_m=0x64455c60)    at ../src/runtime/common/RTLinker.m3:399#3  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d840e20)    at ../src/runtime/common/RTLinker.m3:379#4  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d845480)    at ../src/runtime/common/RTLinker.m3:379#5  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d841d60)    at ../src/runtime/common/RTLinker.m3:379#6  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x4614e0)    at ../src/runtime/common/RTLinker.m3:379#7  0x6bcd7939 in RTLinker__AddUnitI (M3_DjPxE3_m=0x4614e0)    at ../src/runtime/common/RTLinker.m3:113#8  0x6bcd79c0 in RTLinker__AddUnit (M3_DjPxE5_b=0x44a4d3)whereas presumably before you would get:
 
 
#0  Thread__Fork (M3_EMTrVz_closure=0x7ff9ef58)    at ThreadWin32.m3:653#1  0x643cc0d5 in FileBrowserVBT_M3 (M3_AcxOUs_mode=1)    at FileBrowserVBT.m3:942#2  0x6bcd840e in RTLinker__RunMainBody (M3_DjPxE3_m=0x64455c60)    at RTLinker.m3:399#3  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d840e20)    at RTLinker.m3:379#4  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d845480)    at RTLinker.m3:379#5  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d841d60)    at RTLinker.m3:379#6  0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x4614e0)    at RTLinker.m3:379#7  0x6bcd7939 in RTLinker__AddUnitI (M3_DjPxE3_m=0x4614e0)    at RTLinker.m3:113#8  0x6bcd79c0 in RTLinker__AddUnit (M3_DjPxE5_b=0x44a4d3)
 
 ok?
 
I agree this medium level of verbosity in the ui is not useful.
The gain is that gdb finds the source files automatically.
 
 - Jay
 


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 2 Mar 2008 14:54:02 +0000Subject: [M3devel] full paths to source files in debug info


I probably only originally tested changes involving only parse.c, and then the final parse.c change with the m3front changes. I probably did not previously test only changing m3front. I have now tested only changing m3front and the behavior is as I desire.I put back parse.c and left m3front asis. And I believe has a good chance of satisfying everyone else. The assembly source does not have the full path to any FILE, but it does have the current working directory, or directory of the input *c file -- these are always the same and so it is ambiguous, and I didn't track down the code or try where they differ. The two m3front implementation in question, are, given:  ../src/Foo.m3   ../src/POSIX/FooPosix.m3  should gcc be given the paths  as show above or   Foo.m3   FooPosix.m3  Historically the answer was Foo.m3 and FooPosix.m3.This does not lead to what I expect for an "easier" debugging experience (oxymoron?)Changing to the ../src path does. As well I once tested setting a breakpoint by file and line number in gdb.With ../src/foo.m3, you can still break on Foo.m3:123. ok? I did not check that given Foo.m3, if the symbols still have that directory path.It is POSSIBLE that "wrecking" the source file path causes gcc to omit the directory name,but I would be surprised. It is definitely possible to have gdb always check for "../src", however this isn't generaland I'm sure would not be accepted "upstream", and doesn't handle m3core, etc. - Jay

> CC: m3devel at elegosoft.com> Date: Fri, 29 Feb 2008 13:19:43 -0800> From: mika at async.caltech.edu> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > "Rodney M. Bates" writes:> ...> >People can and often do move executables to different machines and also> >sometimes move source trees around on the original machine. Using simple> >file names within an executable (of which there is always exactly one)> >is invariant to all this, and a lot shorter to type/read.> ...> > Arbitrary paths are also not trustworthy on many Unix systems that run> automounters. The path you get from getcwd is likely not to be permanently> accessible on those. (You access the files via a different path.)> > Mika

Climb to the top of the charts! Play the word scramble challenge with star power. Play now! 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080303/f66c6dee/attachment-0002.html>