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

[Tony Hosking]

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