[llvm-dev] XRAY_OPTIONS variable does not enable FDR mode and log flushing

[Dean Michael Berris via llvm-dev]

> On 12 Jun 2018, at 07:49, Henry Zhu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello,
> 
> 
>  
> Setting the xray_mode to xray-fdr in XRAY_OPTIONS does not enable FDR mode. Under Flight Data Recorder Mode in the docs (https://llvm.org/docs/XRay.html), it mentions that “ To use FDR mode on your application, you may set the xray_mode variable to xray-fdr in the XRAY_OPTIONS environment variable.”
> 
> I will demonstrate below with output generated from setting the flag
> 
>  
> I am running Ubuntu 16.04.1 on a x86_64 machine and am using clang 7.0.
> 
> henry at OptiPlex-9010:~$ uname -a
> 
> Linux OptiPlex-9010 4.13.0-43-generic #48~16.04.1-Ubuntu SMP Thu May 17 12:56:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> 
>  
> The test file I will be using is arg1-arg0-logging.cc from the TestCases/Posix directory. I will include the file as an attachment as well.
> 
>  
> Steps taken:
> 
> henry at OptiPlex-9010:~/build_xray/llvm-instrumented-build/bin$ ./clang++ -fxray-instrument -std=c++11 arg1-arg0-logging.cc
> 
>  
> Running with xray-fdr mode enabled:
> 
>  
> henry at OptiPlex-9010:~/build_xray/llvm-instrumented-build/bin$ XRAY_OPTIONS="patch_premain=true verbosity=1 xray_mode=xray-fdr" ./a.out
> 
> hello, arg0!
> 
> hello, arg1!
> 
>  
>  
> Running with basic-mode enabled:
> 
>  
> henry at OptiPlex-9010:~/build_xray/llvm-instrumented-build/bin$ XRAY_OPTIONS="patch_premain=true verbosity=1 xray_mode=xray-basic" ./a.out
> 
> ==13229==XRay: Log file in 'xray-log.a.out.dpsGGd'
> 
> hello, arg0!
> 
> hello, arg1!
> 
> ==13229==Skipping buffer for TID: 13229; Fd = 3; Offset = 0
> 
> ==13229==Cleaned up log for TID: 13229
> 
>  
> As shown above, setting the xray_mode=xray-fdr does not initialize or produce any logs. The documentation states that setting this variable would enable fdr mode, but nothing from the output indicates that.
> 

Can you say whether you’re doing this against HEAD?

We’ve recently made changes to make it so that installing FDR mode will actually initialise it. We’ve also made it so that the configuration options for FDR mode are in `XRAY_FDR_OPTIONS` along with the `XRAY_OPTIONS` environment variable.

>  
> Instead, I enabled xray-fdr programmatically, but it does not produce a trace even when the program terminates. I have to call __xray_log_finalize and __xray_log_flushLog() to produce a trace. Shouldn’t XRay in FDR mode produce a trace when the program terminates like basic mode does?
> 

It could, but it currently doesn’t.

As I mentioned in the other email you sent, it’s a little tricky to do this automatically for any mode currently selected, but it’s not impossible to do.

>  
> XRay reports that fdr-mode is initialized, but when the program is finished executing, the logs are not flushed to a trace file. I would expect fdr-mode to flush like basic-mode does when before a program terminates, but it does not do so unless __xray_log_finalize and __xray_log_flushLog are called before program termination.
> 

That’s a reasonable expectation. We could certainly implement something like that which will work for all XRay modes.

> 
> 
>  
> Now, the log is generated. It seems a bit odd to me that setting xray_mode=xray-fdr does not enable fdr mode as stated in the documentation. In addition, one has to manually configure the program to initialize fdr-mode and flush its buffers before program termination. Is there a reason for fdr mode to be setup this way? Is it possible to enable fdr mode and flushing to logs by setting xray_mode=xray-fdr?
> 

The reason it’s implemented this way, is to explicitly support the use-case of programmatically controlling when FDR mode starts and ends. We haven’t prioritised the use-case of wanting to get FDR mode traces at program termination.

I admit the naming is a little misleading, given that flight data recorders usually work best looking at “just before unusual termination” conditions. Like mentioned in the other email, it’s not impossible to add this capability as well.

Cheers

-- Dean