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