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: 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
> 


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