Hello, Michael, Brad I still think it would be necessary that the callchain can be back-traced to the exact source line in the user code, imagine you are debugging a large Chapel program and make break points, you definitely want to back-trace to where the function/statement was called in the user code (not interested in internal modules usually). Since now the line number is correctly mapped to the user code, why couldn't the filename be right ? Do you have any idea how the filename information could be transferred as well ?
Thanks On Fri, Oct 30, 2015 at 1:29 PM, Hui Zhang <wayne.huizh...@gmail.com> wrote: > 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 > -- Best regards Hui Zhang
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
