Problem with "va_list" & variable arguments in 64-bit programs onSLES 10 SP1

Discussion in 'C++' started by Chuck Chopp, Sep 13, 2008.

  1. Chuck Chopp

    Chuck Chopp Guest

    I have some code that is being built on the following:

    Windows Server 2003, both 32-bit & 64-bit editions
    Windows Vista, both 32-bit & 64-bit editions
    Windows Server 2008, both 32-bit & 64-bit editions

    Build tools: Visual Studio 2008.

    SLES 10 SP1, both 32-bit & 64 bit editions

    Build tools: gss v4.1.2

    This code has a function that takes a variable # of arguments, and it
    serves as a wrapper around various functions in the printf() family,
    namely, the "v" variants of them directly accept a "va_list" argument.
    The code makes proper use of va_start() and va_end() to initialize an
    instance of "va_list", which then gets passed in to vsnprintf() [Linux],
    vswprintf() [Linux & Windows] and vsnprintf_s() [Windows].

    The code compiles & links successfully for both 32-bit & 64-bit targets
    on Windows, and it executes properly, too. It also compiles, links &
    executes properly when producing a 32-bit binary on SLES 10 SP1.

    Although it compiles & links successfully when producing a 64-bit binary
    on SLES 10 SP1, it does not execute properly. The various printf()
    functions that are being called all fail to produce proper output.

    After simultaneously debugging both the 32-bit & 64-bit builds of the
    program, and also comparing with what's happening on Windows, I've
    obtained the following information:

    On Windows, for both 32-bit & 64-bit targets, "va_list" is nothing more
    than a "char *" pointer that points to a contiguous block of memory that
    contains 32-bit values [on 32-bit build] and 64-bit values [on 64-bit
    build]. Examining memory at that address value stored in an initialized
    instance of "va_list" proves that this is true.

    On Linux, for the 32-bit build of the program, "va_list" is also a "char
    *", and it behaves the same as on Windows. Examining memory at that
    address value stored in an initialized instance of "va_list" proves that
    this is true.

    On Linux, for the 64-bit build of the program, sizeof(va_list) returns a
    value of 24, and examining an initialized instance of "va_list" in the
    debugger [gdb] shows that it is a structured data type, with members
    named "gp_offset", "fp_offset", "overflow_arg_area" and "reg_save_area".

    For both the 32-bit & 64-bit builds of the program on Linux, the
    "stdarg.h" header has a typedef that makes "va_list" equivalent to
    "__gnuc_va_list", and another typedef that makes "__gnuc_va_list"
    equivalent to "__builtin_va_list", which must be defined internally by
    gcc itself, rather than being present in any header files.

    My best guess at this point is that gcc is defining "__builtin_va_list"
    for the 64-bit build of the program such that it differs from the
    definition of "va_list" used by the the glibc implementations the
    various printf() functions.

    Google Groups searches of the Usenet archives haven't been turning up
    anything useful, and neither has searching the gcc wiki & FAQ.

    Has anybody encountered this problem, before? Any info about it would
    be helpful, especially any work around or fixes or links to any web
    pages that confirm what I think is going wrong.


    Chuck Chopp, Sep 13, 2008
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    Timothy Bendfelt
    Jan 19, 2007
  2. Spoon
    those who know me have no need of my name
    Jul 25, 2007
  3. Vijay
    Joern Schou-Rode
    Nov 1, 2008
  4. Navaneeth
    Kenny McCormack
    Nov 20, 2010
  5. Judy

Share This Page