public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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?

             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).