<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>> ...debugger itself with the debug info as it was. It<SPAN class=EC_Apple-converted-space> </SPAN>already<BR>> > contained one copy of the full path to the source file in each<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > object file, though I don't know of a place the debugger uses this now.<BR><BR>btw, I don't think this part is true.<BR>
I don't believe the object files contain full source paths anywhere.<BR>
But oops, I admit I didn't open the .ms or .mo files and double check that.<BR>
However, "the way it works", where "it" is the little bit of code I looked at,<BR>
is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that<BR>
path was passed in to gcc.<BR>
 <BR>
My experience with gdb strongly suggests that this sort of path is the only<BR>
one in the debug info.<BR>
 <BR>
I will check more stuff tonight, the behavior of __FILE__, the behavior of gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the behavior of emacs+gdb (yet another learning curve..man, being low in the callstack requires familiarity with everyone's workflow above you..)<BR>
 <BR>
I wonder as well if a list of directories can be put in the debug info.<BR>
You know, partly as a size optimization, and possibly to address these issues.<BR>
  (of course the size optimization could be independently implemented)<BR>
When I stepping, I don't really need gdb to show me the full path, that is often but not always noise, I just need it to know the full path so it can show the source. As things were, gdb wouldn't find source without dir commands.<BR>
 <BR>
Command line debuggers are quite daunting.<BR>
I don't know if it is worthwhile to strive to reduce the fear and pain they cause, or just suck it all up because you'll hardly make much of a dent anyway. ?<BR>
 <BR>
 - Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
CC: rodney.bates@wichita.edu; m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jayk123@hotmail.com<BR>Subject: Re: [M3devel] FW: put full paths to source files in debug info]<BR>Date: Thu, 28 Feb 2008 22:01:42 -0500<BR><BR>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV>On Feb 28, 2008, at 8:01 PM, Jay wrote:</DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV>
<DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?<BR>What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself.<BR> <BR>Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.<BR>As is setting them by full name PosixProcess__WaitProcess.<BR>That is what I "always" do ("always" as in, I just started using gdb a few weeks ago).<BR> <BR>What I could imagine is affected is setting them by file and line number.<BR>Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?<BR>Maybe it depends. I should try out xcode and ddd and such?<BR> <BR>Do people say like break foo.c:#123? And now I've made them use a full path?</DIV></SPAN></BLOCKQUOTE>
<DIV><BR class=EC_webkit-block-placeholder></DIV>
<DIV>Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Gdb doesn't have any fuzzy matching?</DIV></SPAN></BLOCKQUOTE>
<DIV><BR class=EC_webkit-block-placeholder></DIV>Not sure.</DIV>
<DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Maybe in gcc I can give multiple file names?</DIV></SPAN></BLOCKQUOTE>
<DIV><BR class=EC_webkit-block-placeholder></DIV>
<DIV>Again, not sure.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">This really greatly improves the out-of-the-box minimally configured debugging experience.<BR>Gdb automatically shows me the source as I step, instead of just file name and line number.<BR>cdb/windbg at least show disassembly by default, but gdb doesn't, so by default gdb was showing hardly anything at all, quite poor. I admit, I'm at the start of the learning curve on gdb. I had to look to find the dir command. I had to look to find display/x $pc. To use the dir command, I have to constantly switch my slashes, since I get the paths from dir /s/b.</DIV></SPAN></BLOCKQUOTE>
<DIV><BR class=EC_webkit-block-placeholder></DIV>
<DIV>I use gdb under emacs...  if the emacs bindings continue to work then OK, but if not then problems.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">I will make it a switch in cm3 and cm3cg if it is really a problem.<BR> <BR>In C it is a common idiom:<BR>void assert_failed(const char* condition, const char* file, unsigned line);<BR>#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0)<BR> <BR>__FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation.<BR> <BR>Also:<BR>printf("foo is %d in %s\n", foo, __FILE__).<BR> <BR>This really just seems like basic correctness to me, to give a debugger full paths.<BR>I'm quite surprised by the pushback.</DIV></SPAN></BLOCKQUOTE>
<DIV><BR class=EC_webkit-block-placeholder></DIV>
<DIV>I look forward to Rodney's input since he has most experience with m3gdb and its expectations, and moreover with the current behavior of gdb for other languages.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available..<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_stopSpelling>
<BR>> From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:rodney.bates@wichita.edu">rodney.bates@wichita.edu</A><BR>> Date: Thu, 28 Feb 2008 14:12:33 -0500<BR>> CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> Subject: Re: [M3devel] FW: put full paths to source files in debug info]<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> I concur with Rodney on this. There are deeper issues here than<SPAN class=EC_Apple-converted-space> </SPAN><BR>> simply avoiding the need to use dir in gdb.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> ><BR>> > I don't understand what the need for these paths is. In every<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > complete<BR>> > program, all the interfaces and all the modules must have unique<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > simple<BR>> > names, otherwise code could not refer to them. With the filename<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > matchup<BR>> > rules, this should make all the simple file names unique too. So any<BR>> > debug commands should never need a path. And using simple names<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > avoids<BR>> > the problems of moving compiled code.<BR>> ><BR>> > Is it more output from the debugger you want? If so, this could no<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > doubt<BR>> > be done by the debugger itself with the debug info as it was. It<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > already<BR>> > contained one copy of the full path to the source file in each<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > object file,<BR>> > though I don't know of a place the debugger uses this now.<BR>> ><BR>> > Yes, I know the filename/modulename rules don't actually apply for<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > modules,<BR>> > but not following them is a bad practice. I've been around that<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > block many<BR>> > times with Ada, and believe me, it's a nightmare. Furthermore, then<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > you<BR>> > wouldn't be able to name things in the debugger as<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > ModuleName.VarOrProcInModule,<BR>> > This construct does not exist in code but is very useful in<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > debugging, especially<BR>> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > exports >1<BR>> > interface, etc.<BR>> ><BR>> > Jay wrote:<BR>> >> truncated again! and possibly misformated..<BR>> >><SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> ------------------------------------------------------------------------<BR>> >> From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</A><BR>> >> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> >> Subject: RE: put full paths to source files in debug info<BR>> >> Date: Thu, 28 Feb 2008 08:44:11 +0000<BR>> >> pps: "webinfo" (Reactor?) and assertion failures are affected by<BR>> >> this also, but not fully.<BR>> >> Before you would have gotten:<BR>> >> ***<BR>> >> *** runtime error:<BR>> >> *** <*ASSERT*> failed.<BR>> >> *** file "WaitProcessCygwin.m3", line 16<BR>> >> ***<BR>> >> but now you get:<BR>> >> ***<BR>> >> *** runtime error:<BR>> >> *** <*ASSERT*> failed.<BR>> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16<BR>> >> ***<BR>> >> I'd say the realpath call (or whatever the portable Modula-3<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> library<BR>> >> call is) should be moved up to m3front to address these, and the<BR>> >> parse.c change undone.<BR>> >> As well, I believe resolving symlinks is happening too but<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> that<BR>> >> wasn't the point, so something instead of realpath might be<BR>> >> preferable. Like, just see if the string starts ".\" or "..\", it<BR>> >> will almost always start "..\", and if so, prepend current working<BR>> >> directory and then workout the dots.<BR>> >> It may also be reasonable to provide paths to the compiler<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> to remove<BR>> >> from the starts of paths, which would likely address the symlink<BR>> >> issue, since they are more likely to be nearer the start of the<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> path<BR>> >> than the middle or end. As well as partly the<BR>> >> privacy/size/same-across-machines issues.<BR>> >> In any case, I think this easy small change is already very<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> useful<BR>> >> progress. Or does everyone else just fill up .gdbinit with dir<BR>> >> commands? It seems to me that it shouldn't even that difficult,<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> even<BR>> >> if it isn't very difficult.<BR>> >> Agreed?<BR>> >> - Jay<BR>> >><SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> ------------------------------------------------------------------------<BR>> >> From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</A><BR>> >> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</A><BR>> >> Subject: re: put full paths to source files in debug info<BR>> >> Date: Thu, 28 Feb 2008 08:31:32 +0000<BR>> >> ps: does anyone care that binaries built from different cvs<BR>> >> checkouts, but otherwise identical source, will no longer match,<BR>> >> unless perhaps they are "stripped"?<BR>> >> If so, or if any of the other issues bug people, or any other<BR>> >> problem is brought up or discovered, this can be made a command<BR>> >> line option. I will always turn it on. :)<BR>> >> - Jay<BR>> >><SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> ------------------------------------------------------------------------<BR>> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000<BR>> >> > To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><BR>> >> > From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jkrell@elego.de">jkrell@elego.de</A><BR>> >> > Subject: [M3commit] CVS Update: cm3<BR>> >> ><BR>> >> > CVSROOT: /usr/cvs<BR>> >> > Changes by: jkrell@birch. 08/02/28 09:23:22<BR>> >> ><BR>> >> > Modified files:<BR>> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c<BR>> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3<BR>> >> > Scanner.m3<BR>> >> ><BR>> >> > Log message:<BR>> >> > put full paths to source files in debug info<BR>> >> ><BR>> >> > This has the minor downsides of:<BR>> >> > 1) grows the debug info (it is already huge; who is counting?)<BR>> >> > 2) reveals file system layout in debug info (privacy?)<BR>> >> > 3) does it inhibit debugging files from other people's machines<BR>> >> or does gdb dir still work?<BR>> >> ><BR>> >> > but definitely makes for a more pleasant debugging experience<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> when<BR>> >> > debugging stuff you have built yourself.<BR>> >> ><BR>> >> > The linear searching to see if a name has been allocated a<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> number yet<BR>> >> > will obviously slow way down due to a large increase in common<BR>> >> prefixes,<BR>> >> > but that should be a hash table anyway. Linear search is lame.<BR>> >> > (or a trie, but working from the ends of the strings, minus the<BR>> >> last one or few<BR>> >> > characters, due to common prefixes as well as common suffixes)<BR>> >> ><BR>> >> > Note that both m3front and m3cc changes are needed as m3front<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> has<BR>> >> paths<BR>> >> > relative to the current working directory or such.<BR>> >> ><BR>> >> > For most packages, you can get by without the m3front change<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> and<BR>> >> just prepend<BR>> >> > "../src/" to the path in m3cc, but that doesn't work for<BR>> >> hierarchical packages<BR>> >> > such as libm3 and m3core which I am debugging.<BR>> >> ------------------------------------------------------------------------<BR>> >> Need to know the score, the latest news, or you need your HotmailŪ-<SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> get your "fix". Check it out. <<A href="http://www.msnmobilefix.com/Default.aspx" target=_blank>http://www.msnmobilefix.com/Default.aspx</A><SPAN class=EC_Apple-converted-space> </SPAN><BR>> >> ><BR>> ><BR>> > --<SPAN class=EC_Apple-converted-space> </SPAN><BR>> > -------------------------------------------------------------<BR>> > Rodney M. Bates, retired assistant professor<BR>> > Dept. of Computer Science, Wichita State University<BR>> > Wichita, KS 67260-0083<BR>> > 316-978-3922<BR>> ><SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:rodney.bates@wichita.edu">rodney.bates@wichita.edu</A><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR><BR><BR>
<HR>
Need to know the score, the latest news, or you need your HotmailŪ-get your "fix".<SPAN class=EC_Apple-converted-space> </SPAN><A href="http://www.msnmobilefix.com/Default.aspx" target=_blank>Check it out.</A></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>