468,733 Members | 1,358 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,733 developers. It's quick & easy.

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

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
Sep 13 '08 #1
1 4885
Sam
Chuck Chopp writes:
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.
Your best guess will, unfortunately, remain only a guess, unless you post
some actual example that demonstrates your question.

What printf use or doesn't use is completely irrelevant. There's nothing in
any standard that requires printf to use stdarg.h-defined facilities to
process its arguments.

Furthermore, I do not see any C++ language-related content, for
comp.lang.c++, here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkjLGogACgkQx9p3GYHlUOLSvgCfQMTvAQ91X2 yjtK354tvxBqv2
QUEAnA2+LhiHzi/AeZiQonhYEzyvQjNu
=iFUA
-----END PGP SIGNATURE-----

Sep 13 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Michael Cohen | last post: by
3 posts views Thread by shiva | last post: by
4 posts views Thread by Egbert Nierop \(MVP for IIS\) | last post: by
3 posts views Thread by carvalho.miguel | last post: by
5 posts views Thread by shaanxxx | last post: by
4 posts views Thread by Tor Rustad | last post: by
5 posts views Thread by =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post: by
45 posts views Thread by mdh | last post: by
1 post views Thread by CARIGAR | last post: by
xarzu
2 posts views Thread by xarzu | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.