diff options
| author | Jeff Morriss <jeff.morriss@ulticom.com> | 2012-05-04 21:56:32 +0000 |
|---|---|---|
| committer | Jeff Morriss <jeff.morriss@ulticom.com> | 2012-05-04 21:56:32 +0000 |
| commit | 06bb1678241c2cd4094f99f77ac3bdb85a46e59a (patch) | |
| tree | 882fdb688b8145fef7789a8c85b71505f5639ff8 | |
| parent | d1566f00a29b8f4db3aae925be825c065e53e6a2 (diff) | |
The rest of the fix for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7221
(emem alignment problems on SPARC) :
Have emem use 8-byte alignment when we need it.
Since I can't seem to write code that which reliably (across GCC versions and
optimization levels) determines if 8-byte alignment is needed for doubles,
"when" is defined as "if we're compiling for a CPU other than i386."
Windows doesn't need a check because it's either i386 or 64-bit (x86_64 or
maybe ia64--both of which get 8-byte alignment from G_MEM_ALIGN).
(And, yes, all of this is ignoring the 16-byte alignment requirements of long
doubles.)
svn path=/trunk/; revision=42431
| -rw-r--r-- | configure.in | 16 | ||||
| -rw-r--r-- | epan/emem.c | 2 | ||||
| -rw-r--r-- | epan/emem.h | 16 |
3 files changed, 31 insertions, 3 deletions
diff --git a/configure.in b/configure.in index a71026dc41..85e79e9638 100644 --- a/configure.in +++ b/configure.in @@ -1911,6 +1911,22 @@ CPPFLAGS="$CPPFLAGS '-DPLUGIN_DIR=\"\$(plugindir)\"'" PLUGIN_LIBS="" AC_SUBST(PLUGIN_LIBS) +# +# Check if (emem) memory allocations must be 8-byte aligned. +# I haven't been able to write C code that reliably makes that determination +# (different versions of GCC with or without optimization give different +# results) so just assume everything except (32-bit) x86 needs 8-byte +# alignment (64-bit x86 will get 8-byte alignment from G_MEM_ALIGN anyway). +# +AC_MSG_CHECKING(whether we need memory allocations to be 8-byte aligned) +if test x$host_cpu != xi386 +then + AC_MSG_RESULT(yes) + AC_DEFINE(NEED_8_BYTE_ALIGNMENT, 1, [Define if we need memory allocations to be 8-byte aligned]) +else + AC_MSG_RESULT(no) +fi + dnl libtool defs # # Yes, AM_PROG_LIBTOOL is redundant with newer version(s) of some tool(s) diff --git a/epan/emem.c b/epan/emem.c index 2e9503accc..a2ad22a1c7 100644 --- a/epan/emem.c +++ b/epan/emem.c @@ -760,7 +760,7 @@ emem_alloc_chunk(size_t size, emem_header_t *mem) asize += sizeof(void *); pad = emem_canary_pad(asize); } else - pad = (G_MEM_ALIGN - (asize & (G_MEM_ALIGN-1))) & (G_MEM_ALIGN-1); + pad = (WS_MEM_ALIGN - (asize & (WS_MEM_ALIGN-1))) & (WS_MEM_ALIGN-1); asize += pad; diff --git a/epan/emem.h b/epan/emem.h index ffa9704df5..19eac559b2 100644 --- a/epan/emem.h +++ b/epan/emem.h @@ -166,9 +166,21 @@ void se_free_all(void); **************************************************************/ struct _emem_chunk_t; +/* G_MEM_ALIGN is not always enough: http://mail.gnome.org/archives/gtk-devel-list/2004-December/msg00091.html + * So, we check (in configure) if we need 8-byte alignment. (Windows + * shouldn't need such a check until someone trys running it 32-bit on a CPU + * with more stringent alignment requirements than i386.) + * + * Yes, this ignores the possibility of needing 16-byte alignment for long doubles. + */ +#if defined(NEED_8_BYTE_ALIGNMENT) && (G_MEM_ALIGN < 8) +#define WS_MEM_ALIGN 8 +#else +#define WS_MEM_ALIGN G_MEM_ALIGN +#endif + /* Macros to initialize ws_memory_slab */ -/* XXX, is G_MEM_ALIGN enough? http://mail.gnome.org/archives/gtk-devel-list/2004-December/msg00091.html */ -#define WS_MEMORY_SLAB_INIT(type, count) { ((sizeof(type) + (G_MEM_ALIGN - 1)) & ~(G_MEM_ALIGN - 1)), count, NULL, NULL } +#define WS_MEMORY_SLAB_INIT(type, count) { ((sizeof(type) + (WS_MEM_ALIGN - 1)) & ~(WS_MEM_ALIGN - 1)), count, NULL, NULL } #define WS_MEMORY_SLAB_INIT_UNALIGNED(size, count) { size, count, NULL, NULL } struct ws_memory_slab { |