[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: