[M3devel] full paths to source files in debug info

Jay jayk123 at hotmail.com
Sun Mar 2 15:54:02 CET 2008


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 general
and 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.
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/20080302/f61627c5/attachment-0001.html>


More information about the M3devel mailing list