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

[Rodney M. Bates]

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