<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>You do now get like:<BR>
<BR>
<BR>
#0 Thread__Fork (M3_EMTrVz_closure=0x7ff9ef58)<BR> at ..\src\thread\WIN32\ThreadWin32.m3:653<BR>#1 0x643cc0d5 in FileBrowserVBT_M3 (M3_AcxOUs_mode=1)<BR> at ..\src\lego\FileBrowserVBT.m3:942<BR>#2 0x6bcd840e in RTLinker__RunMainBody (M3_DjPxE3_m=0x64455c60)<BR> at ../src/runtime/common/RTLinker.m3:399<BR>#3 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d840e20)<BR> at ../src/runtime/common/RTLinker.m3:379<BR>#4 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d845480)<BR> at ../src/runtime/common/RTLinker.m3:379<BR>#5 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d841d60)<BR> at ../src/runtime/common/RTLinker.m3:379<BR>#6 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x4614e0)<BR> at ../src/runtime/common/RTLinker.m3:379<BR>#7 0x6bcd7939 in RTLinker__AddUnitI (M3_DjPxE3_m=0x4614e0)<BR> at ../src/runtime/common/RTLinker.m3:113<BR>#8 0x6bcd79c0 in RTLinker__AddUnit (M3_DjPxE5_b=0x44a4d3)<BR><BR><BR>whereas presumably before you would get:<BR>
<BR>
<BR>
#0 Thread__Fork (M3_EMTrVz_closure=0x7ff9ef58)<BR> at ThreadWin32.m3:653<BR>#1 0x643cc0d5 in FileBrowserVBT_M3 (M3_AcxOUs_mode=1)<BR> at FileBrowserVBT.m3:942<BR>#2 0x6bcd840e in RTLinker__RunMainBody (M3_DjPxE3_m=0x64455c60)<BR> at RTLinker.m3:399<BR>#3 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d840e20)<BR> at RTLinker.m3:379<BR>#4 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d845480)<BR> at RTLinker.m3:379<BR>#5 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x6d841d60)<BR> at RTLinker.m3:379<BR>#6 0x6bcd82d6 in RTLinker__RunMainBody (M3_DjPxE3_m=0x4614e0)<BR> at RTLinker.m3:379<BR>#7 0x6bcd7939 in RTLinker__AddUnitI (M3_DjPxE3_m=0x4614e0)<BR> at RTLinker.m3:113<BR>#8 0x6bcd79c0 in RTLinker__AddUnit (M3_DjPxE5_b=0x44a4d3)<BR>
<BR>
ok?<BR>
<BR>
I agree this medium level of verbosity in the ui is not useful.<BR>
The gain is that gdb finds the source files automatically.<BR>
<BR>
- Jay<BR>
<BR><BR> <BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Date: Sun, 2 Mar 2008 14:54:02 +0000<BR>Subject: [M3devel] full paths to source files in debug info<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass EC_body.hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
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=EC_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=_blank>Play now!</A> </BLOCKQUOTE><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>