This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH, libiberty] Fix segfault in floatformat.c:get_field on 64-bit hosts
- From: Ian Lance Taylor <iant at google dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: binutils at sourceware dot org, GCC Patches <gcc-patches at gcc dot gnu dot org>, DJ Delorie <dj at redhat dot com>
- Date: 13 Jun 2006 09:20:15 -0700
- Subject: Re: [PATCH, libiberty] Fix segfault in floatformat.c:get_field on 64-bit hosts
- References: <4489A779.2080101@codesourcery.com>
Julian Brown <julian@codesourcery.com> writes:
> This patch fixes a problem with floatformat.c:get_field on 64-bit (on
> at least x86_64), when cross-assembling to arm-none-eabi. The line
> which reads:
>
> result = *(data + cur_byte) >> (-cur_bitshift);
>
> was executed with cur_byte = -1 (start + len == 0 and order ==
> floatformat_little), which happily segfaulted (during printing of FP
> immediates).
I don't understand how start + len == 0 could ever be true. What was
calling the function? I note that put_field has the exact same
problem if start + len == 0.
> ! return result & ((2 << (total_len - 1)) - 1);
Why do you need to do this? And if you do need to do it, why use 2?
Why not ((1 << total_len) - 1)?
Please compile the file as a standalone program with -DIEEE_DEBUG to
make sure those tests still work. Ideally on both a big- and
little-endian system, if possible.
Ian