I'm only following this conversation at a high-level, but wanted to throw out a couple of data points in case they're useful:
* for code that is considered "internal" (e.g., in modules/internal), the compiler makes a best attempt to refer to the user's code that called into the internal module rather than pointing into code that arguably isn't under the user's control. We generally do OK with this, though I believe it sometimes goes awry when a callchain goes from user code to internal modules and then back into user code (and maybe back into internal modules). * if CHPL_DEVELOPER is set (or --devel is thrown), we don't do any of the above and just point to the actual line # (figuring that developers don't want to have these details papered over). -Brad On Fri, 30 Oct 2015, Michael Ferguson wrote: > Hi - > > On 10/30/15, 12:45 PM, "Hui Zhang" <[email protected]> wrote: > >> Hello, Michael >> >> >> Okay....that makes a lot more sense now >> >> >> In my case, as your example, I need a nice stack trace when a sample fell >> on that "writeln", but now it'll give me something like this (assume file >> is user.chpl, forall is on line >> #1): >> >> wrap_coforall_fn (user.chpl : 1) -> coforall_fn (ChapelRange.chpl: 2) -> >> writeln (..) >> >> I expected it to be something like: >> >> wrap_coforall_fn(user.chpl: 1) -> coforall_fn(user.chpl: 2) -> writeln(..) >> >> >> So if the filename is internal modules, then it'll be difficult for me >> to transfer data along the stack since my previous analysis only >> concerns about user code... > > I don't think it's philosophically wrong for the compiler to include > these internal module line numbers. Can you arrange for your tool to > ignore them somehow? > >> >> >> Another question: why the line# of the frame I got is "correct"(right >> line# in the user code, here '2') when the file/module is internal module >> ? > > That just looks like a bug to me. > > -michael > > ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
