relaxing vs section merging

relaxing vs section merging

[DJ Delorie]

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?

Re: relaxing vs section merging

[Alan Modra]

On Mon, Apr 26, 2004 at 03:45:19PM -0400, DJ Delorie wrote:
> 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.

I would guess that the mn10300 symbol reading code needs to look like
that in elflink.c:elf_link_input_bfd.  I don't see
_bfd_merged_section_offset being called anywhere in elf-m10300.c.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: relaxing vs section merging

[DJ Delorie]

> I would guess that the mn10300 symbol reading code needs to look like
> that in elflink.c:elf_link_input_bfd.  I don't see
> _bfd_merged_section_offset being called anywhere in elf-m10300.c.

Yeah, I added calls to _bfd_merged_section_offset (the mn10300
relocation code calls it indirectly).  That's when all the other
problems started happening; I think I mentioned that in my original
email.

Re: relaxing vs section merging

[Alan Modra]

On Mon, Apr 26, 2004 at 10:47:14PM -0400, DJ Delorie wrote:
> 
> > I would guess that the mn10300 symbol reading code needs to look like
> > that in elflink.c:elf_link_input_bfd.  I don't see
> > _bfd_merged_section_offset being called anywhere in elf-m10300.c.
> 
> Yeah, I added calls to _bfd_merged_section_offset (the mn10300
> relocation code calls it indirectly).  That's when all the other
> problems started happening; I think I mentioned that in my original
> email.

Well, you mentioned _bfd_elf_rela_local_sym, but that's not what I
meant.   I'm talking about code in elf-m10300.c that does

	  isym = isymbuf + ELF32_R_SYM (irel->r_info);
	  if (isym->st_shndx == SHN_UNDEF)
	    sym_sec = bfd_und_section_ptr;
	  else if (isym->st_shndx == SHN_ABS)
	    sym_sec = bfd_abs_section_ptr;
	  else if (isym->st_shndx == SHN_COMMON)
	    sym_sec = bfd_com_section_ptr;
	  else
	    sym_sec = bfd_section_from_elf_index (abfd, isym->st_shndx);

	  symval = (isym->st_value
		    + sym_sec->output_section->vma
		    + sym_sec->output_offset);

then uses symval.


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: relaxing vs section merging

[DJ Delorie]

> Well, you mentioned _bfd_elf_rela_local_sym, but that's not what I
> meant.   I'm talking about code in elf-m10300.c that does

That was one of the places I added a hook to look up the merged
section info.  It didn't work, for the reasons I outlined previously.

RE: relaxing vs section merging

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Alan Modra
> Sent: 27 April 2004 04:28
> To: DJ Delorie

> On Mon, Apr 26, 2004 at 10:47:14PM -0400, DJ Delorie wrote:
> > 
> > Yeah, I added calls to _bfd_merged_section_offset (the mn10300
> > relocation code calls it indirectly).  That's when all the other
> > problems started happening; I think I mentioned that in my original
> > email.
> 
> Well, you mentioned _bfd_elf_rela_local_sym, but that's not what I
> meant.   I'm talking about code in elf-m10300.c that does
> 
> 	  isym = isymbuf + ELF32_R_SYM (irel->r_info);
> 	  if (isym->st_shndx == SHN_UNDEF)
> 	    sym_sec = bfd_und_section_ptr;
> 	  else if (isym->st_shndx == SHN_ABS)
> 	    sym_sec = bfd_abs_section_ptr;
> 	  else if (isym->st_shndx == SHN_COMMON)
> 	    sym_sec = bfd_com_section_ptr;
> 	  else
> 	    sym_sec = bfd_section_from_elf_index (abfd, isym->st_shndx);
> 
> 	  symval = (isym->st_value
> 		    + sym_sec->output_section->vma
> 		    + sym_sec->output_offset);
> 
> then uses symval.

  Hmmm.  Aren't you about to run into the discrepancy I stumbled across a
while ago in this clause:

> 	  if (isym->st_shndx == SHN_UNDEF)
> 	    sym_sec = bfd_und_section_ptr;

because SHN_UNDEF = 0, but also absolute relocs in ELF are indicated by
relocs against the absolute symbol, which has a st_shndx value of zero ?

[  See http://sources.redhat.com/ml/binutils/2004-03/msg00107.html and
preceding thread refs for more.  ]



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....