Please note: The UDK Feature Supplement, Version 7.1.1b is no longer supported on UnixWare 7 systems. It has been superceded by the Open UNIX Development Kit Version 8.0.0 (OUDK) which is the latest complete update of the UDK for UnixWare 7 and Open UNIX 8 systems and is included in the Open UNIX 8 Release 8.0.0 media kit.
These notes describe the UnixWare and OpenServer Development Kit Feature Supplement Release 7.1.1b.
The UnixWare and OpenServer Development Kit, or UDK, is the software development kit that accompanies the UnixWare® 7 product, and that gives you the ability to create a single binary that will run on other SCO operating system platforms as well.
This Feature Supplement is a partial upgrade (not a full replacement) to the full UnixWare and OpenServer Development Kit for UnixWare 7 Release 7.1.1 product.
Accordingly, these notes only describe those areas that are different in the Feature Supplement. For the Release Notes to the underlying base UnixWare and OpenServer Development Kit, see the SCOhelp UnixWare 7 documentation at http://uw7doc.sco.com under "Late News" and then "Release 7.1.1 Software development notes".
This UDK Feature Supplement is supported for installation, development use, and runtime execution of built applications on the following platforms:
The UnixWare and OpenServer Development Kit is a set of tools, libraries, header files and other files. It can be thought of as having two basic sets of components: compile-time components, those files necessary when you are creating a binary; and runtime components, those files needed by the binary you created when it is loaded and run. The compile-time components are the tools, like the compiler, assembler, optimizer, linker, header files and libraries. Runtime components consist mostly of shared libraries, but also include certain configuration files and tools such as debuggers. Some of these files, like shared libraries, are needed at both compile and runtime. In fact, since the UDK tools are themselves binaries built by the UDK, all of the runtime components must be present on the system for the compile-time tools to work.
For a ``universal'' binary to be able to run on SCO OpenServer Release 5, the appropriate runtime components of the UDK must be installed on the target platform. These components provide a compatibility layer that allows the UDK binary to interact correctly with the native system. This compatibility layer is called the UDK Compatibility Module for SCO OpenServer; the package name is OSRcompat.
The UDK Feature Supplement consists of upgrades of both the compile-time and the runtime components of the UDK. This is what you need if you will be developing applications on a system using this new UDK release.
A small subset of the UDK Feature Supplement, the UDK Runtime Feature Supplement Release 7.1.1b, is also available. This contains only those runtime components necessary to execute binaries created with the UDK Feature Supplement (on UnixWare 7.1.1 this updates a few system libraries; on SCO OpenServer 5 this updates package OSRcompat). This is what you need if you are only executing a UDK Feature Supplement-built application on a system, and if that application contains any calls to "new" library functions (relative to the base UnixWare 7.1.1).
If your application is only calling "existing" library functions that were in UnixWare 7.1.1, then it is possible to link your application such that no UDK Runtime Feature Supplement need be installed on the execution system.
The runtime component of the UDK Feature Supplement, and the UDK Runtime Feature Supplement, contain support for UnixWare 7 NonStop Clusters Release 7.1.1+IP; you do not have to obtain a separate version if you are running a NonStop Clusters system.
If you are interested in keeping up with the latest tools and information about developing software on or for SCO, we invite you to consider the SCO Global Developer Program. You can join at no cost, and enjoy the benefits of special developer discounts on software and services, access to prerelease software, and other advantages of membership in the SCO developer technical community. For more information, visit the Developer Programs web site.
The UDK Feature Supplement Release 7.1.1b provides these new features over the base UDK 7.1.1:
std
const char* type
_init and
_fini sections;
identity command that
provides information about a particular location of memory
specified by an address, expression, symbol, or any value that can be
interpreted as a memory location;
signal
command has a new option -m to display the signal mask
of the debugged process or thread;
grab
command, in most cases, do
not need the user to specify the executable path and name when starting
to debug a core file; the -c option is optional in such cases;
create and
grab commands have
a new option -p which searches the user's PATH environment variable for the
executable;
The only items from the ISO/IEC 14882:1998
C++ standard not implemented in this UDK Feature Supplement
are: two-phase name binding in templates, partial specialization
of a class member template outside of the class definition,
the export keyword for templates, placement delete,
function-try-blocks, and support for multibyte characters in source.
The only items from the ISO/IEC 9899:1999 C standard not implemented in this UDK Feature Supplement are: variable-length arrays, complex and imaginary numbers, and some minor variances in the snprintf(3S) function and in some header name space issues.
See the cc(1) and CC(1C++) man pages for full details on items from the standards not implemented.
Finally, be aware that the new C keyword inline will only
be effective in inlining calls to the function it is specified for,
when the cc -O option is used.
Other UDK components remain unchanged from the previous 7.1.1 UDK release.
There are two kinds of application compatibility, binary and source, and two directions compatibility can exist in, forward and backward. The following sections will address each combination in turn.
Furthermore, this forward
compatibility exists at every binary level -- executables, dynamic
libraries, archive, and individual .o files. You can link
existing objects produced by the 7.1.1 UDK together with objects
produced by the UDK Feature Supplement, and the resulting executables
will run in an UDK Runtime Feature Supplement environment. Neither the
C application binary interface (ABI) nor the C++ ABI has been
incompatibly changed in this Feature Supplement release.
As explained in the Introduction, in general this requires installing the UDK Runtime Feature Supplement on the other system, and this runtime component is only available on UnixWare 7.1.1 and SCO OpenServer 5.0.5 and 5.0.6.
However, in some cases it may be possible to further extend the backward binary reach of UDK Feature Supplement-built applications. If the application is not using any of the new C and C++ library calls offered by the UDK Feature Supplement, then it may be possible to link the application in a way that it will successfully run on other, older SCO operating systems, such as SCO UnixWare 2 or prior versions of UnixWare 7 or SCO OpenServer 5, even if they do not have the UDK Runtime Feature Supplement installed. See Usage Notes below for more information on this.
inline or restrict
keywords as identifiers; such code will get compilation errors under
the UDK Feature Supplement C compiler.
The solution is simply to change
the identifier's name to something else, in every usage of that identifier.
For circumstances where this
is impractical or impossible (the latter could happen if a call was being
made to a third-party library function named inline or
restrict, and the source code to that library was not
available to change it), the cc command has a new -Xb
option. This option behaves like the existing
default cc -Xa option, except that inline
and restrict will be not be recognized as keywords.
Most C++ code accepted by the existing 7.1.1 UDK C++ compiler will
compile and execute correctly
under the UDK Feature Supplement C++ compiler. Most of the
changes in this release are due to the addition of the
C++ Standard Library, rather than to the
language. To provide both source and binary forward compatibility,
all of the existing pre-standard library classes and
headers, such as <iostream.h>,
<complex.h>, and <new.h>,
still exist in the global namespace in the UDK Feature Supplement
libC,
along with all of the new Standard Library in namespace std.
There is one standards-motivated language change in the UDK Feature Supplement C++ compiler that does tend to cause compilation errors in "real world" code that compiled under the 7.1.1 UDK C++ compiler. This is the elimination of "friend name injection" from the language. Oversimplifying a bit, this means that friend functions that do not have any arguments of that class type, or are referenced without arguments, need to have an explicit declaration outside of their class. [For the full story, see Stroustrup's The C++ Programming Language (Third Edition) pp. 279-280.] A simple example:
class A {
public:
friend int f(int);
friend int g(const A&);
friend int h(const A&);
...
};
// point X
void gork(A a) {
int i = f(3); // now ill-formed
int j = g(a); // still ok
void* pf = (void*)h; // now ill-formed because no args used
}
The solution is very easy: add non-friend declarations immediately after the class (at point X in the above example):
int f(int);
int h(const A&);
This would typically be done in the header file that contains the class definition. The code will then be conformant to the ISO standard.
The UDK Feature Supplement is currently available only by download from the SCO download site at http://www.sco.com/download/.
It is possible that the Feature Supplement will be incorporated into a future UnixWare 7 media release.
The UDK Feature Supplement
is available as three separately downloadable sets that are
in pkgadd installable data stream format.
These Release Notes are also available for download
in both text and html format.
One set, the UDK Feature Supplement, contains the UDK development packages being upgraded along with new runtime packages. The second set, the UDK Runtime Feature Supplement, consists of the runtime packages only. The third set, the UDK Documentation Feature Supplement, contains updated versions of the UDK documentation packages.
The sets use the pkgadd and pkgrm
commands for installation and removal.
(Set installation is only available on OSR5.0.5 systems after
the rs505a patch has been added.)
Distribution contents:
udknotes.htm and
udknotes.txt.
| Package Name | Version | Package Description | ||
|---|---|---|---|---|
| Updated versions of UDK packages: | ||||
| uccs | 7.1.1b | UDK Optimizing C Compilation System | ||
| ucplus | 7.1.1b | UDK C++ Compilation System | ||
| uedebug | 7.1.1b | UDK Enhanced Debugger | ||
| ustdcomps | 7.1.1b | UDK Standard Components | ||
| baseupd | 7.1.1b | Base Operating System Compatibility Update (OSR5 only) | ||
| udkman | 7.1.1b | UnixWare 7 man command for use on OpenServer 5.x (OSR5 only) | OSRcompat | 7.1.1b | UDK Compatibility Module for SCO OpenServer (OSR5 only) |
| New packages: | ||||
| sysheadfs | 7.1.1b | System Header Feature Supplement (UW7 only) | ||
| libcfs | 7.1.1b | Runtime C Library Feature Supplement (UW7 only) | ||
| libCfs | 7.1.1b | Runtime C++ Library Feature Supplement (UW7 only) | ||
| libmfs | 7.1.1b | Runtime Math Library Feature Supplement (UW7 only) | ||
| Package Name | Version | Package Description | Updated versions of UDK packages: | |
|---|---|---|---|---|
| OSRcompat | 7.1.1b | UDK Compatibility Module for SCO OpenServer (OSR5 only) | ||
| New packages: | ||||
| libcfs | 7.1.1b | Runtime C Library Feature Supplement (UW7 only) | ||
| libCfs | 7.1.1b | Runtime C++ Library Feature Supplement (UW7 only) | ||
| libmfs | 7.1.1b | Runtime Math Library Feature Supplement (UW7 only) | ||
| Package Name | Version | Package Description | Updated versions of UDK packages: | |
|---|---|---|---|---|
| BASEman | 7.1.1b | UnixWare Manual Pages | ||
| UDKdoc | 7.1.1b | UnixWare/OpenServer Development Documentation (UW7 only) | ||
Note that many of the packages in the base 7.1.1 UDK are not included in this Feature Supplement; these include those dealing with software packaging tools, graphics development, and desktop applications development. The base 7.1.1 UDK contains the most recent versions of these packages.
Also, there are no Java packages in this Feature Supplement. The most recent Java Development Kit and Java Runtime Environment packages for SCO platforms can be downloaded from the SCO download site at http://www.sco.com/download/.
The UDK Feature Supplement documentation updates are contained within the BASEman and UDKdoc packages in the UDK Feature Supplement documentation set, udkdocfs.
When installed on a UnixWare 7.1.1 system, documentation is available from the SCOhelp on-line help system.
The SCO OpenServer SCOhelp system cannot display the UnixWare 7.1.1 documentation. OpenServer users should see the SCO documentation website, which contains the latest version of UnixWare 7 on-line documentation.
To access the UDK documentation from these sources, select Software Development from the list of topics.
To access UnixWare 7 manual pages from the command line on SCO OpenServer systems, see ``UnixWare 7 manual pages on SCO OpenServer and SCO UnixWare Systems''.
When you install the UDK documentation on SCO OpenServer, the UnixWare 7 manual pages (BASEman) are loaded into a parallel manual page directory. Use udkman to view the UnixWare 7 manual pages, and continue to use man to view the SCO OpenServer manual pages. The UDK compatibility modules must be installed before the udkman package.
As noted above, the UDK Feature Supplement sets install on:
Note that the Feature Supplement will not install on earlier UnixWare 7 or SCO OpenServer 5 releases, nor can it be installed on any SCO UnixWare 2 release.
Unfortunately, it is possible to install various packages in combination with the UDK Feature Supplement packages and end up losing some or all of the UDK Feature Supplement. The general rule is that the UDK Feature Supplement packages should be installed after any older packages. We suggest the following order of package installs to eliminate such potential problems.
For UnixWare 7, first get to either UnixWare 7 Release 7.1.1 or UnixWare 7 NonStop Clusters Release 7.1.1+IP (do not upgrade to NonStop Clusters after installing the UDK Feature Supplement). Then, if you want the entire UDK to be available along with the UDK Feature Supplement, the 7.1.1 UDK should be installed. (This is entirely optional -- the UDK Feature Supplement does not require the 7.1.1 UDK to be present.) At this point you may well see a suggestion to reinstall the Update 7.1.1 package, if so, install it now. (The Update 7.1.1 package may have some newer versions of some parts of the 7.1.1 UDK.) Next, you may well wish to install any PTFs, and/or any "maintenance set" bundling of PTFs. It is important that no older PTFs or the 7.1.1 UDK be installed after the UDK Feature Supplement since any of these can overwrite some or all of the files included in the UDK Feature Supplement.
Note that if you want to install UnixWare 7 NonStop Clusters Release 7.1.1+IP on a system that already has the UDK Feature Supplement installed, you will first have to remove the Feature Supplement. However, installation of the NonStop Clusters (NSC) package requires the UDK Optimizing C Compilation System (uccs) package to be installed. You will therefore have to install the 7.1.1 version of the uccs package, that is available in the UW7 Release 7.1.1 distribution (either from the Installation or the UDK CD), after removing the UDK Feature Supplement and prior to installing the NSC package.
For SCO OpenServer 5, first decide if you want the entire UDK to be available along with the UDK Feature Supplement, if so, install the 7.1.1 UDK. This is optional just as in UnixWare 7. Then, decide whether you wish to install any PTFs or the like. Again, it is important that the 7.1.1 UDK or older PTFs not be installed after the UDK Feature Supplement since its files can be overwritten.
At this point you can safely install the UDK Feature Supplement package(s).
If after the UDK Feature Supplement is installed, you find that you wish to install either the rest of the UDK or any older PTFs, you must remember to reinstall the UDK Feature Supplement package(s) after these have been installed to recover any overwritten files.
In general the same system requirements exist for upgraded packages in the UDK Feature Supplement as for those in the base 7.1.1 UDK. The minimum disk requirements for the packages in the UDK Feature Supplement are given in the tables below. The unlabeled numbers are 512-byte blocks (1/2 of a kilobyte, which is 1024 bytes).
| udkfs | 273 |
| libCfs | 1017 |
| libcfs | 1092 |
| libmfs | 268 |
| sysheadfs | 399 |
| uccs | 21790 |
| ucplus | 9905 |
| uedebug | 5293 |
| ustdcomps | 2259 |
| Total | 42296 blocks (21Mb) |
| udkrtfs | 190 |
| libCfs | 1017 |
| libcfs | 1092 |
| libmfs | 268 |
| Total | 2567 blocks (1Mb) |
| udkdocfs | 137 |
| BASEman | 60198 |
| UDKdoc | 30831 |
| Total | 91166 blocks (44Mb) |
| udkfs | 326 |
| OSRcompat | 23384 |
| baseupd | 8124 |
| uccs | 21790 |
| ucplus | 9905 |
| uedebug | 5293 |
| ustdcomps | 2259 |
| udkman | 88 |
| Total | 71169 blocks (34Mb) |
| udkrtfs | 190 |
| OSRcompat | 23384 |
| Total | 23574 blocks (11Mb) |
| udkdocfs | 137 |
| BASEman | 60198 |
| Total | 60335 blocks (31Mb) |
| udkfs | 266 |
| udkrtfs | 190 |
| udkdocfs | 137 |
| baseupd | 8124 |
| libCfs | 1017 |
| libcfs | 1092 |
| libmfs | 268 |
| sysheadfs | 399 |
| uccs | 21790 |
| ucplus | 9905 |
| ustdcomps | 2259 |
| uedebug | 5293 |
| udkman | 88 |
| BASEman | 60198 |
| UDKdoc | 30831 |
| 23384 | 23395 |
The UDK Feature Supplement does not require the base 7.1.1 UDK to be installed prior to installation. The development, runtime and documentation parts of the UDK that were upgraded in the UDK Feature Supplement are provided as complete packages and can therefore either be installed over the 7.1.1 versions or freshly installed. A suggested order of package installs is given above.
To install the UDK Feature Supplement you can choose any of the three UDK FS sets to download. Once you have downloaded the product files from the Download page, perform the following steps as root:
mv udkfs.image.Z /tmp or
mv udkrtfs.image.Z /tmp
cd /tmp
uncompress *.Z
pkgadd -d /tmp/udkfs.image
pkginfo OSRcompatIf an older version is already installed, then you can simply install the udkfs as described above being sure to select OSRcompat from the installation menu. If no OSRcompat pacakge is installed, you can type the following to extract and install it from the udkfs set:
pkgadd -d /tmp/udkfs.image OSRcompat
Only the System Header (sysheadfs) and the Runtime Library packages that are part of the UDK Runtime Feature Supplement will restore the system to its state prior to installation. That is, they save the current versions of all system headers and runtime libraries, which will then be restored upon removing those packages. The development packages will not save the earlier versions of the package; if any of them are removed, you will have to reinstall the earlier version.
Note: The runtime packages, libcfs, libmfs, libCfs and OSRcompat, are part of both the UDK Runtime Feature Supplement set (udkrtfs) and the UDK Feature Supplement set (udkfs). If you have installed both sets and then decide to remove the development packages by removing the udkfs set, all of the runtime packages that were installed with the udkrtfs will also be removed. However, the udkrtfs set itself, meaning all of the udkrtfs packaging files, will remain on the system. That is, if you type
pkginfo udkrtfsyou will see a message indicating that the set is installed, but no package names will appear. If in fact you want the runtime packages and set removed, enter:
pkgrm udkrtfsThis will remove the udkrtfs set files. Because of package dependencies, you will not be able to remove the runtime set (udkrtfs) without first removing the development/runtime set (udkfs).
The UDK Feature Supplement can be used to produce binaries that can be executed on both UnixWare 7.1.1 and SCO OpenServer 5.0.5 and 5.0.6, when the UDK Runtime Feature Supplement is installed on any of those platforms. To take advantage of this capability, you must:
See the following sections for detailed usage notes:
As explained in the version 7.1.1 UDK Release Notes, the archive library
libcudk70.a is used to allow applications built on later releases
of UnixWare 7, to execute on earlier releases of UnixWare 7. The library
contains all of the symbols that have been moved
from the archive part of libc in the original UnixWare 7.0.0
release, into the shared part of libc for later releases.
This library continues on in the UDK Feature Supplement, and now includes the following new, additional symbols relative to UnixWare 7.1.1 (each symbol is in the library both with and without a leading underscore):
bcmp bcopy bgets bufsplit
bzero copylist copylist32 copylist64
drand48 ecvtl endspent erand48
fcvtl ffs fgetspent finite
finitel fpclass fpclassl fpgetmask
fpgetround fpgetsticky fpsetmask fpsetround
fpsetsticky gcvtl getspent getspnam
index insque isencrypt jrand48
lckpwdf lcong48 lrand48 mkdirp
mrand48 nrand48 p2close p2open
pathfind putpwent putspent remque
rindex rmdirp seed48 setspent
srand48 strcadd strccpy streadd
strecpy strfind strrspn strtrns
ulckpwdf unordered unorderedl wcswcs
Previously it has been said that you need to install the UDK Runtime Feature Supplement on any system where an application built by the UDK Feature Supplement is to execute, and in general this is true.
But, if you are not using any of the new C Standard Library or C++ Standard Library functions or classes (but were, say, using new language-only features), then it is possible to build your application using the UDK Feature Supplement in a way that does not require the UDK Runtime Feature Supplement to be installed on the execution system. To do this, link with these additional options:
This will force any of the functions moved to the dynamic part of-Bstatic -lm -Bdynamic -lcudk70
libc, and all of the now dynamic libm, to be linked
statically into the executable, thereby allowing it to run on
systems that do not have these new libraries.
Indeed, using this technique, it is possible to run applications built with the UDK Feature Supplement on older SCO operating systems that do not have the UDK Runtime Feature Supplement available for them, such as UnixWare 7 Release 7.0.1 or 7.1.0, SCO UnixWare 2.1.3 (with the UW2compat package installed), or SCO OpenServer 5.0.4 (with the OSRcompat package installed).
But of course in many cases the reason you will be installing and using the UDK Feature Supplement in the first place is that you want to make use of new library features, and so this approach wouldn't work.
To create an executable or shared object, use the CC
or cc command.
If any input object files contain C++ code, you must use the
CC command.
ld should be invoked directly only if the -r
option is used to create a relocatable object to be used in a later link
or a device driver.
One of the reasons why people used to need to invoke the linker directly,
in order to define their own _init and _fini sections in
C programs,
is now obviated by the addition in the UDK Feature Supplement
of the new cc -i option.
UDK-built binaries using the following components will not work on SCO OpenServer:
getutent library call
The dynamic linker provided with the UDK sometimes fails to identify the
target operating system of a binary (e.g., with binaries that have been
run through some versions of GNU strip). If SCO OpenServer binaries
that executed successfully before you installed the UDK fail to execute,
use the elfmark -t osr5 command to positively identify them as
SCO OpenServer binaries.
The graphical interface to debug will occasionally produce
the following message:
message pops up:
Invalid operation on running object p??This just indicates that your previous request from the GUI for that particular object (process) has not completed as yet and your current request has been ignored. This may occur when stepping through the source code very quickly, when the current machine is slow or the machine's system resources are under a heavy load.
The solution is to try again after a small pause.
When debugging C or C++ programs, the debugger may report errors of the type "Cannot get address for symbol X" where X is a symbol that does exist in the source code. The symbol X may have been removed by the compiler as it was determined to be unused. This can happen in C++ standard library code with instantiations of template static data members, for instance.
In debugging C++ programs, the debugger may show only partially demangled names when displaying members of virtual base classes. The name will usually be recognizable however.
In UnixWare 7 the online help for the graphical debugger is linked to the online documentation library for UnixWare 7. Therefore, the debugger online help does not work on SCO OpenServer systems.
Programs built for profiling (with cc -p or CC -p) that use
libthread will not work correctly. In this UDK Feature Supplement
release, attempts to use profiling together with the threads library
will be rejected as an error by the compile command.
Very large compilations, especially those involving complicated C++ template
usage, may create very large intermediate files during compilation, and
may result in /var/tmp running out of space. In some cases the
cc or CC command may not accurately diagnose this, and you
may instead get an error message due to a compilation component reading
a truncated input file (such as the assembler getting a syntax error).
The easiest solution to this is to set the TMPDIR environment to
some other file system with more available space, such as the one your
home directory is in. Alternatively, you can increase the size of
/var/tmp.
The C++ compiler may be unable to generate correct debugging information
in the situation where a file scope function is declared to be
inline after the function has been defined
(which is fairly uncommon).
Given the following example:
static int f_836W51(int i, int j, int k) { return (i+j+k); }
static int k_836W51 = 3;
inline int f_836W51(int i, int j, int k = k_836W51);
int a,b;
int result;
void foo() {
result = f_836W51(a,b);
}
CC -g
will result in undefined symbol diagnostics from the assembler:
There are several ways to work around the problem:$ /usr/ccs/bin/CC -g -c test.c UX:as: ERROR: (EOF):undefined name: ..D27 UX:as: ERROR: (EOF):undefined name: ..D26 UX:as: ERROR: (EOF):undefined name: ..D25 UX:as: ERROR: (EOF):undefined name: ..D23
inline
function declaration before the function definition:
static int k_836W51 = 3;
inline int f_836W51(int i, int j, int k = k_836W51);
static int f_836W51(int i, int j, int k) { return (i+j+k); }
inline
specifier to the function definition:
inline static int f_836W51(int i, int j, int k) { return (i+j+k); }
static int k_836W51 = 3;
inline int f_836W51(int i, int j, int k = k_836W51);
CC -g.
CC -Kno_inline.
CC -W0,-1s option.
The generated .s
file can be scanned for the undefined names reported by
the assembler. The lower numbered ..Dnnn
symbol will be a reference
to the function in question. An assembly comment preceding that reference
will contain the C++ mangled function name. The assembly source code
around the undefined ..D23 symbol in the above example is:
/ sym (5) = f_836W51__FiN21:
..D3.1:
.byte 0x56 / abbrev table index
.4byte ..D3.2-..dbg_info.b / DW_AT_sibling
.4byte ..D23-..dbg_info.b / DW_AT_abstract_origin
.4byte ..IN1 / DW_AT_low_pc
.4byte ..IN2 / DW_AT_high_pc
/ sym (7) = i:
..D3.3:
.byte 0x27 / abbrev table index
.4byte ..D25-..dbg_info.b / DW_AT_abstract_origin
.byte 0 / DW_AT_location DW_FORM_block1
$ echo "/ sym (5) = f_836W51__FiN21:" | c++filt / sym (5) = f_836W51(int, int, int):