From: ralf@uni-koblenz.de
To: "David S. Miller" <davem@dm.cobaltmicro.com>
Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
linux-mips@vger.rutgers.edu
Subject: Re: Haifa scheduler bug in egcs 1.0.2
Date: Thu, 22 Oct 1998 02:44:08 +0200 [thread overview]
Message-ID: <19981022024408.A360@uni-koblenz.de> (raw)
In-Reply-To: <199810210139.SAA22458@dm.cobaltmicro.com>; from David S. Miller on Tue, Oct 20, 1998 at 06:39:21PM -0700
On Tue, Oct 20, 1998 at 06:39:21PM -0700, David S. Miller wrote:
> Relocating the code generated from this source later on will not be
> possible for ld. As knows this and dies ungracefully.
>
> Then why is this a supposed bug in Haifa? It looks to me there is a
> problem with how %hi relocs are assosciated with %lo ones in binutils.
It's not necessarily a bug in Haida itself but it gets visible when Haifa
is enabled. I haven't looked closely at the involved egcs code yet.
> The code you showed me looks perfectly legal.
For ECOFF and ELF, relocations against symbols are done in two parts, with
a hi16 relocation and a lo16 relocation. Each relocation has only 16 bits of
space to store an addend and a carry may have to be propagated between
the two. This means that in order for the linker to handle carries
correctly, it must be able to locate both the hi16 and the lo16 relocation.
Object files which don't contain any other information except the order in
the relocation table which could be used to find the hi16 / lo16 relocs which
belong together.
The code I showed cannot be represented in a ELF or ECOFF object such that
the linker still knows which hi16 and which lo16 relocations are associated
with each other. Therefore it is not possible for the linker to correctly
do the hi16 relocations. Btw, all MIPS assemblers I know of will warn or
even error about that fragment.
The ABI is quite strict in that aspect, it wants one lo16 per hi16 for the
same symbol. Binutils relax that by allowing an arbitrary number of hi16
and one lo16 for the same symbol.
Ralf
prev parent reply other threads:[~1998-10-22 0:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-10-20 23:50 Haifa scheduler bug in egcs 1.0.2 ralf
[not found] ` <199810210139.SAA22458@dm.cobaltmicro.com>
1998-10-22 0:44 ` ralf [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=19981022024408.A360@uni-koblenz.de \
--to=ralf@uni-koblenz.de \
--cc=davem@dm.cobaltmicro.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@vger.rutgers.edu \
--cc=linux@cthulhu.engr.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.