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

[Tony Hosking]

Sorry, read your message too quickly.  Yes, links might be nice....  :-)

On Feb 28, 2008, at 1:47 PM, Jay wrote:

> Links, not diffs.
>
>  - Jay
>
>
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] put full paths to source files in debug info
> Date: Thu, 28 Feb 2008 09:09:14 -0500
>
> No, please don't do that!!!!  I hate it when I get a huge file of  
> diffs.  The comment should be descriptive enough to let me know if I  
> care about the diffs or not.  As an emacs user it is trivial for me  
> to browse diffs there if I *really* care.  But e-mail is the *wrong*  
> place for diffs!!
>
> On Feb 28, 2008, at 4:25 AM, Jay wrote:
>
> Is it easy enough for the commit mails to contain links to view all  
> of the diffs described?
> That's be super duper nice.
> I find browsing the cvsweb very inefficient.
>
>  - Jay
>
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Subject: FW: put full paths to source files in debug info
> Date: Thu, 28 Feb 2008 08:59:47 +0000
>
> 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.
>
> Helping your favorite cause is as easy as instant messaging. You IM,  
> we give. Learn more.
>
>
> Need to know the score, the latest news, or you need your Hotmail®- 
> get your "fix". Check it out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080228/bb53535e/attachment-0002.html>