This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

Re: Patch for ICF string inline bug for SHT_REL sections.


Sriraman Tallam <tmsriram@google.com> writes:

> 2010-07-18  Sriraman Tallam  <tmsriram@google.com>
>
> 	* gc.h (gc_process_relocs): Save the section header type for use by
> 	ICF.
> 	* icf.cc (get_section_contents): Get the addend from the text section
> 	for SHT_REL relocation sections.
> 	* icf.h (Icf::Sh_type_info): New typedef.
> 	(Icf::Reloc_info): Add new member sh_type_info.

Can we add a test case?

> +		  // For SHT_REL relocation sections, the addend is stored in the
> +		  // relocation offset in the text section as a 32-bit value.

That's not true in general.  It's not even true on x86.  The R_386_16
reloc stores a 16-bit value in the section.  What you need here is
something similar to Relocatable_relocs::Reloc_strategy, in which the
general code asks the target for the size of the addend, among other
things.  By default on i386 that uses Relocatable_size_for_reloc, which
you should be able to reuse for this.

Also I note that saving the relocation section type for each reloc is
overkill, though it may not matter much.

I'm not sure you need strings to show the problem, I think it would
occur in code like

int a[100];
int f1() { return a[1]; }
int f2() { return a[2]; }

Ian


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