Wednesday Jun 01, 2011

How to find Oracle Solaris Studio 12.2 & Sun Studio 8 thru 12 update 1 patches

  1. http://support.oracle.com/  and login
  2. Select the "Patches & Updates" tab
  3. Click the "Search" tab in the "Patch Search" box
  4. In "Patch Search" box, click on "Product or Family (Advanced Search)"
  5. Type "studio" in the "Product is" textfield and then select "Oracle Solaris Studio" or "Sun Studio".
  6. Select version of Studio in "Release is" drop-down menu
  7. Select your platform (e.g. Oracle Solaris on SPARC (32-bit), etc.)
  8.    To see them all select SPARC(64-bit), x86-64 (64-bit) and Linux x86-64
  9. Click the "+" button at the right end of the platform field
  10. Select, "Classification" for the "Select Filter" dropdown
  11. Select "General" for its value, instead of the default "any"
  12. Click the "Search" button"

Thursday Mar 24, 2011

C1X is coming

The C Programming Language Standard committee WG14 met in London last week to Resolve the Committee Draft (CD) Ballot Comments. These are the National Body comments on the CD of the third edition of the C Programming Language Standard known as C1X.

So what's new in C1X over C99?

  • conditional (optional) features (including some that were previously mandatory)
  • support for multiple threads of execution including an improved memory sequencing model, atomic objects, and thread-local storage (<stdatomic.h> and <threads.h>)
  • additional floating-point characteristic macros (<float.h>)
  • querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
  • Unicode characters and strings (<uchar.h>) (originally specified in ISO/IEC TR 19769:2004)
  • type-generic expressions
  • static assertions
  • anonymous structures and unions
  • no-return functions
  • macros to create complex numbers (<complex.h>)
  • support for opening files for exclusive access
  • removed the gets function (<stdio.h>)
  • added the aligned_alloc, at_quick_exit, and quick_exit functions (<stdlib.h>)
  • (conditional) support for bounds-checking interfaces (originally specified in ISO/IEC TR 24731−1:2007)
  • (conditional) support for analyzability
So when can we expect this new revision of the C Standard?

The next stage in the process of becoming a standard will be the production
of the Draft International Standard with a 5 month ballot for approval.
If all goes as well as WG14 expects, there will be a new C standard in 2012.

Tuesday Dec 19, 2006

Sun Studio Express Program December 2006 Build available


Sun Studio Express Program December 2006 Build available

Want a peek at the latest Sun Studio Compilers and Tools under development from Sun?

The Sun Studio Express Program provides the Sun developer community with an early look at new features and technologies of the Sun Studio Compilers and Tools.  The Sun developer community can assess the benefits of the most current compiler and tools innovations.  Through the Sun Studio forums, the Sun developer community can ask question and give feedback, long before they are released as products.

Wonder if the next revision of the Sun Studio Compilers is going to give your application a performance boost?  Now you can find out.

The December 2006 Build includes a new Integrated Development Environment (IDE). The new Sun Studio IDE is based on NetBeans 5.5.1 and adds many new features. It supports C and C++ projects, and includes appropriate project templates for applications, dynamic and static libraries, and projects with existing code. The IDE includes a C and C++ class browser. The powerful language-aware built-in editor supports code completion. This build also includes C, C++, and Fortran compilers for the Linux platform, and improvements to the previously released Data Race Detection Tool, which has been renamed the Sun Studio Thread Analyzer.

So go check out the Sun Studio Express Program at:
http://developers.sun.com/prodtech/cc/downloads/express.jsp

Some of the other features being introduces with the June 2006 Build include:

  • Sun C compiler accepts the attributes always_inline, noinline, pure, const, malloc and aligned are now supported by the __attributes__ clause.
  • Sun C++ compiler recognizes __typeof__ keyword, __alignof__ expressions, and extern template
  • All Sun compilers (C/C++/Fortran 95) generate DWARF 2 symbolic information on all platforms.
  • Thread Analyzer (formerly known as the Data Race Detection Tool)


Monday Dec 04, 2006

What About Binary Compatibility?

»What will happen if I try to run my application on a newer Solaris OS release?

»What will happen if I try to compile my application using one version of the Sun Studio compilers and link it with libraries compiled with earlier compiler versions?

Important questions to consider, and luckily both Solaris and the Sun Studio compilers guarantee a certain degree of binary compatibility between releases.

Here are some things to keep in mind

  • Binary Compatibility among versions of Solaris:
    Executables created with a supported compiler release on an earlier Solaris OS version will run on later Solaris OS versions. This is part of the Solaris binary compatibility guarantee. Such executables might need the Sun Studio runtime libraries that are part of the compiler with which the executable was created. For example, an executable created using Forte Devloper 6 update 2 on Solaris 2.6, along with the shared runtime libraries of Forte Developer 6 update 2, will run correctly without recompilation or relinking on Solaris 10.

  • Binary Compatibility among object files: 
    Libraries and object files created with an earlier release of a Sun Studio compile can be used when linking with a later versions of that compiler. When you link with a mixed set of object files and libraries created with different versions of the Sun Studio compilers, you must use the latest compiler that produced any of the object files or libraries being linked. For example, a shared object (.so) file created with an FD6u2 compiler can be used when linking with the Sun Studio 11 version of that same compiler.

    There are some important considerations for Fortran 95 with FD6u2:
    • If you compile with the -aligncommon option you should not mix object files produced by Forte Developer 6 update 2 Fortran 95 with objects produced by a later version of the compiler if the common blocks contain either derived types or variables typed with an explicit kind value.
    • Module information files generated by Forte Developer 6 update 2 release f95 compiler are not guaranteed to be compatible with future releases


Specific Questions I get often:


        »Can I compile my application on Solaris 10 and run it on Solaris 9 and Solaris 8?

No.  Might work, but since you compiled it on Solaris 10, it might also be using system interfaces that did not exist on Solaris 8 and 9 or have changed in Solaris 10.

        »Can I compile my application on Solaris 8 and run it on Solaris 9 and Solaris 10?

 Yes!  This is what binary compatibility is all about.  (See above)

        »Can I compile and build my shared library on Solaris 10 and use it on Solaris 9 and Solaris 8?

No.  Might work, but since you compiled it on Solaris 10, it might also be using system interfaces that did not exist on Solaris 8 and 9 or have changed in Solaris 10.

        »If I compile the code in my shared library using the Sun Studio 11 compilers, can my customers who are still using Forte 6 Update 1 compilers link with these shared libraries?

