From: DJ Delorie <dj@redhat.com>
To: binutils@sources.redhat.com
Subject: relaxing vs section merging
Date: Mon, 26 Apr 2004 19:54:00 -0000 [thread overview]
Message-ID: <200404261945.i3QJjJRS026862@greed.delorie.com> (raw)
target = mn10300-elf
host = linux
Consider linking these two files with "ld --relax":
-------------------- dj1.s
.section .text
.global _start
.type _start,@function
_start:
mov .LC1a,d1
nop
.section .rodata.str1.1,"aMS",@progbits,1
.LC1a:
.string "\n"
-------------------- dj2.s
.section .rodata.str1.1,"aMS",@progbits,1
.LC2a:
.rept 32768
.byte 'a'
.endr
.byte 0
.LC2b:
.string "abc\n"
--------------------
What I'm seeing is that the relaxation code uses the pre-merge value
of LC1a, but the relocation uses the post-merge value and thus fails
(reloc overflow). I've verified that merging happens before relaxing.
Why this happens is uncertain. Various things I've seen:
* The section for LC1a is set to *ABS* by ldlang.c, because the merge
code decided it was to be discarded.
* If I try to map LC1a through _bfd_elf_rela_local_sym, at first it
doesn't because only STT_SECTION symbols are allowed to be mapped.
* If I override the STT_SECTION check, it complains that the symbol is
outside the merged section (*ABS*, remember?)
* If I try to keep the section from being discarded (so it's not
*ABS*), it still complains as above.
So far, the only "solution" I've found is to just not relax relocs to
symbols in mergable sections, but this obviously isn't ideal. Am I
missing something obvious? Is there some fundamental bug that needs
to be fix here, and if so, where? Or should we just skip mergable
symbols?
next reply other threads:[~2004-04-26 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-26 19:54 DJ Delorie [this message]
2004-04-27 2:35 ` Alan Modra
2004-04-27 2:47 ` DJ Delorie
2004-04-27 3:39 ` Alan Modra
2004-04-27 18:03 ` DJ Delorie
2004-04-27 21:39 ` Dave Korn
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=200404261945.i3QJjJRS026862@greed.delorie.com \
--to=dj@redhat.com \
--cc=binutils@sources.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).