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

[Jay]

> ...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.btw, I don't think this part is true.
I don't believe the object files contain full source paths anywhere.
But oops, I admit I didn't open the .ms or .mo files and double check that.
However, "the way it works", where "it" is the little bit of code I looked at,
is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that
path was passed in to gcc.
 
My experience with gdb strongly suggests that this sort of path is the only
one in the debug info.
 
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..)
 
I wonder as well if a list of directories can be put in the debug info.
You know, partly as a size optimization, and possibly to address these issues.
  (of course the size optimization could be independently implemented)
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.
 
Command line debuggers are quite daunting.
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. ?
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to source files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500


On Feb 28, 2008, at 8:01 PM, Jay wrote:


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?

Yes, I do this all the time...via the emacs keybindings -- not sure if full paths would break things or not.

Gdb doesn't have any fuzzy matching?
Not sure.


Maybe in gcc I can give multiple file names?

Again, not sure.

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 use gdb under emacs...  if the emacs bindings continue to work then OK, but if not then problems.

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.

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.

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/0266b1e0/attachment-0002.html>