[M3devel] FW: put full paths to source files in debug info]

Fri Feb 29 02:59:51 CET 2008

If this must be a switch, what should the default be?
I suspect the default should be full paths.

And then, should there be switches for each of:
   debuginfo 
   assertions 
   webinfo 

"assertions" actually use the Modula-3 equivalent of __FILE__.
And so, what this should perhaps looks like is, using bogus Cish names, 
   __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/unix/usomething.m3) 
   __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix\fooposix.m3) 
   __LEAF_FILE__  (e.g. fooposix.m3) 

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.

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).

 - Jay

From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rodney.bates at wichita.eduDate: Fri, 29 Feb 2008 01:01:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] FW: put full paths to source files in debug info]

Are you all serious? Telling the debugger the full path to source files via the debuginfo is bad?What are the issues? I want to know so that when I use the switch I know what trouble I'm bringing myself. Setting breakpoints in "modules", as .dll/.so files, is unaffected I presume.As is setting them by full name PosixProcess__WaitProcess.That is what I "always" do ("always" as in, I just started using gdb a few weeks ago). What I could imagine is affected is setting them by file and line number.Do people do that? I guess the gui wrappers do, but I assume that'd still work. ?Maybe it depends. I should try out xcode and ddd and such? Do people say like break foo.c:#123? And now I've made them use a full path?Gdb doesn't have any fuzzy matching?Maybe in gcc I can give multiple file names? This really greatly improves the out-of-the-box minimally configured debugging experience.Gdb automatically shows me the source as I step, instead of just file name and line number.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. I will make it a switch in cm3 and cm3cg if it is really a problem. In C it is a common idiom:void assert_failed(const char* condition, const char* file, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FILE__, __LINE__) : (void)0) __FILE__ can vary between "the parameter to the compiler on the command line", or "full path", depending on implementation. Also:printf("foo is %d in %s\n", foo, __FILE__). This really just seems like basic correctness to me, to give a debugger full paths.I'm quite surprised by the pushback. Assertions I think should also be "fixed" further. And I suspect "webinfo" but that could wait until Reactor is available..  - Jay

> From: hosking at cs.purdue.edu> To: rodney.bates at wichita.edu> Date: Thu, 28 Feb 2008 14:12:33 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: put full paths to source files in debug info]> > I concur with Rodney on this. There are deeper issues here than > simply avoiding the need to use dir in gdb.> > On Feb 28, 2008, at 2:05 PM, Rodney M. Bates wrote:> > >> > I don't understand what the need for these paths is. In every > > complete> > program, all the interfaces and all the modules must have unique > > simple> > names, otherwise code could not refer to them. With the filename > > matchup> > rules, this should make all the simple file names unique too. So any> > debug commands should never need a path. And using simple names > > avoids> > the problems of moving compiled code.> >> > Is it more output from the debugger you want? If so, this could no > > doubt> > be done by the debugger itself with the debug info as it was. It > > already> > contained one copy of the full path to the source file in each > > object file,> > though I don't know of a place the debugger uses this now.> >> > Yes, I know the filename/modulename rules don't actually apply for > > modules,> > but not following them is a bad practice. I've been around that > > block many> > times with Ada, and believe me, it's a nightmare. Furthermore, then > > you> > wouldn't be able to name things in the debugger as > > ModuleName.VarOrProcInModule,> > This construct does not exist in code but is very useful in > > debugging, especially> > when InterfaceName/ModuleName is not one-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wrote:> >> truncated again! and possibly misformated..> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> >> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> this also, but not fully.> >> Before you would have gotten:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3", line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable Modula-3 > >> library> >> call is) should be moved up to m3front to address these, and the> >> parse.c change undone.> >> As well, I believe resolving symlinks is happening too but > >> that> >> wasn't the point, so something instead of realpath might be> >> preferable. Like, just see if the string starts ".\" or "..\", it> >> will almost always start "..\", and if so, prepend current working> >> directory and then workout the dots.> >> It may also be reasonable to provide paths to the compiler > >> to remove> >> from the starts of paths, which would likely address the symlink> >> issue, since they are more likely to be nearer the start of the > >> path> >> than the middle or end. As well as partly the> >> privacy/size/same-across-machines issues.> >> In any case, I think this easy small change is already very > >> useful> >> progress. Or does everyone else just fill up .gdbinit with dir> >> commands? It seems to me that it shouldn't even that difficult, > >> even> >> if it isn't very difficult.> >> Agreed?> >> - Jay> >> > >> ------------------------------------------------------------------------> >> From: jayk123 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: re: put full paths to source files in debug info> >> Date: Thu, 28 Feb 2008 08:31:32 +0000> >> ps: does anyone care that binaries built from different cvs> >> checkouts, but otherwise identical source, will no longer match,> >> unless perhaps they are "stripped"?> >> If so, or if any of the other issues bug people, or any other> >> problem is brought up or discovered, this can be made a command> >> line option. I will always turn it on. :)> >> - Jay> >> > >> ------------------------------------------------------------------------> >> > Date: Thu, 28 Feb 2008 09:23:22 +0000> >> > To: m3commit at elegosoft.com> >> > From: jkrell at elego.de> >> > Subject: [M3commit] CVS Update: cm3> >> >> >> > CVSROOT: /usr/cvs> >> > Changes by: jkrell at birch. 08/02/28 09:23:22> >> >> >> > Modified files:> >> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> > cm3/m3-sys/m3front/src/misc/: Coverage.m3 Host.i3 Host.m3> >> > Scanner.m3> >> >> >> > Log message:> >> > put full paths to source files in debug info> >> >> >> > This has the minor downsides of:> >> > 1) grows the debug info (it is already huge; who is counting?)> >> > 2) reveals file system layout in debug info (privacy?)> >> > 3) does it inhibit debugging files from other people's machines> >> or does gdb dir still work?> >> >> >> > but definitely makes for a more pleasant debugging experience > >> when> >> > debugging stuff you have built yourself.> >> >> >> > The linear searching to see if a name has been allocated a > >> number yet> >> > will obviously slow way down due to a large increase in common> >> prefixes,> >> > but that should be a hash table anyway. Linear search is lame.> >> > (or a trie, but working from the ends of the strings, minus the> >> last one or few> >> > characters, due to common prefixes as well as common suffixes)> >> >> >> > Note that both m3front and m3cc changes are needed as m3front > >> has> >> paths> >> > relative to the current working directory or such.> >> >> >> > For most packages, you can get by without the m3front change > >> and> >> just prepend> >> > "../src/" to the path in m3cc, but that doesn't work for> >> hierarchical packages> >> > such as libm3 and m3core which I am debugging.> >> ------------------------------------------------------------------------> >> Need to know the score, the latest news, or you need your Hotmail®- > >> get your "fix". Check it out. <http://www.msnmobilefix.com/Default.aspx > >> >> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> 

Need to know the score, the latest news, or you need your Hotmail®-get your "fix". Check it out. 
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080229/c74ff9f3/attachment-0002.html>