[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[dhd@mac.linux-m68k.org: Re: Kernel compile problem with binutils 2.9.5.8.12-2]



Hi,

I forgot that I should probably have Cc:'ed -toolchain on this.  Is this
expected behaviour from binutils?

----- Forwarded message from David Huggins-Daines <dhd@mac.linux-m68k.org> -----

On Tue, Oct 12, 1999 at 10:22:38PM +0100, Nick Holgate wrote:
> I'm pretty sure that the label "sc_mul:" just two instructions away would
> not be out of range even for a short branch. However if I comment out the
> ".global sc_mul" line near the top of the file it will assemble without
> problem.

Well, for the following code in decbin.S (note the pseudo-op):

m_sign:
        btst    #31,(%a0)       |test sign of the mantissa
        jeq     ap_st_z         |if clear, go to append/strip zeros
        fnegx   %fp0            |if set, negate fp0

| <lots of comments snipped>
ap_st_z:

gas 2.9.1 generated (this is a cross-binutils on Alpha, in case you're
wondering):

00000000000000aa <m_sign>:
  aa:   0810 001f       btst #31,%a0@
  ae:   6704            beqs b4 <ap_st_z>
  b0:   f200 001a       fnegx %fp0,%fp0

00000000000000b4 <ap_st_z>:

Whereas gas 2.9.5 generates:

000000aa <m_sign>:
  aa:   0810 001f       btst #31,%a0@
  ae:   67ff 0000 0000  beql b0 <m_sign+0x6>
  b4:   f200 001a       fnegx %fp0,%fp0

000000b8 <ap_st_z>:

It looks like the new gas is treating global symbols as (potentially)
external ones.  I don't know enough to say whether this is a regression
or not.



----- End forwarded message -----


Reply to: