RE: Initial MIPS patch for GOLD - version 3

["Fuhler, Rich" <rich at mips dot com>]

Hi Ian, I've been out with pneumonia and the corporate assignment wasn't updated while I was out. I'll get it done next day or so.
________________________________________
From: Ian Lance Taylor [iant@google.com]
Sent: Wednesday, March 07, 2012 06:54
To: Simeonov, Aleksandar (c)
Cc: Fuhler, Rich; mips-compiler@rt-rk.com; binutils@sourceware.org
Subject: Re: Initial MIPS patch for GOLD - version 3

"Simeonov, Aleksandar (c)" <asimeonov@mips.com> writes:

> Do you have any comments on proposals from my previous mail?

I'm not crazy about those proposals, because they in effect add highly
specialized cases to the Target structure.  One of the problems with the
GNU linker is the function pointers in the elf_backend_data structure.
Many of the function pointers are very specific and hard to understand
and use correctly, which becomes an issue when the code changes.
Unfortunately I have to some extent recreated that in gold's Target
structure.  I'm not sure what to do in this area.

I've been postponing more serious consideration of your patch until the
coypright issues are sorted out.  Also I'm in the middle of overlapping
release cycles and simply haven't had time to do any gold work.  Sorry.

Ian

> ________________________________________
> From: Simeonov, Aleksandar (c)
> Sent: Friday, February 03, 2012 4:40 PM
> To: Ian Lance Taylor
> Cc: Fuhler, Rich; mips-compiler@rt-rk.com; binutils@sourceware.org
> Subject: Re: Initial MIPS patch for GOLD - version 3
>
> Hi Ian,
> I agree with you that processor specific stuff should be in CPU.cc. Because of that I would like to suggest following:
>
> - reloc.cc (Sized_relobj_file<size, big_endian>::write_sections)
>
> Instead of having direct compare of section types in code:
> // For MIPS .reginfo section there is no need to do anything
> if (shdr.get_sh_type() == elfcpp::SHT_MIPS_REGINFO)
>   continue;
>
> To have something like:
> // Sections that need special handling (target specific)
> if(parameters->target().section_needs_spec_handling(shdr.get_sh_type()))
>  continue;
>
> Where section_needs_spec_handling should be defined in Target as a virtual function that returns false by default and can be implemented as needed.
>
>
> - layout.cc (Layout::segment_precedes)
>
> Instead of having function segment_precedes in Layout class, to move it to Target class. Make virtual default implementation as it was originally and allow different architectures to make their own implementation.
>
> Maybe some other proposals?
>
> Greetings,
> Aleksandar
>
> On 28/01/2012 02:54, Ian Lance Taylor wrote:
>> Aleksandar Simeonov <Aleksandar.Simeonov@RT-RK.com> writes:
>>
>>> * reloc.cc (Sized_relobj_file<size, big_endian>::write_sections): Special
>>> handling of MIPS .reginfo section.
>>> - .reginfo section is generated by linker and needs special handling.
>>
>> I haven't thought about everything, but I can see that this patch is not
>> going to work as is.  It will fail when linking a non-MIPS object which
>> happens to have a section type == SHT_MIPS_REGINFO.  We can't use
>> processor-specific values like SHT_MIPS_REGINFO outside of the CPU.cc
>> file.
>>
>>> * layout.cc (Layout::segment_precedes): Fixed order of MIPS specific
>>> segments.
>>> - MIPS needs to have PT_MIPS_REGINFO segment before any loadable segment.
>>
>> This is similarly troubling, though probably less serious.
>>
>>> - MIPS needs to have PT_NULL segment to be last in list of segments.
>>
>> Why would we ever have a PT_NULL segment?
>>
>> Ian
>>