[Top] [All Lists]

Re: Sign extended 64bit address

To: Ralf Baechle <>
Subject: Re: Sign extended 64bit address
From: Brady Brown <>
Date: Wed, 21 Mar 2001 12:15:58 -0700
Cc: SGI news group <>
Organization: Texas Instruments
References: <> <> <> <>
Ralf Baechle wrote:

> On Wed, Mar 21, 2001 at 09:58:54AM -0700, Brady Brown wrote:
> > > > 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?
> > >
> > > 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.
> >
> > I'm currently using binutils-2.10.91-2 from Maciej's site. Is there a later
> > 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

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.

Brady Brown (       Work:(801)619-6103
Texas Instruments: Broadband Access Group

<Prev in Thread] Current Thread [Next in Thread>