Hello, Brad On Fri, Oct 30, 2015 at 12:58 PM, Brad Chamberlain <[email protected]> wrote:
> > 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). > Yes, I did set CHPL_DEVELOPER. What do you mean by "we don't do any of the above and just point to the actual line #" ? the actual line# in the user code or the internal module ? thanks > > -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 >> >> >> -- Best regards Hui Zhang
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
