Jurij Smakov schrieb:
On Mon, Mar 03, 2008 at 11:22:19AM +0100, Guido Draheim wrote:
[...]
There is no redesign required - this problem can only occur on non-x86
little-endian platforms.
You did not tell about that detail but I can guess it from the result. In
fetch.h there is
#define zzip_file_header_get_crc32(__p) ZZIP_GET32((__p)->z_crc32)
and that ZZIP_GET32 can be defined in a way that it would fetch each byte
seperately. This is already done on a lot of platforms - the definition
is dependent on ZZIP_WORDS_BIGENDIAN and covers acrchitectures like SPARC
which have aligned word access as well. However, SPARC is big-endian as
have been all the other test platforms in the lab. So, what's your target
platform currently? If I am guessing right then would need to redefine
the #ifdefs and configure detections in such a way that it would enable a
bytewise access macro on a litte-endian platform right there in fetch.h
Sparc is big-endian, but that's not what causes a problem here (even
though it would be nice to check that endianness is detected correctly
for sparc). Let's say that the macro which will get used is this one:
# define ZZIP_GET32(__p) bswap_32(*(uint32_t*)(__p))
This will only work on sparc if the address __p is word-aligned
(divisible by 4). Compiler is likely to generate a single load-word
instruction for that, and if __p is not word-aligned, then the process
will get a SIGBUS. Normally, it happens automatically, i.e. if you
define an int (of size 4) field inside a struct, then compiler will
take care of allocating memory for it in such a way that it is
word-aligned. However, since the structures in format.h are defined
mostly using arrays of zzip_byte_t, there is no way the compiler can
guess which of them should be aligned, so it places them arbitrarily.
Thus, attempt to cast the value to uint32_t fails.
Best regards,
Hi Jurij,
checking into the codebase I find that there is already a configure time
check for ZZIP_HAVE_ALIGNED_ACCESS_REQUIRED - is that being enabled in the
generated $build/zzip/_config ?
I would like to disable the Linux bswap optimization in that case (so it is
left enabled for all other Linux platforms that allow misaligned access).
I am going to commit a change that looks for that additional configure
value anyway. I hope this fixes the problem.
cheers, Guido
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]