Hello, Michael Thanks ! I've tried to rerun my experiment with --no-devel, but it still went to internal modules.
So, for the current compiler, reasonable stack frame should be mapped to the internal module file with line# in the internal module instead of user code right ? On Fri, Oct 30, 2015 at 1:05 PM, Michael Ferguson <mfergu...@cray.com> wrote: > Hi - > > Answering your other email - I think it's a bug in the compiler > if the line number is right but the filename is wrong... > > Also, I think you should try running your experiments with > CHPL_DEVELOPER unset (or set to 0). It might be that the > work Brad described will form your work-around. So that > your tool wouldn't see any internal module file/line #s. > > Cheers, > > -michael > > On 10/30/15, 1:01 PM, "Hui Zhang" <wayne.huizh...@gmail.com> wrote: > > >Hello, Brad > > > > > >On Fri, Oct 30, 2015 at 12:58 PM, Brad Chamberlain > ><br...@cray.com> 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" <wayne.huizh...@gmail.com> 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 > > > > > > > > -- Best regards Hui Zhang
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
