C
Chuck Chopp
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.
TIA,
Chuck
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.
TIA,
Chuck