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

[Tony Hosking]

On Feb 29, 2008, at 12:11 PM, Rodney M. Bates wrote:

>
>
> Jay wrote:
>> Are you all serious? Telling the debugger the full path to source  
>> files via the debuginfo is bad?
>
> Below.
>
>> 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.
>
> In m3gdb, you can also say 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.  PosixProcess.m3:123 is the normal way.  Since source file  
> simple names
> are unique, this is enough in Modula-3.  I suppose in C, if somebody  
> actually
> had >1 source file with the same simple name, something messier  
> would be
> needed, but normally, break Foo.c:123 is the way to do it.
>
> Likewise, before your change to debug info, output from (m3)gdb  
> showing where
> something is stopped uses source file simple names and line numbers  
> too.
>
>> Gdb doesn't have any fuzzy matching?
>> Maybe in gcc I can give multiple file names?
>> 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.
>
> The paths to source are used in (m3)gdb only to display a portion of  
> actual
> source code, not to identify file/line# places.  For the former  
> function only,
> (m3)gdb has to have full paths, and they must be as they may have  
> changed since
> things were compiled/linked.  I put -d command line options for all my
> source file paths (which do the same thing as dir gdb commands) in a  
> startup
> file for any project that gets significant work.
>
> I do agree, it would be nice for a quick jump into a debugger, not  
> to have
> to do this.  It could only work, of course, if the source files are  
> where
> they were at the time of compilation.  The way to do this is for gdb  
> to
> try the path from the object module, after normal use of dir/-d  
> paths have
> failed.  Since we can't change gdb, this would only be in m3gdb.

Indeed!  Given that cm3 compiles in one location and ships to another  
it is important that full paths *not* be used I suspect.  That way,  
one can have users of installed packages debug against their source as  
necessary.

> On big advantage of this would be that it would work when one needs to
> debug right into the runtime system, as I do somewhat regularly.  That
> requires several additional paths that one would not ordinarily have
> specified.  The way we are installing Modula-3 now, it is a pretty  
> safe
> bet that, if the source exists at all, then it where it was when the
> runtime system was compiled.
>
> (Well, copies of the interfaces do get placed in the install  
> directory, but
> I'm not sure m3gdb ever displays non-executable code, which is all
> that interfaces have.)
>
> You have convinced me to add this to my list.
>
>> 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)
>>
>
> We don't have anything like __FILE__ and __LINE__ in Modula-3.  I  
> have a
> largish program full of assertions with it's own coded assertion  
> handling,
> including recoverable (in a sense, roll back to a consistent state)  
> assertion
> failures.  It could use something like this.  But it also seems  
> pretty hackish
> to me too.

Sure we do:

Compiler.ThisLine()
Compiler.ThisFile()

>
>
>> __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.
>
> People can and often do move executables to different machines and  
> also
> sometimes move source trees around on the original machine.  Using  
> simple
> file names within an executable (of which there is always exactly one)
> is invariant to all this, and a lot shorter to type/read.

Agreed.

>
>
>> I'm quite surprised by the pushback.
>> 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. <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