<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>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.<BR>
<BR>
I have now tested only changing m3front and the behavior is as I desire.<BR>
I put back parse.c and left m3front asis.<BR>
<BR>
And I believe has a good chance of satisfying everyone else.<BR>
<BR>
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.<BR>
<BR>
The two m3front implementation in question, are, given:<BR>
../src/Foo.m3 <BR>
../src/POSIX/FooPosix.m3 <BR>
<BR>
should gcc be given the paths<BR>
as show above <BR>
or <BR>
Foo.m3 <BR>
FooPosix.m3 <BR>
<BR>
Historically the answer was Foo.m3 and FooPosix.m3.<BR>
This does not lead to what I expect for an "easier" debugging experience (oxymoron?)<BR>
Changing to the ../src path does.<BR>
<BR>
As well I once tested setting a breakpoint by file and line number in gdb.<BR>
With ../src/foo.m3, you can still break on Foo.m3:123.<BR>
<BR>
ok?<BR>
<BR>
I did not check that given Foo.m3, if the symbols still have that directory path.<BR>
It is POSSIBLE that "wrecking" the source file path causes gcc to omit the directory name,<BR>
but I would be surprised.<BR>
<BR>
It is definitely possible to have gdb always check for "../src", however this isn't general<BR>
and I'm sure would not be accepted "upstream", and doesn't handle m3core, etc.<BR><BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> CC: m3devel@elegosoft.com<BR>> Date: Fri, 29 Feb 2008 13:19:43 -0800<BR>> From: mika@async.caltech.edu<BR>> Subject: Re: [M3devel] FW: put full paths to source files in debug info]<BR>> <BR>> "Rodney M. Bates" writes:<BR>> ...<BR>> >People can and often do move executables to different machines and also<BR>> >sometimes move source trees around on the original machine. Using simple<BR>> >file names within an executable (of which there is always exactly one)<BR>> >is invariant to all this, and a lot shorter to type/read.<BR>> ...<BR>> <BR>> Arbitrary paths are also not trustworthy on many Unix systems that run<BR>> automounters. The path you get from getcwd is likely not to be permanently<BR>> accessible on those. (You access the files via a different path.)<BR>> <BR>> Mika<BR><BR><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>