Using wrong file paths during debug compilation with local temp dir

[imrehg]

I was trying out COPRTHR on Parallella and needed to debug some issues. If I run the debugger with a local directory to output its work progress like cldebug -t temp -- <programfilename>, I got quite a few errors along the line of cpp: fatal error: no input files. Looking at the commands the problem is that first the code cd into the work directory, but within there it executes the follow-up commands with the full relative file path (from before cd) instead of just the base file name. See for example this build log. An excerpt:

[16048] clmesg debug: computil_e32.h(560): execshell> cd temp/xcl6eUI59; cpp -x c++  -D__coprthr_device__  -I/usr/local/browndeer/include temp/xcl6eUI59/eman39.cl   | awk -v prog=\"temp/xcl6eUI59/eman39.cl\" 'BEGIN { pr=0; } {    if($0~/^#/ && $3==prog) pr=1;   else if ($0~/^#/) pr=0;   if ($0!~/^#/ && pr==1) print $0; }' | xclnm --kcall -d -c -o _kcall_eman39.c - 
cpp: error: temp/xcl6eUI59/eman39.cl: No such file or directory
cpp: warning: ‘-x c++’ after last input file has no effect
cpp: fatal error: no input files
compilation terminated.

As I check, temp/xcl6eUI59/eman39.cl exists, but at that point cpp should be looking for eman39.cl instead, because it just cd'd into temp/xcl6eUI59/ a moment earlier...

Any thoughts on this? I'm using the stable-1.6.2 branch.

[browndeer]

If you have created a local path temp/ try to use the full path with the -t option. This has been a longstanding bug in
the script and should be fixed, but see if this makes the errors go away.

-DAR

Gergely Imreh wrote:

I was trying out COPRTHR on Parallella and needed to debug some issues.
If I run the debugger with a local directory to output its work progress
like |cldebug -t temp -- |, I got quite a few errors
along the line of |cpp: fatal error: no input files|. Looking at the
commands the problem is that first the code |cd| into the work
directory, but within there it executes the follow-up commands with the
full relative file path (from before cd) instead of just the base file
name. See for example this build log
https://gist.github.com/imrehg/10cd6143528afa9cc76b#file-cldebug-log-L92-L105.
An excerpt:

|[16048] clmesg debug: computil_e32.h(560): execshell> cd temp/xcl6eUI59; cpp -x c++ -D__coprthr_device__ -I/usr/local/browndeer/include temp/xcl6eUI59/eman39.cl | awk -v prog="temp/xcl6eUI59/eman39.cl" 'BEGIN { pr=0; } { if($0~/^#/ && $3==prog) pr=1; else if ($0~/^#/) pr=0; if ($0!~/^#/ && pr==1) print $0; }' | xclnm --kcall -d -c -o _kcall_eman39.c -
cpp: error: temp/xcl6eUI59/eman39.cl: No such file or directory
cpp: warning: ‘-x c++’ after last input file has no effect
cpp: fatal error: no input files
compilation terminated.
|

As I check, |temp/xcl6eUI59/eman39.cl| exists, but at that point |cpp|
should be looking for |eman39.cl| instead, because it just |cd|'d into
|temp/xcl6eUI59/| a moment earlier...

Any thoughts on this? I'm using the stable-1.6.2 branch.

—
Reply to this email directly or view it on GitHub
#29.

David Richie, Ph.D.
Brown Deer Technology
1641 Denwright Court
Forest Hill, MD 21050
410-459-3848
[email protected]
www.browndeertechnology.com

[imrehg]

yeah, indeed, that makes sense, and it does work (for simplicity I just used cldebug -t $PWD/temp -- <program>, that's the shortest workable change.

And indeed, I know what you mean. Having absolute paths is not actually a problem, since its easy to turn a local path into absolute like above. Though still does not quite understand why does the script simultaneously cd into a directory and calls the file with its full path. It should probably either / or.

As a sidenote, for short term maybe the biggest issue in this sense is the sparsity of docs. If cldebug says that -t needs absolute path, then it's all fine, there's no bug like the one above. But for most of the command line switches for cldebug, clcc and so on, I can only find out the valid option values by reading their source code (sometimes that doesn't even help) and trial & error. Some more documentation would be very helpful, will look into what's there already, and where can I help to add more. Thanks!

[browndeer]

This is fixed with the commit just pushed to the stable-1.6 branch. cldebug has been updated so as to not require full
path for -t option.

Regarding documentation, if you find gaps and/or things that could be explained better, please do make a note of these
things. We appreciate this feedback and will try to address it.

-DAR

Gergely Imreh wrote:

yeah, indeed, that makes sense, and it does work (for simplicity I just
used |cldebug -t $PWD/temp -- |, that's the shortest workable
change.

And indeed, I know what you mean. Having absolute paths is not actually
a problem, since its easy to turn a local path into absolute like above.
Though still does not quite understand why does the script
simultaneously |cd| into a directory and calls the file with its full
path. It should probably either / or.

As a sidenote, for short term maybe the biggest issue in this sense is
the sparsity of docs. If |cldebug| says that |-t| needs absolute path,
then it's all fine, there's no bug like the one above. But for most of
the command line switches for |cldebug|, |clcc| and so on, I can only
find out the valid option values by reading their source code (sometimes
that doesn't even help) and trial & error. Some more documentation would
be very helpful, will look into what's there already, and where can I
help to add more. Thanks!

—
Reply to this email directly or view it on GitHub
#29 (comment).

David Richie, Ph.D.
Brown Deer Technology
1641 Denwright Court
Forest Hill, MD 21050
410-459-3848
[email protected]
www.browndeertechnology.com

[imrehg]

Thanks, doing a quick test, after 618c906 it does work, both with relative and absolute paths.

[browndeer]

There is also an undocumented feature, using a '-T' instead of '-t' will cause the temp directory to be cleared. This
can be useful if you are repeatedly compiling since it can be confusing to figure out which subdirectory was created
last, as you work through some debugging exercise. Just a convenience feature.

Gergely Imreh wrote:

Thanks, doing a quick test, after 618c906
618c906
it does work, both with relative and absolute paths.

—
Reply to this email directly or view it on GitHub
#29 (comment).

David Richie, Ph.D.
Brown Deer Technology
1641 Denwright Court
Forest Hill, MD 21050
410-459-3848
[email protected]
www.browndeertechnology.com