This is the mail archive of the
mailing list for the glibc project.
-magign-double on i686
- From: "Warlich, Christof" <christof dot warlich at siemens dot com>
- To: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 4 Jul 2014 07:15:17 +0000
- Subject: -magign-double on i686
- Authentication-results: sourceware.org; auth=none
Dear glibc community,
for various reasons being out of my control, I have to compile an application with -malign-double for a i686 (i.e. 32 bit) Linux system. With glibc being the only library used by that application, I wonder which pitfalls I may run into?
I roughly skimmed the data types of the glibc API, and with very few exceptions (I actually just found one), glibc's API doesn't seem to use structures that have different internal padding when using either 32 bit or 64 bit alignment. Thus, is it right that I'm on the save side as long as my application does not use any glibc functions (or macros) expecting (or returning) structures containing long long or double?
To push the topic even further, the only example I found that seems to have different padding when using either 32 bit or 64 bit alignment is struct aiocb64, due to its member __off64_t aio_offset:
int aio_fildes; /* File desriptor. */
int aio_lio_opcode; /* Operation to be performed. */
int aio_reqprio; /* Request priority offset. */
volatile void *aio_buf; /* Location of buffer. */
size_t aio_nbytes; /* Length of transfer. */
struct sigevent aio_sigevent; /* Signal number and value. */
/* Internal members. */
struct aiocb *__next_prio;
__off64_t aio_offset; /* File offset. */
Did I miss a substantial part(s) of glibc's API where I may see similar issues?
I know that this would always be a hack being far from any decent engineering work, and that it may break any time soon when changing glibc versions, but after having thoroughly discussed our options, there weren't any other viable options left. Thus, I'd happily appreciate any comments that help to mitigate the risk of being trapped by strange and hard to find bugs due to alignment mismatches.
Thanks and cheers,