llvm dev - Jan 2014 - [LLVMdev] [lld] Relocation sections format: .rela / .rel

Hi,

Now lld writes relocations to the ".rela" sections only. Mips requires
to use the "rel" format. So we need to be able to select format and
names of relocation section, names of symbols like __rela_iplt_* /
__rel_iplt_*, dynamic table tag DT_RELA / DT_REL.

My current idea:
- Add two virtual functions
DefaultLayout::createDynamicRelocationTable() and
DefaultLayout::getPLTRelocationTable(). Call these functions when we
need to create relocation tables. By default these function create
.rela.* sections.
- Override createDynamicRelocationTable() and getPLTRelocationTable()
in the MipsTargetLayout to create .rel.* sections.
- Add support for writing Elf_Rel entries to the RelocationTable
class. Maybe it's better to inherit form RelocationTable two separate
classes deal with lf_Rela / Elf_Rel entries.
- It's unclear to me how to select names of symbols like __rela_iplt_*
/ __rel_iplt_* and dynamic table tag DT_RELA / DT_REL.

Is it an appropriate solution? Any objections or suggestions?

Thanks.

-- 
Simon Atanasyan

I think the linking context should decide whether to use rel (or) rela. This is
also needed if --emit-relocations option is chosen (or) -r option is used.

Thoughts ?

Sent from my iPhone
> On Jan 19, 2014, at 15:01, Simon Atanasyan <simon at atanasyan.com>
wrote:
> 
> Hi,
> 
> Now lld writes relocations to the ".rela" sections only. Mips
requires
> to use the "rel" format. So we need to be able to select format
and
> names of relocation section, names of symbols like __rela_iplt_* /
> __rel_iplt_*, dynamic table tag DT_RELA / DT_REL.
> 
> My current idea:
> - Add two virtual functions
> DefaultLayout::createDynamicRelocationTable() and
> DefaultLayout::getPLTRelocationTable(). Call these functions when we
> need to create relocation tables. By default these function create
> .rela.* sections.
> - Override createDynamicRelocationTable() and getPLTRelocationTable()
> in the MipsTargetLayout to create .rel.* sections.
> - Add support for writing Elf_Rel entries to the RelocationTable
> class. Maybe it's better to inherit form RelocationTable two separate
> classes deal with lf_Rela / Elf_Rel entries.
> - It's unclear to me how to select names of symbols like __rela_iplt_*
> / __rel_iplt_* and dynamic table tag DT_RELA / DT_REL.
> 
> Is it an appropriate solution? Any objections or suggestions?
> 
> Thanks.
> 
> -- 
> Simon Atanasyan

I create a patch which adds new virtual function to the
ELFLinkingContext class and calls this function everywhere where we
need to select a relocation table format, dynamic table tags etc.

http://llvm-reviews.chandlerc.com/D2601

On Mon, Jan 20, 2014 at 1:36 AM, Shankar Easwaram <shankarke at gmail.com>
wrote:
> I think the linking context should decide whether to use rel (or) rela.
This is also needed if --emit-relocations option is chosen (or) -r option is
used.
>
> Thoughts ?
>
> Sent from my iPhone
>
>> On Jan 19, 2014, at 15:01, Simon Atanasyan <simon at
atanasyan.com> wrote:
>>
>> Hi,
>>
>> Now lld writes relocations to the ".rela" sections only. Mips
requires
>> to use the "rel" format. So we need to be able to select
format and
>> names of relocation section, names of symbols like __rela_iplt_* /
>> __rel_iplt_*, dynamic table tag DT_RELA / DT_REL.
>>
>> My current idea:
>> - Add two virtual functions
>> DefaultLayout::createDynamicRelocationTable() and
>> DefaultLayout::getPLTRelocationTable(). Call these functions when we
>> need to create relocation tables. By default these function create
>> .rela.* sections.
>> - Override createDynamicRelocationTable() and getPLTRelocationTable()
>> in the MipsTargetLayout to create .rel.* sections.
>> - Add support for writing Elf_Rel entries to the RelocationTable
>> class. Maybe it's better to inherit form RelocationTable two
separate
>> classes deal with lf_Rela / Elf_Rel entries.
>> - It's unclear to me how to select names of symbols like
__rela_iplt_*
>> / __rel_iplt_* and dynamic table tag DT_RELA / DT_REL.
>>
>> Is it an appropriate solution? Any objections or suggestions?
>>
>> Thanks.
-- 
Simon Atanasyan