No.  You must always link with the same compiler used to create the newest objects in your application or library.  So, if Sun Studio 11 compilers are used to compile the code in a shared library, Sun Studio 11 compilers must be used when linking with that shared library.
 

Monday Nov 20, 2006

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 3 of 3)


Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:

  • Lawrence Crowl of Google gave a presentation on where C++ threads is going.
  • A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
  • Proposal to augment the interface of malloc, et al.
  • DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
  • DR review
  • TR24731, Part II, Bounds Checking via dynamic allocation.
  • We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.

Here are the details on Decimal Floating Point, Bounds Checking, and couple of DRs.

Details (Part III):

DTR 24732, Decimal Floating Point.

Discussion of the National Bodies comments on the draft were reviewed in detail.  This lead to some minor changes to the draft.  There will be a small review committee to incorporate these changes.  The WG14 convenor will then forward that draft to SC22 for final ballot.

IBM is the only company known to have hardward to support Decimal Floating Point at this time ...


TR24731, Part II, Bounds Checking. N1193 (Stoughton)

This document is a proposed Part II to TR24731, Bounds Checking via dynamic allocation.  There is no invention here. All of the functions already exist in implementations, particularly in POSIX.  The document is organized the same way as Part I.   The intent of this document is to provide programmers with an additional mechanism to address issues of buffer overflow, etc., as does Part I.  A key difference is that the mechanisms are via dynamic memory allocation, and heavily dependent on malloc.  There are some minor changes that need to be made, the document is still a working draft, but it has sufficient substance to be ready for CD registration.  Small editorial group to go over the document.


We went through all the open and under review DRs.  Those of interest to us include:

DR 329  (N1181) Math functions and directed rounding

The result is DBL_MIN\*DBL_EPSILON, a subnormal number. But, if the implementation does not support subnormal numbers, such as IBM S/360 hex floating-point, then it is either zero or DBL_MIN, depending upon the current rounding direction mode. Hence, the sentence "Thus, the remainder is always exact." in footnote 204 in C99+TC1+TC2 (N1124) is wrong. This problem also applies to remquo and fmod.

Issue for non-754 implementations.

remove the sentence from the footnote, move the rest of the edits to annex f, instead of section 7

DR 332  (N1194)  gets is generally unsafe

Committee consensus to have words crafted to deprecate gets. This is a political issue in response to lots of bashing of the committee being non responsive to the security issues. Which of course is not true, but WG14 wants to soften the rhetoric.

Proposed Technical Corrigendum:

Add to subclause 7.26.9 (future library directions for ):

The gets function is obsolescent, and its use is deprecated.

[Note: Rationale wording might be useful.] [Editorial note: add a forward reference to this from gets subclause 7.19.7.7.]

Reviewed state in Portland 10/06 Expedited, will include in TC3 pending results of the disposition of this DR (DR 332) by WG14


Tom Plum Report: Macro Regions Proposal

This effort is essentially in the 'stalled' proposal list within the Evolution Working Group (EWG) in C++ (WG21/J16).  Tom believes it solves real problems with the preprocessor.  There is opposition within this committee to changing the C Standard.

Sunday Nov 12, 2006

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 2 of 3)

 

Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:

  • Lawrence Crowl of Google gave a presentation on where C++ threads is going.
  • A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
  • Proposal to augment the interface of malloc, et al.
  • DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
  • DR review
  • TR24731, Part II, Bounds Checking via dynamic allocation.
  • We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.

Here are the details on augmenting the interface of malloc, modeling sequence points to aid C++ work on concurrency, and committee discussions on revising the C standard.

Details (Part II):

Tom Plum Report #2, WG21/N1085 C++ Proposal to augment the interface of malloc, et al.

WG21/N1085 is a proposal by Howard Hinnant. Ulrich wants to add alignment considerations to this C++ proposal.  POSIX is now using a function called posix_memalign() that seems suitable for the original proposal.  That function came from an X/Open function named memalign(). Some of the members of J11 believe a function of this sort would be useful for C as well. Ulrich expressed concern that C++ might put a different spin on this. Bill Plauger prefers that we not push this work on to C++.  Sees it as simply adding to layers of complexity.   It's not clear whether or not C++ will even ever adopt this. Bill Plauger sees it as low on the list of things to do.

After much debate and several straw polls we agreed to this Liaison Report

WG14 urges WG21 to incorporate into the next C++ revision ("C++0x"):

  1. The functions sizeof_alloc and resize_alloc from WG14/N1085 ("Proposal to augment the interface of malloc/free/realloc/calloc", by Howard Hinnant); and
  2. A function along the lines of posix_memalign - see www.opengroup.org/onlinepubs/000095399/functions/posix_memalign.html

Sequence Points


N1188 is a paper that explains the C language sequence point model, and may be suitable as an addition to the C99 rationale.  The difficulty seems to be in determining all the possible orderings of sequence point, which makes teaching it difficult.

Making use of the model here is important in providing liaison input to C++ for their concurrency model. We want to make sure our underlying model does not get broken by C++ concurrency. We have plenty of time to get this in the C99 rationale, but there is more urgency in nailing down our model for C++ concurrency.


Future of C - Ulrich Drepper

Ulrich believes that the state of C compiler development is such that the C Standard is well behind the technology being used by the community. Virtually all major C compiler developers have developed extensions to the language that go well beyond the Standard. We can either subsume ourselves to C++, or plan on revising the C Standard to adopt existing technologies.  Bill Plauger pointed out that our pace has been deliberate, and that adoption of C99 has been slow.  We probably should consider reopening the Standard soon, and look at adopting things like multi-treading, security features, and others.  Ulrich believes we should focus on existing practice, features that are in wide use, minimize the risk of standardizing features that no one will use.  Doug Gwyn believes that C will have longevity in embedded programming, but that if we work on a 5 year schedule we should probably consider starting now.  There are a number of things that C can probably do better than other languages. Round table discussion on whether or not we should consider revising the C Standard.  David Keaton believes that are real commercial needs that C can address, such as security.  General feeling that making a decision to revise the C Standard with a focus on existing practice would be a good thing. Many developers make use of extensions to the language, some do not.  Invention of new feature sets is not a good idea.  John Benito: No one is saying no. If we are going to do this we will need to work on our charter, and proceed from there.

The next step. John Benito (WG14 Convenor): We need to start putting a charter together that will define the scope a revision to the C Standard.  Tom Plum is in favor of using the wiki as a vehicle to propose ideas.  Bill Plauger suggests using a full day in London to process such a list.  Start by generating a list, filter it based on criteria, then let the world know what we are doing.  We are not ruling out proposals from the outside.

Friday Nov 03, 2006

