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

[Jay]

truncated again! and possibly misformated..


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: RE: put full paths to source files in debug infoDate: 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.comTo: m3devel at elegosoft.comSubject: re: put full paths to source files in debug infoDate: 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".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080228/5ce0fc04/attachment-0001.html>