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

[Tony Hosking]

On Feb 28, 2008, at 8:01 PM, Jay wrote:

> Are you all serious? Telling the debugger the full path to source  
> files via the debuginfo is bad?
> 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.
> 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, I do this all the time...via the emacs keybindings -- not sure if  
full paths would break things or not.

> Gdb doesn't have any fuzzy matching?

Not sure.

> Maybe in gcc I can give multiple file names?

Again, not sure.

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

I use gdb under emacs...  if the emacs bindings continue to work then  
OK, but if not then problems.

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

I look forward to Rodney's input since he has most experience with  
m3gdb and its expectations, and moreover with the current behavior of  
gdb for other languages.

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

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