October 23-27 meeting of ISO SC22 WG14, the C programming language committee (Part 1 of 3)

Highlights of the October 23-27 meeting of ISO SC22 WG14, the C programming language committee:
  • Lawrence Crowl of Google gave a presentation on where C++ threads is going.
  • A proposal for Sequence Points work for the C rationale.  This is in response to C++ threads work in understanding sequence points.
  • Proposal to augment the interface of malloc, et al.
  • DTR 24732, Decimal Floating Point headed for final balloting after some minor updates.
  • DR review
  • TR24731, Part II, Bounds Checking via dynamic allocation.
  • We also had a visitor this meeting, Ulrich Drepper from Red Hat, Ulrich talked about his perceptions of the future of C.  This lead to the main surprise of this meeting, committee sentiment to consider opening the C standard for another revision.
Details (Part I):

Here are the details on what Lawrence Crowl presented on where C++ threads is going ...

Lawrence Crowl gave a presentation on where C++ threads is going.  C++ is trying to make threads correspond to operating system threads, POSIX and Windows, but not cover all of the functionality. They will be heavyweight, preemptive, and independent. Not a replacement for existing Standards.  Presuming that all writes are available to all threads is not viable, and C++ wants to adopt a message memory model.

Sequencing has been redefined. Sequence points are gone. Relations are sequenced-before and indeterminately-sequenced.  A write-to and read-from a location that are not sequence-before and not indeterminately-sequenced results in undefined behavior.

The sequence rules have been extended to concurrency.  Relations are synchronizes-with and happens-before are based on acquire and release. Race conditions are defined. The existence of a race condition makes the program undefined.

A location is a non-bitfield primitive data object. Adjacent bitfields together constitute a single location, enables unsynchronized read-modify-write.

The C++ Committee decided there needs to be some compromised between the language and the hardware.  Ulrich has an opinion that needs to be communicated back to WG21 via liaison. He has been talking with Hans Boehm in WG21 about this and prefers to have the POSIX type binding for threads (pthreads).

Optimizers are affected. Some speculative writes and reads are no longer legal. Loops without synchronization may be assumed to terminate.

All threads observe the same sequence of values for an atomic type. Atomic operations acquire, release, both, and neither. Atomic types are struct, but could be primitive type. Operators are type generic macros in C. The default assignment operator for both C and C++ is wrong, and cannot be disable in C99. It can be disable in C++98, but doing so breaks C/C++ compatibility.  C++ has a template for making any type atomic.

The types are comprehensive over the important primitive types: atomic_flag, atomic_bool, atomic_integers, atomic_void_pointer.  Atomics may be compiled by both C and C++.  Atomic operations must be lock-free to be used in signals. A macro will indicate if a type is lock-fee. Atomic operations must be address-free if used between processes. If an operation is lock-free , it must also be address-free.  Sequential consistency is not settled, and can be affected by hardware design. Example: How to program 'total store order'. Experts doubt whether mortals can program effectively without a total store order.

Thread-local storage has been implemented by at least five vendors. Some have slightly different syntax. A new thread duration has been defined. Dynamic initialization and destruction of static-duration variables can be tricky.  Without implicit synchronization, there is the potential for data races. With implicit synchronization, there is the potential for deadlock.

The thread semantic model initiates a thread with a fork on a function call (semantically like pthreads). Join waits for the function to return.  Some open questions remain. Is there a test for ready for join? Is there a join with a timeout? Does join return a function value?

Mutexes provide mutual exclusion. The Standard (C++) will have a least a simple mutex, and may have read-write and reentrant mutexes. Conditional variables enable the monitor paradigm. Threads may wait on a conditional variable.

Thread termination is voluntary. Return form outermost function, likely to have some form of cooperative termination, possible have some for of synchronous cancellation (exists in Windows) and there is strong opposition to asynchronous cancellation.  Thread scheduling is limited.

Locks hold a mutex within a given scope.

Higher level primitives may be built on primitives such as tread pools, thread groups, parallel iterators, etc.

Further threads work is being prepared for inclusion in C++ TR2, which will follow the next revision of C++ scheduled for 2009.

I'll cover the other topics in some future postings


Monday Jul 24, 2006

Resolving problems creating reproducible binaries using Sun Studio Compilers



Certain flags (-g, -xipo, -xcrossfile) invoke features of the Sun
Studio Compilers and tools that must make static data global.  To avoid
namespace collisions, the data is globalized using a unique
globalization prefix.  The drawback of using a unique globalization
prefix is that the resulting object files will be different every time
the source file is compiled, even though the sources and compilation
options are identical.  So, if you compare the resulting object files
from two identical compilations they will differ.

If you are in an environment that requires the ability to reproduce
identical object files, this becomes a problem.

Both C and C++ have an undocumented flag (-xglobalstatic) that can be
passed to the compiler front-end which will force the use of a static
globalization prefix based on the source filepath, instead of the usual
algorithm that guarantees a unique prefix.  To pass the flag to cc use
the -W0 option as follows:

cc -W0,-xglobalstatic

To pass the flag to CC use the -Qoption ccfe option as follows:

CC -Qoption ccfe -xglobalstatic

The drawback to using the filepath to generate the globalization prefix
is the increased risk of a namespace collision at link time between
static data with the same name that has been globalized from two files
with the same filepaths.  Though rare it does occur more often than
using a randomly generated prefix.

If you do run into namespace collisions, you might need to assign
the globalization prefix.  For C this can be done with the
wizard option -W0,-xp<prefix>, for example:

-W0,-xp\\$XAqalkBBa5_D2Mo

For C++ this can be done with the wizard options
-Qoption ccfe -prefix -Qoption ccfe <prefix>, for example:

-Qoption ccfe -prefix -Qoption ccfe \\$XA0ZlkBtDTxEGkV.

Tuesday Jun 27, 2006

Linux Technology Preview, Build 24 - June 2006

Update: Sun Studio Compilers for Linux Technology Preview

We've just made Build 24 - June 2006 available for download visit:
http://developers.sun.com/prodtech/cc/downloads/tech_preview.jsp

