Patch for ICF string inline bug for SHT_REL sections.
Ian Lance Taylor
iant@google.com
Mon Jul 19 07:16:00 GMT 2010
More information about the Binutils mailing list
Mon Jul 19 07:16:00 GMT 2010
- Previous message (by thread): Patch for ICF string inline bug for SHT_REL sections.
- Next message (by thread): Patch for ICF string inline bug for SHT_REL sections.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Patch for ICF string inline bug for SHT_REL sections.
- Next message (by thread): Patch for ICF string inline bug for SHT_REL sections.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list