This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Add format attributes and fix exposed bugs


On Mon, 2005-06-20 at 19:34, Kaveh R. Ghazi wrote:
> Well since it's using "%llx" already, it should be okay to use long
> long.  If they're not supported, then it moves a runtime failure into
> a compile-time failure, which let's you notice it easier.

The only thing Ian objected to was the use of long long.  You are right
to point out that things are already broken, and that this turns a run
time error into a compiler error.  If this compiler error is a problem,
then as ia64 maintainer I am willing to fix it.

Ian suggested using bfd_sprintf_vma.  That won't work here, because it
prints a 32-bit number for ELF32 and a 64-bit number for ELF64, but on
IA-64, we can have 64-bit immediates even in 32-bit code, so we must
always print a 64-bit number here.

I would expect all native IA-64 compilers to support long long.  The
IA-64 ABI does not require it, but considering that C99 because public
around the same time as the IA-64 architecture did, it would be
surprising if someone did not support it.

If we can't use long long here, then maybe something like the code in
binutils/strings.c that checks STDC_VERSION will work.

By the way, long long is already used in two other places in opcodes. 
In the d30v-dis.c file and the s390-mkopc.c file.  d30v is an obscure
target port, but s390-mkopc.c is a little more mainstream.  If long long
works there, it can probably work OK in ia64-dis.c.

> Here's a revised patch with the cast-to-int from the first paragraph.
> I recompiled a cross configuration to xtensa-unknown-elf to test it.
> Is this version okay?  If so, would you please install?

I am willing to approve and apply your patch, but you really need to do
a --enable-targets=all build first.  I tried it, and ran into one error
in opcodes/arc-dis.c which I fixed, then I got 10 errors in
opcodes/arm-dis.c which I worked around by not building it, then I got
two errors in opcodes/cris-dis.c, and at that point I figured it was
easier to ask you to finish the job.  It looks like quite a few of the
disassemblers will need fixing.  I also got one patch error in
opcodes/or32-dis.c which is trivial to fix.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]