Some of the features changes available in this update include:
  • OpenMP support for cc and f95
  • -xipo, whole-program interprocedural optimization
  • For Sun C and C++ compilers:
  • Thread local storate support
  • -fast command line macro now includes: -dalign -fns -nofstore -fsimple=2 -fsingle -xalias_level=basic -xtarget=native -xO5 -xregs=frameptr
  • suncc, sunCC, sunf90, sunf77, sunf95, sunc89, sunc99, sunas compiler driver nicknames
  • -m32 and -m64 flags specifying respectively, the ILP32 and LP64 address models
  • The -xMD, -xMF, -xMMD flags for controlling makefile dependency information
  • #include_next directive
  • aligned and visibility __attribute__ support in C
  • value returning blocks in C
  • __typeof__ support in C
  • Zero length arrays in C
  • C++ compiler: stlport4 and rw7 libraries

  • For Fortran compiler:
  • -fast command line macro now includes: -xO5 -xtarget=native -xprefetch=auto -dalign -fsimple=2 -fns=yes -ftrap=common -nofstore
  • interval arithmetic on Solaris Intel
  • CAUTION messages issued when using the same symbols that are defined in different modules.
  • Faster compilation time for source files with many constant values.
  • Intrinsic functions called with UNSIGNED arguments improved.

Monday Jun 26, 2006

Sun Studio Express Program June 2006 Build



Sun Studio Express Program June 2006 Build

Want a peek at the latest Sun Studio Compilers and Tools under development from Sun?  The Sun Studio Express Program provides the Sun developer community with an early look at new features and technologies of the Sun Studio Compilers and Tools.  The Sun developer community can assess the benefits of the most current compiler and tools innovations.  Through the Sun Studio forums, the Sun developer community can ask question and give feedback, long before they are released as products.

Wonder if the next revision of the Sun Studio Compilers is going to give your application a performance boost?  Now you can find out.

With the June 2006 Build, the Sun Studio Express Program is featuring the Data Race Detection Tool (DRDT), a cool new tool for datarace detection in OpenMP, threaded and parallel programs.  DRDT works with code written using the POSIX thread API, the Solaris Operating System(R) thread API, OpenMP directives, Sun parallel directives, Cray(R) parallel directives, or a mix of these.

So go check out the Sun Studio Express Program at:
http://developers.sun.com/prodtech/cc/downloads/express.jsp

Some of the other features being introduces with the June 2006 Build include:
  • For Sun C and C++ compilers
  • suncc, sunCC, sunf90, sunf77, sunf95, sunc89, sunc99, sunas compiler driver nicknames
  • -m32 and -m64 flags specifying respectively, the ILP32 and LP64 address models
  • The -xMD, -xMF, -xMMD flags for controlling makefile dependency information
  • #include_next directive
  • aligned and visibility __attribute__ support in C
  • value returning blocks in C
  • __typeof__ support in C
  • Zero length arrays in C
  • -xinstrument=datarace to support the cool new Data Race Detection Tool
  • For Fortran compiler:
  • interval arithmetic on Solaris Intel
  • CAUTION messages issued when using the same symbols that are defined in different modules.
  • Faster compilation time for source files with many constant values.
  • Intrinsic functions called with UNSIGNED arguments improved.
  • Improved backward compatibility with old F77 objects produced by the Sun WorkShop 6 update 2 compiler
  • Sun Performance Library:
  • major improvements in the performance of the Fast Fourier Transform software
  • Improved the performance of the Transpose routines : CTRANS, DTRANS, STRANS, ZTRANS.
  • Improved the performance and scalability of the Cholesky factorization routines: CPOTRF, DPOTRF, SPOTRF, ZPOTRF.
  • lock_lint a static data race and deadlock detection tool for C programs is now available on Solaris Intel
  • For the Analyzer:
  • analyzer and er_print have been enhanced to present data race detection information, ie. the Data Race Detection Tool.
  • collect and er_kernel command:
  • new -r option for collecting data-race-detection data
  • new -t option which specifies a time range for data collection
  • Function and instruction count data can be recorded using the collect -c on option
  • -P <pid> option, to attach to the process with the given PID, and collect data from it
  • -F flag for collecting data on descendant processes
  • -p <interval> may be prepended with a + sign to record additional data corresponding to dataspace profiling.

Thursday Jun 15, 2006

Report bugs on Sun Studio Compilers and Tools at bugs.sun.com


You can now report bugs on Sun Studio Compilers and Tools at bugs.sun.com.

Here is how:

  • Visit bugs.sun.com
  • Select "Report a Bug" under Bug Database list on the right hand side of the page.
  • Check the box under header "Submit a Bug", and click on button "Start a new Report"
  • Under \*Product/Category \*pulldown menu, you will see 8 entries for eight components under the main one "Sun Studio Compilers and Tools":
  • C Compiler
  • C++ Compiler
  • Fortran
  • Dbx
  • Performance Analyzer
  • IDE
  • Dmake
  • Other
 
You'll recieve an acknowledgment of your submital, and if accepted and entered into Sun's bug database an email with a Bug ID to track the issue with.

Check it out.

Comming soon, the ability to search for Sun Studio Compilers and Tools bugs at bugs.sun.com ...

Friday Jun 02, 2006

The real story on the cc command and the -xregs=frameptr option


Alas the Sun Studio 11 C User's Guide documentation about -xregs=frameptr and -fast expansion that includes -xregs=frameptr is incorrect to the point of being completely confusing.

http://docs.sun.com/source/819-3688/cc_ops.app.html Appendix B 2.16, Table B-5 -fast option description incorrectly list -fast on x86 as expanding to -xregs=no%frameptr.  That is not correct.  The -fast macro option on x86 expansion includes -xregs=frameptr.

Later in Appendix B at 2.129, near the end of the description of -xregs, exists the following incorrect sentence:

The x86 default is -xregs=no%frameptr unless you specify -fast or an optimization of -xO5 in which case -xregs=frameptr.

-xO5 has no effect what-so-ever on -xregs option.  The sentence should read:

The x86 default is -xregs=no%frameptr unless you specify the -fast macro option whose expansion includes -xregs=frameptr.

Unfortunately the cc man page also has the equivalent errors incorrectly showing -fast expanding to -xregs=no%frameptr, and claiming -xO5 implies -xregs=frameptr.



So to recap, here is an accurate description of -xregs=frameptr, and how the -fast macro expands for cc on x86/64:

-xregs=frameptr    Tells the compiler it is allowed to use the frame-pointer
                              register as an unallocated callee-saves register for purposes
                              of optimization.

-xregs=no%frameptr  Tells the compiler it is NOT allowed to use the frame=pointer
                                   register for purposes of optimization.

The x86 default is -xregs=no%frameptr unless you specify the -fast macro option whose expansion includes -xregs=frameptr.



