Direct path in generated code
조회 수: 2 (최근 30일)
이전 댓글 표시
In the generated C code for the embedded platform I can see direct paths to files on the host computer, for example (pName):
/* Variable Definitions */
static rtDoubleCheckInfo l_emlrtDCI = { 57,/* lineNo */
34, /* colNo */
"file_name1", /* fName */
"Q:\\Matlab\\Source\\file_name1.m", /* pName */
4 /* checkKind */
};
static rtBoundsCheckInfo je_emlrtBCI = { -1,/* iFirst */
-1, /* iLast */
32, /* lineNo */
27, /* colNo */
"array_of_data", /* aName */
"file_name2", /* fName */
"Q:\\Matlab\\Source\\file_name2.m", /* pName */
0 /* checkKind */
};
static rtRunTimeErrorInfo w_emlrtRTEI = { 20,/* lineNo */
15, /* colNo */
"function1", /* fName */
"C:\\MATLAB\\R2017b\\toolbox\\eml\\lib\\matlab\\datafun\\private\\function1.m"/* pName */
};
I am little cofusing why these paths, inaccessible on tle embedded platform, are placed in the C source code. How to prevent generation of these paths or, if it is possible, how to explain their necessity?
Best regards
Artur
댓글 수: 1
Walter Roberson
2019년 11월 12일
It appears to be information for debugging purposes that is used to generate error messages if various kinds of checking fail, such as array index out of range. It is probably possible to disable to some kind of bounds checking.
채택된 답변
Denis Gurchenkov
2019년 11월 12일
Hi Arthur, the bottom line:
- These paths are there because you configured MATLAB Coder to produce C code with runtime error checks. If you change the configuration (set the config parameter "RuntimeChecks" to false) the paths would disappear.
- These paths dont' need to be accessible on the target platform. If you see how they are used, they are only used to print an error message for you (see rtErrorReportLocation() function in the generated yourproject_rtwutil.c file).
Details: In MATLAB programming language, there are many operations that can fail with an error. For instance, indexing into a 3x1 array with an index value of 10 causes an error. When MATLAB Coder converts MATLAB source to C, it has a choice, what to do with those erroneous situations. It can either ignore those (assume that errors would never happen) or introduce runtime checking code that checks for those errors and prints some mesage.
You (the user) control what coder is going to do. For that, there is a config parameter:
cfg = coder.config('lib');
cfg.RuntimeErrors = true; % or false
codegen ..... -config cfg....
If you elect to genreate code with runtime checks, there will be error reporting functions in the file whose name ends with "_rtwutil.c" in the generated code. Those functions are called to check for various errors, and all these functions, when an error condition is true, they print to console the location of the source MATLAB code that is associated with the error, and then call abort().
Take a look at the _rtwutil.c file, it is self-explanatory, and you'll see how the absolute paths are used there.
댓글 수: 0
추가 답변 (0개)
참고 항목
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!