I'm profiling a kernel compiled (with debug and lineinfo) using the nvrtc library. In the profiling results, many of the samples are listed as being within __nv_nvrtc_builtin_header.h. However - there is obviously no such file on disk, and naturally (?) the NVIDIA Compute source view can't locate it.
My questions:
What is actually in the __nv_nvrtc_builtin_header.h?
Is it possible for me to view the contents of this mysterious header? (If it helps, assume the code I use to perform the compilation can be adapted/added to.)
What is actually in the __nv_nvrtc_builtin_header.h?
All the standard definitions you would otherwise get in the standard CUDA includes and internal toolchain/host compiler headers the toolchain automagically includes during compilation. Just all assembled into one huge file.
Is it possible for me to view the contents of this mysterious header?
The header is contained within the the nvrtc-builtins library, and you should be able to use the requisite library dump utility on your platform to view it. for example:
$ objdump -s libnvrtc-builtins.so
[snipped for brevity]
Contents of section .rodata:
0007a0 2f2a0a20 2a20436f 70797269 67687420 /*. * Copyright
0007b0 31393933 2d323031 36204e56 49444941 1993-2016 NVIDIA
0007c0 20436f72 706f7261 74696f6e 2e202041 Corporation. A
0007d0 6c6c2072 69676874 73207265 73657276 ll rights reserv
0007e0 65642e0a 202a0a20 2a204e4f 54494345 ed.. *. * NOTICE
0007f0 20544f20 4c494345 4e534545 3a0a202a TO LICENSEE:. *
000800 0a202a20 54686973 20736f75 72636520 . * This source
000810 636f6465 20616e64 2f6f7220 646f6375 code and/or docu
000820 6d656e74 6174696f 6e202822 4c696365 mentation ("Lice
000830 6e736564 2044656c 69766572 61626c65 nsed Deliverable
000840 73222920 6172650a 202a2073 75626a65 s") are. * subje
000850 63742074 6f204e56 49444941 20696e74 ct to NVIDIA int
000860 656c6c65 63747561 6c207072 6f706572 ellectual proper
000870 74792072 69676874 7320756e 64657220 ty rights under
000880 552e532e 20616e64 0a202a20 696e7465 U.S. and. * inte
000890 726e6174 696f6e61 6c20436f 70797269 rnational Copyri
0008a0 67687420 6c617773 2e0a202a 0a202a20 ght laws.. *. *
0008b0 54686573 65204c69 63656e73 65642044 These Licensed D
0008c0 656c6976 65726162 6c657320 636f6e74 eliverables cont
(probable EULA violations if I show more...)
Adding to #talonmies answer:
If you remove the objdump header lines, you can pass the actual dump lines through xxd -r to get the __nv_nvrtc_builtin_header.h text proper:
$ objdump -s --section=.rodata /usr/local/cuda/lib64/libnvrtc-builtins.so | tail --lines=+5 | xxd -r | sed -r '1s/^.*\//\//;' | less
/*
* Copyright 1993-2016 NVIDIA Corporation. All rights reserved.
*
* NOTICE TO LICENSEE:
*
* This source code and/or documentation ("Licensed Deliverables") are
* subject to NVIDIA intellectual property rights under U.S. and
* international Copyright laws.
*
* These Licensed Deliverables contained herein is PROPRIETARY and
* CONFIDENTIAL to NVIDIA and is being provided under the terms and
(the last sed removes some junk at the beginning of the 6th line - as for CUDA 11.6)
Related
For common elf binaries, one could use readelf -n <binary file> to get the unique build id as follows:
$ readelf -n matrix
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 30935f4bf2ea2d76a53538b28ed7ffbc51437e3c
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.2.0
yet for cuda binaries, aka cubin, readelf -n does not work. So how to get the unique id of a cubin? Or what's the unique id of a cubin?
For common elf binaries, one could use readelf -n to get the unique build id
That isn't strictly true. What you are referring to as the "build id" is the .note.gnu.build-id section of the elf header, which is populated by a specific feature of the gnu linker ld and (when enabled) creates some identifying bits for that notes field from the contents of the elf section. The resulting ID value isn't unique, in that two files containing identical code will hash to the same ID, as far as I am aware. If you use another linker, that field isn't populated (the LLD linker clang uses certainly didn't, last time I checked)
So how to get the unique id of a cubin? Or what's the unique id of a cubin?
There isn't one. The NVIDIA elf headers don't contain a .notes section and the resulting elf files are not linked with the GNU linker, they are linked with nvlink and that doesn't have the same ID functionality, to the best of my knowledge.
According to the documentation for plot(), I should be able to pass a format argument to control the style of the graph. However, Octave seems to be misinterpreting this as an incomplete property specification, rather than a format string:
$ octave-cli
GNU Octave, version 4.4.1
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type 'warranty'.
Octave was configured for "x86_64-pc-linux-gnu".
Additional information about Octave is available at https://www.octave.org.
Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html
Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.
1> t = linspace(0,5,1001);
2> plot(t, sin(pi*t), "g_;sin(πt)");
error: plot: properties must appear followed by a value
error: called from
__plt__ at line 90 column 15
plot at line 223 column 10
Am I doing something wrong or is this a bug?
Converting my comment into an answer as requested
From the documentation:
The fmt format argument can also be used to control the plot style. It is a string composed of four optional parts: "<linestyle><marker><color><;displayname;>"
where, valid linestyles are:
‘-’ Use solid lines (default).
‘--’ Use dashed lines.
‘:’ Use dotted lines.
‘-.’ Use dash-dotted lines.
Based on the above, you have two typos in the format string.
The first is that you used an 'underscore' (_) instead of a 'dash' (-) as your linestyle specifier.
The second is that you didn't 'enclose' the "displayname" in semicolons as the syntax expects; you only put the left semicolon but forgot the right one.
So the correct format string would be:
plot( t, sin( pi * t ), "g- ;sin(πt);" );
I am checking out the source of tcl 8.6.3 and like to see how the byte code works. But I cannot find where is command if compiled.
I looked at tclCompCmds.c, it has a bunch of commands, such as break, continue, etc., but I do not see command if.
Could you point me where is the compile routine of command if?
It is in generic/tclCompCmdsGR.c (function TclCompileIfCmd()).
BTW, while looking for the requested function I noticed that the division of command implementations by different source files doesn't strictly follow the scheme declared in the beginning of the two of them.
/*
* tclCompCmds.c --
*
* This file contains compilation procedures that compile various Tcl
* commands into a sequence of instructions ("bytecodes").
*
*/
/*
* tclCompCmdsGR.c --
*
* This file contains compilation procedures that compile various Tcl
* commands (beginning with the letters 'g' through 'r') into a sequence
* of instructions ("bytecodes").
*
*/
/*
* tclCompCmdsSZ.c --
*
* This file contains compilation procedures that compile various Tcl
* commands (beginning with the letters 's' through 'z', except for
* [upvar] and [variable]) into a sequence of instructions ("bytecodes").
* Also includes the operator command compilers.
*
*/
tclCompCmds.c doesn't state that it contains only part of the command implementations, but the other two files suggest that it should contain commands whose names start with 'a' through 'f'. However, as an exception, it also includes the implementation of the lmap command.
tclCompCmdsGR.c states that it contains implementations of command starting with 'g' through 'r'. However upvar and variable also belong to tclCompCmdsGR.c, but that is explicitly stated in the last file tclCompCmdsSZ.c, which, apart from that exception, hosts commands starting with 's' through 'z', as well as the ::tcl::mathop::* commands.
I have written an application in Tcl-Expect which spawns minicom and
sends and receives data via the serial port. Sometimes i see that the
application receives control characters along with human readable data.
A search on the internet tells me that the control characters are
nothing but the VT terminal codes. However i could not find a solution
to filter out the terminal codes.
I am attaching a sample of the expected buffer and the actual buffer.
Expected :-
Microsoft Windows [Version 6.2.9200](c) 2012 Microsoft Corporation. All rights reserved. C:\Windows\system32>
Actual:-
[1;1H[37m[40m [2;1H [3;1H [4;1H [5;1H [6;1H [7;1H [8;1H [9;1H [10;1H [11;1H [12;1H [13;1H [14;1H [15;1H [16;1H [17;1H [18;1H [19;1H [20;1H [21;1H [22;1H [23;1H [24;1H [1;1HMicrosoft Windows [Version 6.2.9200][2;1H(c) 2012 Microsoft Corporation. All rights reserved.[4;1HC:Windowssystem32>
You don't want to filter them out when doing the initial match; they're useful for ensuring that you get exactly what you want (a prompt/banner). But when you're extracting the sense, you most certainly do want to filter them out first. Luckily, it's fairly easy with regsub magic:
regsub -all {\u00AB\[[\d;]*[A-Za-z]} $expect_out(buffer) "" filtered
That replaces all escape sequences (ESC (\u00AB) followed by a bracket, any number of digits and semicolons, and a letter) in the Expect match buffer (pick something else if you have a better candidate) with the empty string, and then stores the result in the filtered variable.
In the opening page of the book of "Lisp In Small Pieces", there is a paragraph goes like this:
Based on the idea of "function", an idea that has matured over
several centuries of mathematical research, applicative languages are
omnipresent in computing; they appear in various forms, such as the
composition of Un*x byte streams, the extension language for the Emacs
editor, as well as other scripting languages.
Can anyone elaborate a bit on "the composition of unix byte streams"? What does it mean? and how it is related to applicative/functional programming?
Thanks,
/bruin
My guess is that this is a reference to something like a pipe under linux.
cal | wc
the symbol | it's what invokes a pipe between 2 applications, a pipe is a feature provided by the kernel so you can use pipes where the applications are written using this kind of kernel APIs.
In this example cal is just the utility that prints a calendar, wc is an utility that counts words, rows and columns in the input that you pass to it, in this case the input is the result of piping cal to wc which makes things easier for you because it's more functional, you only care about what each applications does, you don't care, for example, about what is the name of the argument or where to allocate a temporary file to store the input/output in between.
Without the pipes you should do something like
cal > temp.txt
wc temp.txt
rm temp.xt
to obtain pretty much the same information. Also this second solution could possibly generate problems, for example what if temp.txt already exists ? Following what kind of rationale you will tell to your script to pick a name for your temporary file ? What if another process modifies your file in between the 2 calls to cal and wc ?