From: Brady Brown <bbrown@ti.com>
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: SGI news group <linux-mips@oss.sgi.com>
Subject: Re: Sign extended 64bit address
Date: Wed, 21 Mar 2001 12:15:58 -0700 [thread overview]
Message-ID: <3AB8FDEE.95A74D61@ti.com> (raw)
In-Reply-To: 20010321181017.A7274@bacchus.dhis.org
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 (bbrown@ti.com) Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prev parent reply other threads:[~2001-03-21 19:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-21 0:04 Sign extended 64bit address Brady Brown
2001-03-21 4:04 ` Ralf Baechle
2001-03-21 16:58 ` Brady Brown
2001-03-21 17:10 ` Ralf Baechle
2001-03-21 19:15 ` Brady Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AB8FDEE.95A74D61@ti.com \
--to=bbrown@ti.com \
--cc=linux-mips@oss.sgi.com \
--cc=ralf@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.