-xregs=frameptr allow the compiler to use the frame-pointer register (%ebp on IA32, %rbp on AMD64) as an unallocated callee-saves register.  Using this register as an unallocated callee-saves register may improve program run time. However, it also reduces the capacity of some tools to inspect and follow the stack. This stack inspection capability is important for system performance measurement and tuning.  Therefor, using this optimization may improve local program performance at the expense of global system performance.
  • Tools, such as the Performance Analyzer, that dump the stack for postmortem diagnosis will not work.
  • Debuggers (e.g adb, mdb, dbx) will not be able to dump the stack or directly pop stack frames.
  • The dtrace performance analysis facility will be unable to collect information on any frames on the stack before the most recent frame missing the frame pointer.
  • Posix pthread_cancel will fail trying to find cleanup handlers.
  • C++ exceptions cannot propagate through C functions.
The failures in C++ exceptions occur when a C function that has lost its frame pointer calls a C++ function that throws an exception through the C function. Such calls typically occur when a function accepts a function pointer (for example, qsort) or when a global function, such as malloc, is interposed upon. The last two affects listed above may impact the correct operation of applications. Most application code will not encounter these problems.



Note some might also be confused by the following bullet item in the C man page ...

The documentation at the top of the cc man page about -xregs=no%frameptr is incorrect, it currently says:

     o A new x86-only flag for the -xregs option,
     -xregs=[no%]frameptr, lets you use the frame-pointer regis-
     ter as an unallocated callee-saves register to increase the
     run-time performance of applications.

This needs to be corrected to say:

     o A new x86-only flag for the -xregs option,
     -xregs=frameptr, lets you use the frame-pointer regis-
     ter as an unallocated callee-saves register to increase the
     run-time performance of applications.



Note the Sun Studio 10 C User's guide does not have these errors, i.e. it correctly describes -xregs=frameptr and -fast 

Monday May 22, 2006

C99 inline function and the Sun C Compiler


Note, the C standard says that inline is only a suggestion to the C compiler.  The C compiler can choose not to inline anything, and attempt to call the actual function.

The Sun C compiler does not inline C function calls unless optimizing at -xO3 or above.  And that inlining is done by the backends.  And then only if the backend's heuristics decide it is profitable to do so.  The Sun C compiler gives no way to force a function to be inlined.

For static inline functions it is simple.  Either a function defined with the inline function specifier is inlined at a reference or a call is made to the actual function.  The compiler can choose which to do at each reference.  The Sun C compiler decides if it is profitable to inline at -xO3 and above.  When not profitable to inline, or at an optimization of less than -xO3 a reference to the actual function will be generated.  If any reference to the actual function is generated the function definition will be generated in the object code.  Note if the address of the function is taken, the actual function will be generated in the object code.

