From: Joern Rennecke <amylaar@redhat.com>
To: binutils@sources.redhat.com
Cc: law@redhat.com, amylaar@cambridge.redhat.com
Subject: fix for fixup_segment / MD_PCREL_FROM_SECTION
Date: Tue, 28 Aug 2001 13:07:00 -0000 [thread overview]
Message-ID: <200108282007.f7SK7rG02021@phal.cambridge.redhat.com> (raw)
Currently, it is impossible to write a port with a correct definition of
MD_PCREL_FROM that works, because fixup_segment neglects to subtract the
address of the relocation.
Tue Aug 28 20:37:06 2001 J"orn Rennecke <amylaar@redhat.com>
* write.c (fixup_segment): When resolving pcrel addresses,
properly subtract the address of the relocation if
TC_MD_PCREL_FROM_SECTION_FIXED is defined.
Index: write.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gas/write.c,v
retrieving revision 1.239
diff -p -r1.239 write.c
*** write.c 2001/08/11 18:27:01 1.239
--- write.c 2001/08/28 19:33:11
*************** fixup_segment (fixP, this_segment_type)
*** 2772,2777 ****
--- 2781,2789 ----
add_number += S_GET_VALUE (add_symbolP);
add_number -= MD_PCREL_FROM_SECTION (fixP, this_segment_type);
+ #ifdef TC_MD_PCREL_FROM_SECTION_FIXED
+ add_number -= fixP->fx_frag->fr_address + fixP->fx_where;
+ #endif
/* Lie. Don't want further pcrel processing. */
pcrel = 0;
Index: doc/internals.texi
===================================================================
RCS file: /cvs/cvsfiles/devo/gas/doc/internals.texi,v
retrieving revision 1.42
diff -p -r1.42 internals.texi
*** internals.texi 2001/07/14 15:56:19 1.42
--- internals.texi 2001/08/28 19:33:11
*************** If you define this macro, it should retu
*** 1280,1285 ****
--- 1280,1291 ----
PC relative fixup and the position from which the PC relative adjustment should
be made. On many processors, the base of a PC relative instruction is the next
instruction, so this macro would return the length of an instruction.
+ @item TC_MD_PCREL_FROM_SECTION_FIXED
+ @cindexTC_MD_PCREL_FROM_SECTION_FIXED
+ You also need to define @code{TC_MD_PCREL_FROM_SECTION_FIXED} to make this
+ work right, because a large number of old ports papered over a bug in
+ fixup_segment by making the reverse error in their definition of
+ @code{MD_PCREL_FROM_SECTION}.
@item md_pcrel_from
@cindex md_pcrel_from
next reply other threads:[~2001-08-28 13:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-28 13:07 Joern Rennecke [this message]
2001-08-28 16:38 ` law
2001-08-28 22:34 ` Alan Modra
2001-08-29 4:09 ` Joern Rennecke
2001-08-29 5:05 ` Alan Modra
2001-08-29 8:11 ` law
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=200108282007.f7SK7rG02021@phal.cambridge.redhat.com \
--to=amylaar@redhat.com \
--cc=amylaar@cambridge.redhat.com \
--cc=binutils@sources.redhat.com \
--cc=law@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).