This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: 0xffffffff when BFD64
- To: Alan Modra <alan at linuxcare dot com dot au>
- Subject: Re: 0xffffffff when BFD64
- From: Alexandre Oliva <aoliva at cygnus dot com>
- Date: 07 Apr 2000 01:32:13 -0300
- Cc: ian at zembu dot com, binutils at sourceware dot cygnus dot com
- Organization: Cygnus Solutions, a Red Hat Company
- References: <Pine.LNX.4.21.0004071354090.6764-100000@front.linuxcare.com.au>
On Apr 7, 2000, Alan Modra <alan@linuxcare.com.au> wrote:
> I guess we should check all hex constants in the range 0x80000000 to
> 0xffffffff, replacing them with const & N_ONES(32). Blechh.
I started doing something like that, but gave up. It's just too much
of a hassle. I'd rather just fix the problem at hand, which occurs
with a native compiler, and hope no other compiler has this problem.
After all, we can always recommend GCC :-)
OTOH, it wouldn't hurt to run something like this on the binutils
tree (minimally tested; may require GNU grep and GNU sed):
grep -lr '\<0x[89a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]\>' bfd opcodes binutils gas ld |
while read f; do
sed 's,\<0x[89a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]\>,(unsigned)(N_ONES(32) \& &),g' \
< $f > $f.new && mv $f.new $f
done
--
Alexandre Oliva Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me