Problem with goto line with error listed in output window after compilation

random.chance · Jul 30, 2014#12014-07-30T13:48+00:00

I'm using UEStudio 14 and getting some strange behavior after I build a project. Normally if there are errors in the output window, I can double-click them and UE will take me to the line, but lately it has started either taking me to line 66 in the offending file or telling just telling me "\\.\con was not found" in a popup box and not doing anything. This doesn't happen in every file, but there are enough that it does happen with that it becomes annoying. Has anybody seen this behavior before?

Mofi · Jul 30, 2014#22014-07-30T20:58+00:00

What does the output window contain after running a failed build?
Do have right clicked into the output window, left clicked on Set Default Path for Relative Paths and configured something not working anymore?
Do you use an updated compiler or changed something on compiler options resulting in printing the error messages by the compiler/linker different to previous version/configuration?

\\.\con is a strange path as it looks like a UNC path for a public share with name con on a server with just a dot as name whereby con is a reserved name for device console and therefore it is not possible to use con as name for files or folders. Or this should be a relative path, but has wrong syntax and therefore just looks like a UNC path. But that are just speculations without knowing what output window contains.

random.chance · Jul 31, 2014#32014-07-31T14:08+00:00

I introduced an error into my build and copied the output window contents:

Code: Select all

"C:\pemicro\pkgppcnexus\gnu\bin\powerpc-eabispe-gcc.exe" -x c -c -DV3 -DJ10T4M1 -DJTVERSION=versionString -Wa,-mregnames -Wa,-mbooke32 -Wa,-me200 -misel=yes -mspe=yes -mfloat-gprs=no -msoft-float -mno-string -msdata=none -nostartfiles -gdwarf-2 -O0 -c -mno-eabi -mregnames -omf=elf -mcpu= "E:\common\DEVELO~1\EMBEDD~1\V3_Mach1\common\L2CanProtocol.c" -o"L2CanProtocol.o" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\JT100" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3Headers" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3L0" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3L1" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3StartupCode" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3TPUCMW1" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\JT100\j1939" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\JT100\j1939\DMx" -I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\JT100\j1939\ca" -Wa,-I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\JT100" -Wa,-I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3StartupCode" -Wa,-I"E:\common\development\Embedded 60 Pin V3\V3_Mach1\common\V3Headers"
In file included from E:\common\DEVELO~1\EMBEDD~1\V3_Mach1\common\L2CanProtocol.c:32:
E:/common/development/Embedded 60 Pin V3/V3_Mach1/JT100/L2CanProt_10T4_v3.c:60:4: warning: #warning ********** Using j1939 CAN system timing **********
In file included from E:\common\DEVELO~1\EMBEDD~1\V3_Mach1\common\L2CanProtocol.c:32:
E:/common/development/Embedded 60 Pin V3/V3_Mach1/JT100/L2CanProt_10T4_v3.c: In function `CANGetAlarmSet':
E:/common/development/Embedded 60 Pin V3/V3_Mach1/JT100/L2CanProt_10T4_v3.c:641: error: syntax error before '}' token

In this case when I double-click the error it will open the file, but it only takes me to line 60 instead of line 641. It doesn't matter where the error is inserted, it only goes to line 60 when double-clicked. In this case it opens the file but with some files it won't and instead give the \\.\con message.

I did check the "Set Default Path for Relative Paths" option and tried setting it to the project directory, but it didn't affect the behavior. (that is as expected since you can see in the output the reference isn't using relative paths anyway) Our compiler hasn't been upgraded or changed in at least 8 years so it definitely isn't that. When I first installed it was working fine, and I can't really pinpoint when it started so I can't isolate it to any specific UE update. I think I'll try uninstalling and reinstalling and see if that changes anything.

Thanks for helping!

Jul 31, 2014#42014-07-31T17:16+00:00

Okay, got it figured out, not solved but at least defined. Apparently the doubleclick goto error functionality gets confused when you have files included from other files that are more than 1 or 2 levels down. This particular codebase has files that conditionally include other files that may even conditionally include other files until you get to the specific code that you need (bad practice I know, but I inherited this code from others). I guess that is what causes UEStudio to be unable to find the line or even the correct file sometimes. It never happens with first level included files, always with second-level included files, and the \\.\con thing happens with files that are even deeper included. It probably has to do with how that output line is parsed, but not really surprising given how convoluted this particular codebase is.

Mofi · Aug 01, 2014#52014-08-01T09:53+00:00

Okay, we have a progress on finding the problem.

Typical formats for compiler errors on Windows are (as far as I know):

Full\Path\File Name/line number:
Full\Path\File Name(line number):
Full\Path\File Name:line number:

What looks strange in output of powerpc-eabispe-gcc.exe are the file paths with slash as directory separator like on Unix instead of backslash as standard on Windows, especially because of the include directories are specified with backslashes on command line invoking the compiler and the information messages between the warning and output messages are with backslashes in file path.

I think, UEStudio gets confused on parsing the warning/error lines because of slash instead of backslash and additionally spaces in file path without double quotes around full file name. Embedded 60 Pin V3 is most likely responsible for setting caret at line 60 instead of the line specified by the line number after the colon.

I think, cross-compiler powerpc-eabispe-gcc.exe is not correct compiled for Windows because on compilation of gcc the directory separator of the host operating system is usually taken into account for output messages.

Possible solutions for this problem:

There is perhaps a command line switch to control which directory separator to use on output messages, look into manual of compiler.
A newer version of the compiler is available which outputs the warning/error messages with a backslash on Windows instead of slash and it is possible for you to use this newer version.
The directories with a space in name could be renamed by using underscores instead of the spaces or removing the spaces.
A filter program is written and used by you which converts the slashes in the file paths to backslashes.

I have used the last option by myself for an old compiler to reformat the output of the compiler to a format correct parsed by UE/UES.

In this case the filter application would not be difficult to write for the replacement of slashes in file paths to backslashes. It just has to look if second character of a line is a colon and third one is a slash. If this is the case, all slashes beginning with the first one at character index 2 on output line need to be replaced by a backslash up to one more colon is found. The rest of the line as all other lines is output unmodified by the filter application from input.

But before trying all this solutions, copy following lines into a text file saved with file name Test.js, and use next Scripting - Run Active Script.

Code: Select all

UltraEdit.outputWindow.showStatus=false;
UltraEdit.outputWindow.clear();
UltraEdit.outputWindow.write("\"C:\\pemicro\\pkgppcnexus\\gnu\\bin\\powerpc-eabispe-gcc.exe\" -x c -c -DV3 -DJ10T4M1 -DJTVERSION=versionString -Wa,-mregnames -Wa,-mbooke32 -Wa,-me200 -misel=yes -mspe=yes -mfloat-gprs=no -msoft-float -mno-string -msdata=none -nostartfiles -gdwarf-2 -O0 -c -mno-eabi -mregnames -omf=elf -mcpu= \"E:\\common\\DEVELO~1\\EMBEDD~1\\V3_Mach1\\common\\L2CanProtocol.c\" -o\"L2CanProtocol.o\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3Headers\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3L0\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3L1\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3StartupCode\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3TPUCMW1\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\j1939\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\j1939\\DMx\" -I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\j1939\\ca\" -Wa,-I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\" -Wa,-I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3StartupCode\" -Wa,-I\"E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\common\\V3Headers\"");
UltraEdit.outputWindow.write("In file included from E:\\common\\DEVELO~1\\EMBEDD~1\\V3_Mach1\\common\\L2CanProtocol.c:32:");
UltraEdit.outputWindow.write("E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\L2CanProt_10T4_v3.c:60:4: warning: #warning ********** Using j1939 CAN system timing **********");
UltraEdit.outputWindow.write("In file included from E:\\common\\DEVELO~1\\EMBEDD~1\\V3_Mach1\\common\\L2CanProtocol.c:32:");
UltraEdit.outputWindow.write("E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\L2CanProt_10T4_v3.c: In function `CANGetAlarmSet':");
UltraEdit.outputWindow.write("E:\\common\\development\\Embedded 60 Pin V3\\V3_Mach1\\JT100\\L2CanProt_10T4_v3.c:641: error: syntax error before '}' token");
UltraEdit.outputWindow.showWindow(true);

As you can see, the slashes are replaced by backslashes in this little script writing the lines into the output window.

Now double click on warning/error lines in output window or use Ctrl+Shift+Up/Down from within active document window.

Is the file correct opened now with caret in correct line?

Yes, then indeed the slashes are (one) the source for the wrong parsing of the warning/error lines by UEStudio.

No, what happens with replacing in script Embedded 60 Pin V3 by Embedded_60_Pin_V3, running the script again, making same changes also on name of this directory in Windows Explorer, and double clicking on warning/error lines in output window?

Does eliminating the spaces in directory name solve the parsing problem?

Yes, replace the backslashes in script in file paths back to slashes and check if the warning/error lines can be still correct parsed by UEStudio if there are no spaces in file path.

So with this little script you can check what works and what is problematic and then we can look on how to get the output of compiler directly in a format correctly parsed by UEStudio.