[UR] added filename and line number to logs

[mateuszpn]

Added an option to print line number and filename in log file. When fileline:1 is specified in an environment variable describing log, e.g:

UR_LOG_LEVEL_ZERO="level:debug;flush:warning;fileline:1;output:file,juju-l0.log"

then every log entry will have source file and line added, like below:

ZE ---> zeInit(L0InitFlags) <unified-runtime/source/adapters/level_zero/common.cpp:141>

The significant changes are contained in the following files:

• ur_logger.hpp
• ur_logger_details.hpp
• ur_sinks.hpp
• CMakeList.txt

In the remaining files, the calls to the logger functions are replaced by macros (basically automatic change)

[hvdijk]

If the idea is that URLOG already includes the file name and line number, __FILE__ and __LINE__ should be removed here.

[mateuszpn]

Fixed

[hvdijk]

This doesn't quite look right now, if __FILE__ and __LINE__ are removed without also updating the format string to match, this cannot work, can it?

[lslusarczyk]

I think double FILE LINE is fine if one will set fileline:1, because

• default fileline is 0
• FILE from URLOG shortens path relatively to root, while FILE is a full path and one may want to 'grep' over each of them
• URLOG looks shorter in code and comply new standard of writing log statements

I would leave original code

    URLOG(ERR, "Not Implemented : {} - File : {} / Line : {}", __FUNCTION__,   \
          __FILE__, __LINE__);

@hvdijk ,
do we agree on that?

[hvdijk]

I disagree, File : {} / Line : {} was added to address a deficiency in the available logging, now that the standard logging will have it, there is no longer a need for it. If we want the ability to log full paths (I'm not sure that we do), we should implement that in URLOG, not work around it everywhere we use URLOG.

[lslusarczyk]

I see. OK. @mateuszpn , please just fix format string too (remove excesive {}).

[mateuszpn]

Yes, that's what I meant, it was my mistake to keep the braces. I am now running additional tests to find more problems like this.

@ldrumm did not follow up the discussion on his request, so the way of solving it remained unclear. His remaining comments are addressed.

[mateuszpn]

@intel/llvm-gatekeepers this is ready to merge

[sarnex]

We still need review from @intel/bindless-images-reviewers and @intel/unified-runtime-reviewers-opencl

[ldrumm]

@mateuszpn mateuszpn dismissed ldrumm’s stale review April 24, 2025 15:37

@ldrumm did not follow up the discussion on his request, so the way of solving it remained unclear. His remaining comments are addressed.

I believe I was perfectly clear. I don't think adding extra environment variables to shorten logging strings belongs in the library, and users are perfectly capable of reasoning about this or writing their own post-processors. Please don't dismiss me simply because I haven't resolved the discussion. I didn't resolve the discussion because

a) I didn't see your comment about it not working on MSVC since this thread now has a lot of email noise
b) I don't believe it is resolved

[lslusarczyk]

@mateuszpn mateuszpn dismissed ldrumm’s stale review April 24, 2025 15:37

@ldrumm did not follow up the discussion on his request, so the way of solving it remained unclear. His remaining comments are addressed.

I believe I was perfectly clear. I don't think adding extra environment variables to shorten logging strings belongs in the library, and users are perfectly capable of reasoning about this or writing their own post-processors. Please don't dismiss me simply because I haven't resolved the discussion. I didn't resolve the discussion because

a) I didn't see your comment about it not working on MSVC since this thread now has a lot of email noise b) I don't believe it is resolved

Dear @ldrumm,

Sorry, but I need you to precise solution you proposed.
Could you please answer my questions from #17684 (comment) ?

Do I understand correctly that you want unified runtime to print full file paths which existed on the machine which was used to create a binary? And do I understand correctly that you want to ask customers to write awk-like scipts that will shorten these paths if they want them to be related to unified runtime source tree only?

[mateuszpn]

@mateuszpn mateuszpn dismissed ldrumm’s stale review April 24, 2025 15:37

@ldrumm did not follow up the discussion on his request, so the way of solving it remained unclear. His remaining comments are addressed.

I believe I was perfectly clear. I don't think adding extra environment variables to shorten logging strings belongs in the library, and users are perfectly capable of reasoning about this or writing their own post-processors. Please don't dismiss me simply because I haven't resolved the discussion. I didn't resolve the discussion because
a) I didn't see your comment about it not working on MSVC since this thread now has a lot of email noise b) I don't believe it is resolved

Dear @ldrumm,

Sorry, but I need you to precise solution you proposed. Could you please answer my questions from #17684 (comment) ?

Do I understand correctly that you want unified runtime to print full file paths which existed on the machine which was used to create a binary? And do I understand correctly that you want to ask customers to write awk-like scipts that will shorten these paths if they want them to be related to unified runtime source tree only?

@ldrumm In our opinion, there is no reason to store the local directories of the build machine in an executable file or log them, and the cost is one symbol defined in CMakeList. We clearly have different views on the importance of this approach, but it is time to close this discussion nonetheless. Please be specific about your suggestion for resolving this issue, and I will follow it immediately.
Should I:
(1) Put the full paths in the logs without trimming?
(2) Truncate the paths in other ways? How?
(3) For lack of better ideas, leave the solution as is?
As the last reviewer, we hope you will answer promptly.