<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>If this must be a switch, what should the default be?<BR>
I suspect the default should be full paths.<BR>
<BR>
And then, should there be switches for each of:<BR>
debuginfo <BR>
assertions <BR>
webinfo <BR>
<BR>
"assertions" actually use the Modula-3 equivalent of __FILE__.<BR>
And so, what this should perhaps looks like is, using bogus Cish names, <BR>
__FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) <BR>
__SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) <BR>
__LEAF_FILE__ (e.g. fooposix.m3) <BR>
<BR>
or maybe just the first two, and maybe the one that exists today retains its meaning and a new "full file" is introduced. And then folks can use it if they wish, and assertion maybe honors a switch.<BR>
<BR>
I hate to make everything TOO flexible and configurable though. It can get confusing, and the underutilized options may get undertested (but better now with increasing automated testing).<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: hosking@cs.purdue.edu; rodney.bates@wichita.edu<BR>Date: Fri, 29 Feb 2008 01:01:02 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] FW: put 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>
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?<BR>Gdb doesn't have any fuzzy matching?<BR>Maybe in gcc I can give multiple file names?<BR> <BR>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.<BR> <BR>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.<BR> <BR>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: hosking@cs.purdue.edu<BR>> To: rodney.bates@wichita.edu<BR>> Date: Thu, 28 Feb 2008 14:12:33 -0500<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] FW: put full paths to source files in debug info]<BR>> <BR>> I concur with Rodney on this. There are deeper issues here than <BR>> simply avoiding the need to use dir in gdb.<BR>> <BR>> On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:<BR>> <BR>> ><BR>> > I don't understand what the need for these paths is. In every <BR>> > complete<BR>> > program, all the interfaces and all the modules must have unique <BR>> > simple<BR>> > names, otherwise code could not refer to them. With the filename <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 <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 <BR>> > doubt<BR>> > be done by the debugger itself with the debug info as it was. It <BR>> > already<BR>> > contained one copy of the full path to the source file in each <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 <BR>> > modules,<BR>> > but not following them is a bad practice. I've been around that <BR>> > block many<BR>> > times with Ada, and believe me, it's a nightmare. Furthermore, then <BR>> > you<BR>> > wouldn't be able to name things in the debugger as <BR>> > ModuleName.VarOrProcInModule,<BR>> > This construct does not exist in code but is very useful in <BR>> > debugging, especially<BR>> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module <BR>> > exports >1<BR>> > interface, etc.<BR>> ><BR>> > Jay wrote:<BR>> >> truncated again! and possibly misformated..<BR>> >> <BR>> >> ------------------------------------------------------------------------<BR>> >> From: jayk123@hotmail.com<BR>> >> To: m3devel@elegosoft.com<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 <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 <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 <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 <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 <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, <BR>> >> even<BR>> >> if it isn't very difficult.<BR>> >> Agreed?<BR>> >> - Jay<BR>> >> <BR>> >> ------------------------------------------------------------------------<BR>> >> From: jayk123@hotmail.com<BR>> >> To: m3devel@elegosoft.com<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>> >> <BR>> >> ------------------------------------------------------------------------<BR>> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000<BR>> >> > To: m3commit@elegosoft.com<BR>> >> > From: jkrell@elego.de<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 <BR>> >> when<BR>> >> > debugging stuff you have built yourself.<BR>> >> ><BR>> >> > The linear searching to see if a name has been allocated a <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 <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 <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®- <BR>> >> get your "fix". Check it out. <http://www.msnmobilefix.com/Default.aspx <BR>> >> ><BR>> ><BR>> > -- <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>> > rodney.bates@wichita.edu<BR>> <BR><BR><BR>
<HR>
Need to know the score, the latest news, or you need your Hotmail®-get your "fix". <A href="http://www.msnmobilefix.com/Default.aspx" target=_blank>Check it out.</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>