[M3devel] FW: put full paths to source files in debug info]
Rodney M. Bates
rodney.bates at wichita.edu
Fri Feb 29 18:32:49 CET 2008
Jay wrote:
> > ...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.
>
> btw, I don't think this 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.
>
> My experience with gdb strongly suggests that this sort of path is the only
> one in the debug info.
Evidence:
-----------------------------------------------------------------------------------------------
[rodney at selkirk LINUXLIBC6]$ objdump -G Sets.mo | more
Sets.mo: file format elf32-i386
Contents of .stab section:
Symnum n_type n_othr n_desc n_value n_strx String
-1 HdrSym 0 839 00001db3 1
0 SO 0 0 00000000 9 /home/rodney/proj/util/m3/ordsets/LINUXLIBC6/
1 SO 0 0 00000000 55 Sets.mc
2 OPT 0 0 00000000 63 gcc2_compiled.
... A bunch of irrelevant type definitions deleted .........
3 LSYM 0 0 00000000 78 26 SOL 0 0 00000000 1353 Sets.m3
-----------------------------------------------------------------------------------------------
This is from an earlier compiler, before your change. Your change shows up in the
last line, in front of Sets.m3.
The path in the separate SO line is to the compiled object file, not the
source. For Modula-3, getting the source file is usually trivial, although
not always, especially the RTS.
When changing m3gdb to use this after normal dir/-d paths have failed,
I would consider changing cm3 to emit a 3rd SO line with the source path,
*IF* this didn't choke stock gdb, which I doubt it would. However m3gdb
works on code compiled by all the compilers, including older versions of
cm3, so perhaps searching below ../src would be needed anyway.
>
> 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 callstack requires familiarity with everyone's workflow above
> you..)
>
> 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
> issues.
> (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 commands.
>
> 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 anyway. ?
>
> - Jay
>
> ------------------------------------------------------------------------
> CC: rodney.bates at wichita.edu; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] FW: put full paths to source 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 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 <mailto:hosking at cs.purdue.edu>
>> To: rodney.bates at wichita.edu <mailto:rodney.bates at wichita.edu>
>> Date: Thu, 28 Feb 2008 14:12:33 -0500
>> CC: m3devel at elegosoft.com <mailto: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 <mailto:jayk123 at hotmail.com>
>> >> To: m3devel at elegosoft.com <mailto: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 <mailto:jayk123 at hotmail.com>
>> >> To: m3devel at elegosoft.com <mailto: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 <mailto:m3commit at elegosoft.com>
>> >> > From: jkrell at elego.de <mailto: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 <mailto: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>
>
>
>
> ------------------------------------------------------------------------
> Shed those extra pounds with MSN and The Biggest Loser! Learn more.
> <http://biggestloser.msn.com/>
--
-------------------------------------------------------------
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
More information about the M3devel
mailing list