This is the mail archive of the
mailing list for the binutils project.
RE: Initial MIPS patch for GOLD - version 3
- From: "Simeonov, Aleksandar (c)" <asimeonov at mips dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "Fuhler, Rich" <rich at mips dot com>, "mips-compiler at rt-rk dot com" <mips-compiler at rt-rk dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 7 Mar 2012 14:26:28 +0000
- Subject: RE: Initial MIPS patch for GOLD - version 3
- References: <A3487A936DAED94AA1B5D34A90FB63D446AA09B4@exchdb03.mips.com>
Do you have any comments on proposals from my previous mail?
Are there any other comments about patch or you think it is ready for trunk?
Thanks in advance for your answers,
From: Simeonov, Aleksandar (c)
Sent: Friday, February 03, 2012 4:40 PM
To: Ian Lance Taylor
Cc: Fuhler, Rich; email@example.com; firstname.lastname@example.org
Subject: Re: Initial MIPS patch for GOLD - version 3
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)
To have something like:
// Sections that need special handling (target specific)
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?
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
>> * layout.cc (Layout::segment_precedes): Fixed order of MIPS specific
>> - 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?