This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

guidance requested Re: [PATCH RFA] implement"ld --embedded-relocs" for 32-bit MIPS ELF.


cgd@broadcom.com (Chris G. Demetriou) writes:
> I spent some time thinking about this last night (while I should have
> been sleeping 8-).
> 
> I've decided to withdraw this patch.  I'll resubmit a different
> version later.  It occurs to me that there's probably a _much_ more
> sane way to do this in ELF, which will save space in the resulting
> binary _and_ be IMO a better solution.

Actually, I need some guidance here from people with more linker clue
than I currently possess.


What I was hoping to do was, after the mapping from input sections to
output sections was decided, for sect in output sections
create .emreloc$sect containing the relocations for objects in $sect.

That way:

* people could elide the relocations against .text symbols, if they
  knew that their text segment would have a fixed location, etc.

* it would get rid of the evil "first 8 bytes of the output section
  name" hack currently used.

* each reloc would be smaller (4 bytes for 32-bit ELF, rather than 12
  bytes).  people would distinguish the sections using labels in the
  linker script, and so rather than coding like:

	for each reloc {
		if section string is ".text"
			offset = text_offeset
		else if section string is ".data"
			offset = data_offset
		else
			die
		do_reloc(reloc, offset)
	}

  They'do:

	text_offset=N
	text_relocs_start=label1
	text_relocs_end=label2
	do_relocs(text_relocs_start, text_relocs_end, text_offset)

	data_offset=N
	data_relocs_start=label1
	data_relocs_end=label2
	do_relocs(data_relocs_start, data_relocs_end, data_offset)


Just the latter feature would cut the amount of space spent on the
reloc table by 2/3 for 32-bit ELF -- from about 28.5k down to 9.5k on
some code we've got here, for instance.



However, this requires the ability to create new sections and have
them show up in the 'right places' in the output BFD _after_ all the
input BFDs sections have been mapped to output sections.

I don't see any good place/way to do that.

Anybody have any suggestions?



chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]