XCOFF 64 function address wrong?
Nick Clifton
nickc@redhat.com
Thu Mar 10 10:22:00 GMT 2005
Hi David,
> But how could coff64-rs6000.c file #defining a value influence coffgen.c
> (unless there's some autogeneration going on here)?
It can't. You have uncovered a bug.
> Shouldn't this be
> in a .h file? Is there a better test for XCOFF64/32 status than a
> compile time ifdef - surely we'd want mixed capability?
Exactly. The idea was that XCOFF64 was defined in coff64-rs6000.c which
then included coffcode.h. If support for 32-bit COFF targets was also
being included in the bfd library then their *.c files would include
coffcode.h without defining XCOFF64 and so both 32-bit and 64-bit
formats would be supported.
As you have discovered this does not work with the current way that the
coff_print_symbol() function is coded in coffgen.c.
Would you like to try the attached, untested patch ? It is at best a
workaround since all it really does is to try to make sure that if a
symbol has a 64-bit value then it is displayed as such, but at least
this is better than displaying a truncated version.
Cheers
Nick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: coffgen.c.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20050310/1155244d/attachment.ksh>
More information about the Binutils
mailing list