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

[Rodney M. Bates]

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.

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.

> __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.

> 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