Subject: Sign extended 64bit address

From: Brady Brown <[email-masked]>
Date: Tue, 20 Mar 2001 17:04:07 -0700

I have run into the earlier mentioned problem of objcopy not correctly
dealing with the sign extended 64 bit address generated by the new
tools. Is there an update on this issue? Any good work-arounds or short
time solutions?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brady Brown ([email-masked])       Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 21 Mar 2001 05:04:07 +0100

> tools. Is there an update on this issue? Any good work-arounds or short

I don't have your old report at hand but somewhen during the past year
binutils received a number of fixes related to signed/unsigned addresses,
so you should try a recent copy of binutils.

   Ralf

---

From: Brady Brown <[email-masked]>
Date: Wed, 21 Mar 2001 09:58:54 -0700

> so you should try a recent copy of binutils.

I'm currently using binutils-2.10.91-2 from Maciej's site. Is there a later
rev that I should look at?

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 21 Mar 2001 18:10:18 +0100

> rev that I should look at?

I was believing that that one is good; can you resend your bugreport
about the sign extension problem?  Thanks.

  Ralf

---

From: Brady Brown <[email-masked]>
Date: Wed, 21 Mar 2001 12:15:58 -0700

> about the sign extension problem?  Thanks.

Problem solved. Sorry, my oversight. The binutils are correctly handling the
addresses. What happened was that the new tools created a couple of new code
sections "__ex_table and __dbe_table" that were not handled by the linker script
in my kernel (2.4.0-test9), hence ended up a strange low addresses. I
interpreted the warnings and the 'wrong' address in the final srec as a address
translation problem. Once I added these sections to the linker script the
warnings and 'bad' address's went away.

A second issue:
The kernel built by these new tools will not boot. Complains about illegal
instructions as soon as init is launched. The first address that traps is a sw
inside the __bzero routine.  I'll have to dig a bit here I guess. Any leads
would be appreciated.