Extern inline functions are more complicated.  There are two types of extern inline functions, an inline definition which never provides an extern (global) definition of the function and an extern inline function which always provide a global definition of the function.  To quote the C99 standard:
       [#6]  Any  function  with  internal linkage can be an inline
       function.   For  a  function  with  external  linkage,   the
       following restrictions apply: If a function is declared with
       an inline function specifier, then it shall also be  defined
       in  the  same  translation  unit.   If all of the file scope
       declarations for a function in a  translation  unit  include
       the  inline  function  specifier  without  extern,  then the
       definition in that translation unit is an inline definition.
       An inline definition does not provide an external definition
       for the function, and does not forbid an external definition
       in  another translation unit.  An inline definition provides
       an alternative to an external definition, which a translator
       may  use  to  implement any call to the function in the same
       translation unit.  It is unspecified whether a call  to  the
       function   uses   the  inline  definition  or  the  external
       definition.

       [#7] EXAMPLE  The declaration of  an  inline  function  with
       external   linkage   can   result   in  either  an  external
       definition, or a definition available for  use  only  within
       the  translation unit.  A file scope declaration with extern
       creates an external definition.  The following example shows
       an entire translation unit.

               inline double fahr(double t)
               {
                       return (9.0 \* t) / 5.0 + 32.0;
               }

               inline double cels(double t)
               {
                       return (5.0 \* (t - 32.0)) / 9.0;
               }

               extern double fahr(double);     // creates an external definition

               double convert(int is_fahr, double temp)
               {
                       /\* A translator may perform inline substitutions \*/
                       return is_fahr ? cels(temp) : fahr(temp);
               }

       [#8]  Note  that  the  definition  of  fahr  is  an external
       definition because fahr is also declared  with  extern,  but
       the  definition  of  cels  is an inline definition.  Because
       cels has external linkage and  is  referenced,  an  external
       definition  has  to  appear in another translation unit (see
       6.9); the inline definition and the external definition  are
       distinct and either may be used for the call.

So, for an inline definition, the programmer is required to supply an extern definition of the function in another translation-unit for references to the function that are not inlined.

For an inline definition, the compiler must not create a global definition of the function.  That means for any calls to that function, the compiler may use the inline definition or call a global function by that name defined elsewhere.  When we say the compiler may use the inline definition, that does not necessarily mean the compiler actually inlines the code. The compiler might also create a local function for the inline definition and call that local function.  For other references, i.e. taking the address of the inline function definition, the compiler should create references to a global function defined elsewhere.

For an extern inline function declared by a file scope declaration with the extern storage-class-specifier (i.e. the function definition and/or prototype), the compiler must provide a global definition of the function in the resulting object file.  The compiler can choose to inline any references to that function seen in the translation unit where the function definition has been provided, or the compiler can choose to call the global function.  Implementation note: The global function created by the compiler is placed in a comdat sections. You can have multiple global symbols in comdat and the linker only chooses one.  This is compatible with C++ use of comdat.  Without the inline keyword an extern function definition is not placed in comdat and a the linker will complain if there are duplicate global symbols with the same name.

The behavior of any program that relies on whether or not a function call is actually inlined, is undefined.

Note also an inline function with external linkage may not declare or reference a static variable anywhere in the translation-unit.

Definition of translation-unit: A source file and all of its includes, recursively.

Like it does for static functions, the Sun C compiler decides if it is profitable to inline a reference to an inline definition or an extern inline function at -xO3 and above.  When not profitable to inline, or at an optimization of less than -xO3 a reference to the global function will be generated.  Likewise a reference to the address of the function is always a reference to the global function.

The rules for C++ differ: a function which is inline anywhere must be inline everywhere and must be defined identically in all the translation units that use it.

gcc

The GNU C rules differ and are described in the GNU C manual, which can be found here http://gcc.gnu.org.

  • A function defined with inline and without either extern or static keywords, will always cause a global function to be emitted.  gcc may inline references to the function within the object code for the translation-unit in which it appears.  And references to the function from other translation-units in the program will be satisfied by linking with this object code.
  • For a function defined with "extern inline" a global function is never emitted.  References to the function are either inlined or are made to a global function that must be defined somewhere else.
  • A function defined with "static inline" acts the same as C99.

Sun C compiler gcc compatibility for inline functions

To obtain behavior from the Sun C compiler that is compatible with gcc's implementation of extern inline functions for most programs, use the -features=no%extinl flag.  When this flag is specified the Sun C compiler will treat the function as if it was declared as a static inline function.

The one place this is not compatible will be when the address of the function is taken.  With gcc this will be an address of a global function, and with Sun's compiler the local static definition address will be used.

Monday May 08, 2006

Finding the canonical path to an executable


Below is a coding example of how an executable can determine the canonical path to itself on the file system.  Compiler drivers, like cc, CC, f95 need to do this in order to exec the component executables that compile a program.  For example, the compiler front-end, an optimizer, and a linker.

% cat findself.c
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

#ifndef MAXPATHLEN
#define MAXPATHLEN      1024
#endif

/* find_run_directory - find executable file in PATH
 * PARAMETERS:
 *      cmd     filename as typed by user
 *      cwd     where to return working directory
 *      dir     where to return program's directory
 *      run     where to return final resolution name
 * RETURNS:
 *      returns zero for success,
 *      -1 for error (with errno set properly).
 */
int
find_run_directory (char *cmd, char *cwd, char *dir, char **run)
{
    char                *s;

    if (!cmd || !*cmd || !cwd || !dir) {
        errno = EINVAL;         /* stupid arguments! */
        return -1;
    }

    if (*cwd != '/')
        if (getcwd (cwd, MAXPATHLEN - 1) == NULL )
            return -1;          /* cant get working directory */

    if (strchr (cmd, '/') != NULL) {
        if (realpath(cmd, dir) == NULL) {
            int lerrno = errno;
            if (chdir((const char *)cwd) == NULL)
                errno = lerrno;
            return -1;
        }
    } else {
#ifdef __linux__
        /* getexecname() not available on Linux */
        /* Note dir needs to be initialized with '\0' before
           being passed to readlink() which does not append
           a NULL terminator. */
        if (readlink("/proc/self/exe", dir, MAXPATHLEN) == -1) {
#else
        if (realpath(getexecname(), dir) == NULL) {
#endif
            int lerrno = errno;
            if (chdir((const char *)cwd) == NULL)
                errno = lerrno;
            return -1;
        }
    }

    s = strrchr (dir, '/');
    *s++ = 0;
    if (run)            /* user wants resolution name */
        *run = s;

    return 0;
}

char current_working_directory[MAXPATHLEN];
char run_directory[MAXPATHLEN];
char * run_exec_name = NULL;

int
main(int argc, char **argv)
{

    if ( !find_run_directory (argv[0],
                              current_working_directory,
                              run_directory, &run_exec_name) ) {
        (void)printf("argv[0] = %s\\n"
                         "cwd = %s\\n"
                         "run_dir = %s\\n"
                         "run_exec = %s\\n",
                     argv[0],
                     current_working_directory,
                     run_directory,
                     run_exec_name);
    } else {
        (void) printf("%s\\n", "Unaable to find run directory.");
    }

    exit (0);
}


% cc findself.c -O -o prod/bin/findself
% ls
bin         findself.c  prod
% ls bin
findself
% ls -laF bin
total 6
drwxr-xr-x   2 me      staff        512 Mar  5 10:37 ./
drwxr-xr-x   4 me      staff        512 Mar  5 10:37 ../
lrwxrwxrwx   1 me      staff         20 Mar  5 10:37 findself -> ../prod/bin/findself*
% ls -laF prod/bin          
total 22
drwxr-xr-x   2 me      staff        512 Mar  5 10:37 ./
drwxr-xr-x   3 me      staff        512 Mar  5 10:37 ../
-rwxr-xr-x   1 me      staff       8992 Mar  5 10:37 findself*
% bin/findself
argv[0] = bin/findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself
% prod/bin/findself
argv[0] = prod/bin/findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself
% setenv PATH /home/me/bin:${PATH}
% findself
argv[0] = findself
cwd = /home/me/blog
run_dir = /home/me/blog/prod/bin
run_exec = findself

Monday May 01, 2006

Special Math Functions Draft Technical Report


There were three major items to come out of the Berlin ISO C standard committee meeting which will move forward in the process of becoming Technical Reports.
  • Decimal Floating Point DTR
  • Extensions to the C Library Part I: Bounds-checking interfaces DTR
  • Special Math Functions DTR
I talked about the Decimal Floating Point and Bounds-checking interface Draft Technical Reports in previous blog entries:  Decimal Floating Point Types & Managed Strings.

Today, I'll briefly mention the Special Math Functions DTR, which the committee also is moving forward through the SC22 registration process.  These are essentially the same functions being adopted by C++ in their library TR, tailored to the C language.  They include, among others:
  • Bessel functions
  • confluent hypergeometric functions
  • Neumann functions
  • Riemann zeta function
  • Legendre functions
For details of the functions in the draft have a look at the last committee draft:

http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n1051.pdf

During the committee discussions it was pointed out that the values computed with special math functions are very susceptible to ‘sensitivities’ based on the input values provided.  Outside of specific ranges, the values computed are essentially useless.  Thus, implementations of these functions are not likely to be nearly as robust as implementations of the C90, and C99 math libraries.  A few functions will likely be dropped from the TR in sync with those already dropped from the C++ TR.  WG14 will extract from the existing C++ TR, account for DRs that exist for the C++ TR, have a small editorial review committee review the document, and forward it to SC22 for registration.

Monday Apr 24, 2006

Linux Technology Preview #3


While in Berlin at the ISO C standards meeting Sun announced:

Linux Compiler Technology Preview (TP) #3

The announcement went out to the Sun Studio Forum for Linux users, here.
TP #3 has some interesting features:
  • Closer feature parity with Solaris/x86/64, with features like OpenMP, -xautopar, TLS, -xipo, -xprofile all work on Linux now.
  • And C++ is in much better shape.
Other than the usual 80/20 rule, i.e. we have 80% of the features working with 20% of the work, the only significant component of the Sun Studio compilers yet to be ported to Linux is the Sun Performance Library.

For more details see the SunStudio for Linux Forum where you can download the latest version.

You might also want to have a peek at the C/C++ Development NetBeans project

Tuesday Mar 28, 2006

Avoiding Programming Language Vulnerabilities


This week I am in Berlin at a meeting of the ISO/SC22/WG14, the C programming language committee, in Berlin.  One of the hottest topics are dealing with programming security issues and integerity systems.

JTC 1/SC 22 has created a new project to deal with the subject of vulnerabilities in programming languages. The basic technical concept is that all programming languages contain features that are poorly specified, difficult to use correctly, or dependent upon particular implementations. In some cases, these features cause software codes to become vulnerable to malicious parties. The intent of the project is to create guidance on dealing with these problems. In some cases, the guidance will be generic across languages; in other cases the guidance will be specific to languages.
 
The project is being implemented in an unusual manner. SC22 has created an OWG ("Other Working Group") on Vulnerabilities. This group is convened by, Jim Moore, and the co-convener is John Benito.  Jim is the convener of WG9 (Ada) and John is the convener of WG14 (C); so they cover a wide range of programming language design. It is their intent to enlist experts from other working groups so that they can further broaden the range of expertise.   They also have permission to enlist experts from non-ISO languages, like Java.  Finally, of course, they need participants from national bodies.
 
The purpose of this blog is to encourage US participation.  Because an OWG is not-quite-a-working-group, I believe that the arrangements to participate in it are somewhat informal.

For more information about participating or contacting Jim Moore, have a look at the ISO/IEC JTC 1/SC 22/OWG:Vulnerabilities website http://aitc.aitcnet.org/isai/

I'll be on Vacation next week seeing some of Germany ... :-)

Monday Mar 20, 2006

Managed strings


I'm off to a meeting of the ISO/SC22/WG14, the C programming language committee meeting in a weeks.  Actually, I'm leaving today for a meeting with our my engineering team in St. Petersburg on my way to Berlin for the ISO/SC22/WG14, the C programming language committee meeting.  Another piece of work the committee has been working on for over a year now involves Mitigating Security Vulnerabilities.  This work is about to turn into a Draft Technical Report, currently titled:

Extensions to the C Library Part I: Bounds-checking interfaces

You can read more about it at:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf

there is a rationale at:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1147.pdf

This work has generated alot of interest.  One such area is dealing with the vulnerablilities of manipulating strings in C.  Robert C. Seacord of Carnegie Mellon University has submitted a paper to the committee with ideas on library routines to manage strings to mitigate these issues.  Below is the introduction from the paper, and a link to the full document.

Introduction

String manipulation errors

Many vulnerabilities in C programs arise through the use of the standard C string manipulating functions.  String manipulation errors include buffer overflow through string copying, truncation errors, termination errors and improper data sanitization.  Buffer overflow can easily occur when copying strings if the fixed-length destination of the copy is not large enough to accommodate the source of the string.  This is a particular problem when the source is user input, which is potentially unbounded.  The usual programming practice is to allocate a character array that is generally large enough.  The problem is that this can easily be exploited by malicious users who can supply a carefully crafted string that overflows the fixed length array in such a way that the security of the system is compromised.  This is still the most common exploit in fielded C code today.  In attempting to overcome the buffer overflow problem, some programmers try to limit the number of characters that are copied. This can result in strings being improperly truncated.  This, in turn, results in a loss of data which may lead to a different type of software vulnerability.

A special case of truncation error is a termination error.  Many of the standard C string functions rely on strings being null terminated.  However, the length of a string does not include the null character.  If just the non-null characters of a string are copied then the resulting string may become improperly terminated.  A subsequent access may run off the end of the string and corrupt data that should not have been touched.

Finally, inadequate data sanitization can also lead to vulnerabilities.  Many applications require data to be constrained not to contain certain characters.  Very often, malicious users can be prevented from exploiting an application by ensuring that the illegal characters are not copied into the strings destined for the application.

Proposed solution

A secure string library should provide facilities to guard against the problems described above. Furthermore, it should satisfy the following requirements:
  1. Operations should succeed or fail unequivocally.
  2. The facilities should be familiar to C programmers so that they can easily be adopted and existing code easily converted.
  3. There should be no surprises in using the facilities. The new facilities should have similar semantics to the standard C string manipulating functions.  Again, this will help with the conversion of legacy code.
Of course, some compromise is needed in order to meet these requirements.  For example, it is not possible to completely preserve the existing semantics and provide protection against the problems described above.

Libraries that provide string manipulation functions can be categorized as static or dynamic.  Static libraries rely on fixed-length arrays. A static approach cannot easily overcome the problems described. With a dynamic approach, strings are resized as necessary.  This approach can more easily solve the problems, but a consequence is that memory can be exhausted if input is not limited.  To mitigate against this issue, the managed string library supports an implementation defined maximum string length.  Additionally, the string creation function allows for the specification of a per string maximum length.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1158.pdf

Monday Mar 13, 2006

Decimal Floating Point Types


I'm off to a meeting of the ISO/SC22/WG14, the C programming language committee meeting in a couple of weeks.  One of the papers on the agenda (N1154) is a proposal for a Technical Report on adding Decimal Floating Point types and arithmetic to the C programming language specification.  The proposal is based on a model of decimal arithmetic which is a formalization of the decimal system of numeration (Algorism) as further defined and constrained by, IEEE-854, ANSI X3-274, and the proposed revision of IEEE-754 (known as IEEE-754R).

The proposal adds decimal floating point within the type hierarchy, as base types, real types and arithmetic types.  The three types are called:
  • _Decimal32
  • _Decimal64
  • _Decimal128
There is a new macro an implementation must define to indicate conformance to this technical report:
  • __STDC_DEC_FP__
The proposal introduces generic floating types the existing floating point types: float, double, and long double.  Together the generic floating point types and decimal floating types are known as the real floating types.

The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
  • _Decimal32 is a decimal32 number, which is encoded in four consecutive octets (32 bits)
  • _Decimal64 is a decimal64 number, which is encoded in eight consecutive octets (64 bits)
  • _Decimal128 is a decimal128 number, which is encoded in 16 consecutive octets (128 bits)
The details of the format are give in IEEE-754R.

New macros similar to those of <float.h> are defined in a new header <decfloat.h>.  For example, DEC_EVAL_METHOD, DEC32_MANT_DIG, DEC64_MANT_DIG, DEC128_MANT_DIG.  Prefixes of DEC32_, DEC64_, and DEC128_ are used to denote the types _Decimal32, _Decimal64, and _Decimal128 respectively.

Conversion from decimal floating type to integer is as you would expect, the fractional part is discarded (value truncation towards zero).  If the value cannot be represented by the integer type the result depends on the sign of the integer type.  If unsigned, and the result is positive, the largest representable number, otherwise 0.  If signed, the result it the most negative or positive number according to the sign of the floating point number.

For conversion from integer to decimal floating type, if the value being converted can be represented exactly, it is unchanged.  If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is correctly rounded.  If the value being converted is outside the range of values that can be represented, the result is positive or negative infinity depending on the sign of the value being converted, and the “overflow” floating-point exception will be raised.

For conversion between generic floating types and decimal floating types, the TR is similar to the existing ones for float, double and long double, except that when the result cannot be represented exactly, the behavior is tightened to become correctly rounded.

The TR does not add complex or imaginary decimal floating types.  However, it does add the equivalent rules for conversion between complex and imaginary types to decimal floating types as exist for conversion between generic floating types.

Determining the common type for mixed operations between decimal and other real types is difficult because ranges overlap, therefore mixed mode operations are not allowed and the use of explicit casts are required. Implicit conversions are allowed only for simple assignment and in argument passing.

There is no default argument promotion specified for the decimal floating types.

The new suffixes to denote decimal floating constants are: DF for _Decimal32, DD for _Decimal64, and DL for _Decimal128.

It would help usability if unsuffixed floating constant can be used to initialize decimal floating types.  For, example, 0.1 has type double and in implementations where FLT_EVAL_METHOD is not -1, the internal representation of 0.1 is not exact. This defeats the purpose of decimal floating types.  So the proposal introduce a translation time data type (TTDT) which the translator uses as the type for unsuffixed floating constants.  An unsuffixed floating constant is kept as a TTDT until an operation requires it to be converted to an actual type.  The value of the constant remains exact for as long as possible during the translation process.

The concept can be summarized as follows:
  • The implementation defines the type, including the limits on the constant that the type can represent exactly.  Probably the widest decimal floating type.
  • The range and precision of the type are implementation defined and are fixed throughout the program.
  • The type is an arithmetic type.  All arithmetic operations are defined for this type.
  • The Usual arithmetic conversion is extended to handle mixed operations between TTDT and other types.  If an operation involves both TTDT and an actual type, the TTDT is converted to an actual type before the operation.
Examples:

double f;
f = 0.1;

Suppose the implementation uses _Decimal128 as the TTDT. 0.1 is represented exactly after the constant is scanned. It is then converted to double in the assignment operator.

f = 0.1 \* 0.3;

Here, both 0.1 and 0.3 are represented in TTDT.  If the compiler evaluates the expression during translation time, it would be done using TTDT, and the result would be TTDT.  This is then converted to double before the assignment.  If the compiler generates code to evaluate the expression during execution time, both 0.1 and 0.3 would be converted to double before the multiply.  The result of the former would be different but more precise than the latter.

float g = 0.3f;
f = 0.1 \* g;

When one operand is a TTDT and the other is one of float/double/long double, the TTDT is converted to double with an internal representation following the specification of FLT_EVAL_METHOD for constant of type double.  Usual arithmetic conversion is then applied to the resulting operands.

_Decimal32 h = 0.1;

If one operand is a TTDT and the other a decimal floating type, the TTDT is converted to _Decimal64 with an internal representation specified by DEC_EVAL_METHOD. Usual arithmetic conversion is then applied.

If one operand is a TTDT and the other a decimal floating type, the TTDT is converted to the decimal floating type.

The floating-point environment <fenv.h> specified in C99 applies also to decimal float types.  The decimal floating-point arithmetic specified is more stringent.  All the rounding directions and flags are supported.

Certain algorithms stipulate a precision on the result of an operation; and this precision could be different from those of the three standard types.  The technical report adds a pragma directive to control this during translation time.

#pragma STDC DEC_MAX_PRECISION integer | DEFAULT

A host of new functions are added to <math.h> to support the new decimal floating types, along with new macros HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128, DEC_INFINITY and DEC_NAN are defined to help using these functions. The functions are equivalent to the existing generic floating type functions with d32, d64, and d128 suffixes added for the decimal floating type versions of the functions.  Similarly equivalent functions to support decimal floating types are added to <stdlib.h>, <wchar.h>, and macros to <tgmath.h>.

And last New quantize functions are added to <math.h>  These functions set the exponent of argument x to the exponent of argument y, while attempting to keep the value the same.

For a look at the full document and the rational see:


Monday Mar 06, 2006

Finding a dynamic library dependency

At a customer visit this week I was asked if the compiler libraries can be reshipped with an application.  And of course the answer is yes.  A complete list of those libraries can be found at:

/opt/SUNWspro/READMEs/runtime.libraries

This reminded me of another question about how an application can locate library dependencies when the application can be installed in a user defined location.  For example, you have an application whose dynamic library is always located relative to itself via the path ../lib, like this:

cobol% ls -laF bin prod prod/bin .
.:
total 48
drwxr-xr-x   4 bin      bin        512 Mar  6 08:15 ./
drwxrwxrwx   5 bin      bin       1024 Mar  5 10:23 ../
drwxr-xr-x   2 bin      bin        512 Mar  5 10:37 bin/
-rw-r--r--   1 bin      bin       2178 Mar  6 08:15 myapp.c
drwxr-xr-x   3 bin      bin        512 Mar  5 10:37 prod/

bin:
total 6
drwxr-xr-x   2 bin      bin        512 Mar  5 10:37 ./
drwxr-xr-x   4 bin      bin        512 Mar  6 08:15 ../
lrwxrwxrwx   1 bin      bin         20 Mar  5 10:37 myapp -> ../prod/bin/myapp

prod:
total 6
drwxr-xr-x   3 bin      bin        512 Mar  5 10:37 ./
drwxr-xr-x   4 bin      bin        512 Mar  6 08:15 ../
drwxr-xr-x   2 bin      bin        512 Mar  6 08:15 bin/
drwxr-xr-x   2 bin      bin        512 Mar  6 08:15 lib/

prod/bin:
total 4
drwxr-xr-x   2 bin      bin        512 Mar  6 08:15 ./
drwxr-xr-x   3 bin      bin        512 Mar  5 10:37 ../
-rwxr-xr-x   1 bin      bin       8972 Mar  6 08:33 myapp\*

prod/lib:
total 4
drwxr-xr-x   2 bin      bin        512 Mar  6 08:15 ./
drwxr-xr-x   3 bin      bin        512 Mar  5 10:37 ../
-rwxr-xr-x   1 bin      bin       8972 Mar  6 08:33 mylib.so\*
cobol%

The linker provides Dynamic String Tokens that can be used to when creating the application.  In this case the token is called: $ORIGIN

And would be used as follows:

% cc -o prod/bin/myapp myapp.c '-R$ORIGIN/../lib' -L prod/lib -lmylib

For details about $ORIGIN and other Dynamic String Tokens see the Linker and Libraries Guide on docs.sun.com.

About

Douglas is a principal software engineer working as the C compiler project lead and the Oracle Solaris Studio technical lead.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today