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

Tony Hosking hosking at cs.purdue.edu
Fri Feb 29 04:02:23 CET 2008 

Before we decide a switch is needed, can anyone tell me what gcc does  
by default for C?  Does gcc have a switch already?

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

> If this must be a switch, what should the default be?
> I suspect the default should be full paths.
>
> And then, should there be switches for each of:
>    debuginfo
>    assertions
>    webinfo
>
> "assertions" actually use the Modula-3 equivalent of __FILE__.
> And so, what this should perhaps looks like is, using bogus Cish  
> names,
>    __FULL_FILE__ (e.g. /usr/home/jkrell/dev2/cm2/m3-libs/m3core/src/ 
> unix/usomething.m3)
>    __SPECIFIED_FILE__ (e.g. ..\src\foo.m3 or ..\src\thread\posix 
> \fooposix.m3)
>    __LEAF_FILE__  (e.g. fooposix.m3)
>
> or maybe just the first two, and maybe the one that exists today  
> retains its meaning and a new "full file" is introduced. And then  
> folks can use it if they wish, and assertion maybe honors a switch.
>
> I hate to make everything TOO flexible and configurable though. It  
> can get confusing, and the underutilized options may get undertested  
> (but better now with increasing automated testing).
>
>  - Jay
>
> From: jayk123 at hotmail.com
> To: hosking at cs.purdue.edu; rodney.bates at wichita.edu
> Date: Fri, 29 Feb 2008 01:01:02 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FW: put full paths to source files in debug  
> info]
>
> 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?
> 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.
>
> 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.
>
> 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.
>
> Climb to the top of the charts! Play the word scramble challenge  
> with star power. Play now!

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

More information about the M3devel mailing list