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

[Mika Nystrom]

I'm pretty sure I've seen full paths in ASSERT failures, using, perhaps,
ezm3?  It didn't cause any gdb problems (I use the old m3gdb a lot).

      Mika

Jay writes:
>--_93b0d79c-137f-47e2-9518-78e460fd7ea0_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>> ...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, thou=
>gh I don't know of a place the debugger uses this now.btw, I don't think th=
>is part is true.
>I don't believe the object files contain full source paths anywhere.
>But oops, I admit I didn't open the .ms or .mo files and double check that.
>However, "the way it works", where "it" is the little bit of code I looked =
>at,
>is cm3 IL contains the path "as specified" (e.g. ../src/foo.m3) and that
>path was passed in to gcc.
>=20
>My experience with gdb strongly suggests that this sort of path is the only
>one in the debug info.
>=20
>I will check more stuff tonight, the behavior of __FILE__, the behavior of =
>gcc+gdb, the behavior of foo.c#123 or whatever the syntax is and MAYBE the =
>behavior of emacs+gdb (yet another learning curve..man, being low in the ca=
>llstack requires familiarity with everyone's workflow above you..)
>=20
>I wonder as well if a list of directories can be put in the debug info.
>You know, partly as a size optimization, and possibly to address these issu=
>es.
>  (of course the size optimization could be independently implemented)
>When I stepping, I don't really need gdb to show me the full path, that is =
>often but not always noise, I just need it to know the full path so it can =
>show the source. As things were, gdb wouldn't find source without dir comma=
>nds.
>=20
>Command line debuggers are quite daunting.
>I don't know if it is worthwhile to strive to reduce the fear and pain they=
> cause, or just suck it all up because you'll hardly make much of a dent an=
>yway. ?
>=20
> - Jay
>
>
>CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.=
>eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] FW: put full paths to sour=
>ce files in debug info]Date: Thu, 28 Feb 2008 22:01:42 -0500
>
>
>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 us=
>e the switch I know what trouble I'm bringing myself. Setting breakpoints i=
>n "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 debugg=
>ing 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 defa=
>ult, 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 us=
>e 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, b=
>ut 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* fi=
>le, unsigned line);#define assert(expr) ((expr) ? assert_failed(#expr, __FI=
>LE__, __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 li=
>ke basic correctness to me, to give a debugger full paths.I'm quite surpris=
>ed by the pushback.
>
>I look forward to Rodney's input since he has most experience with m3gdb an=
>d 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 o=
>n 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 > > si=
>mple> > 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 th=
>e debugger itself with the debug info as it was. It > > already> > containe=
>d 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 kno=
>w the filename/modulename rules don't actually apply for > > modules,> > bu=
>t not following them is a bad practice. I've been around that > > block man=
>y> > 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 use=
>ful in > > debugging, especially> > when InterfaceName/ModuleName is not on=
>e-to-one, e.g. when a module > > exports >1> > interface, etc.> >> > Jay wr=
>ote:> >> truncated again! and possibly misformated..> >> > >> -------------=
>-----------------------------------------------------------> >> From: jayk1=
>23 at hotmail.com> >> To: m3devel at elegosoft.com> >> Subject: RE: put full path=
>s to source files in debug info> >> Date: Thu, 28 Feb 2008 08:44:11 +0000> =
>>> pps: "webinfo" (Reactor?) and assertion failures are affected by> >> thi=
>s also, but not fully.> >> Before you would have gotten:> >> ***> >> *** ru=
>ntime error:> >> *** <*ASSERT*> failed.> >> *** file "WaitProcessCygwin.m3"=
>, line 16> >> ***> >> but now you get:> >> ***> >> *** runtime error:> >> *=
>** <*ASSERT*> failed.> >> *** file "..\src\thread\WIN32\WaitProcessCygwin.m=
>3", line 16> >> ***> >> I'd say the realpath call (or whatever the portable=
> Modula-3 > >> library> >> call is) should be moved up to m3front to addres=
>s these, and the> >> parse.c change undone.> >> As well, I believe resolvin=
>g symlinks is happening too but > >> that> >> wasn't the point, so somethin=
>g instead of realpath might be> >> preferable. Like, just see if the string=
> starts ".\" or "..\", it> >> will almost always start "..\", and if so, pr=
..