This is the mail archive of the
mailing list for the binutils project.
Re: Initial MIPS patch for Gold
- From: Ian Lance Taylor <iant at google dot com>
- To: Aleksandar Simeonov <Aleksandar dot Simeonov at RT-RK dot com>
- Cc: rich at mips dot com, mips-compiler at rt-rk dot com, binutils at sourceware dot org
- Date: Mon, 14 Nov 2011 10:58:19 -0800
- Subject: Re: Initial MIPS patch for Gold
- References: <4E7B2939.1000702@RT-RK.com> <4E7B3361.90501@RT-RK.com> <firstname.lastname@example.org> <4EC12FFA.5010001@RT-RK.com>
Aleksandar Simeonov <Aleksandar.Simeonov@RT-RK.com> writes:
>>> + target->fix_sections(this, symtab);
>> fix_sections is not a good name, since it doesn't say anything about
>> when the function is called or what it can do. More seriously, when I
>> look at the implementation of fix_sections, I don't see anything that
>> can't be done in finalize_sections. Why not just use finalize_sections?
> Problem here is that MIPS version of Gold needs some data that are not
> available in the moment when finalize_sections is executed. For example,
> number of elements in dynamic symbol table is needed for MIPS_SYMTABNO
> tag in .dynamic section , but it is known only after
> create_dynamic_symtab function is executed, so I added additional
> function that is called almost at the end of Layout::finalize, when all
> needed data is known.
Oh, I see. You are using passing a pointer to Output_data_dynamic, and
then filling in the pointer later. I don't particularly like that
approach, because it introduces a dependency which I think is unclear.
Nothing will notice if the linker changes such that the dynamic tag
value is written out before it is set.
The name add_special is not good, because it does not convey any
meaning--every value is special in its own way. Instead, perhaps
add_target_specific--see the existing method of that name in
Output_data_reloc. And implement it the same way that
add_target_specific is implemented: the code calls the target to get the
value, rather than simply trusting that the value has appeared in a
memory location; look for TARGET_CODE.
I note that for DT_MIPS_GOTSYM you are traversing the symbol table.
Traversing the symbol table is the single slowest operation in the
linker, and traversals should be avoided whenever possible. As far as I
can tell you are just looking for the smallest dynamic symbol table
index. The layout code already computes that, in
Layout::create_dynamic_symtab. In this case you should just change the
Layout code to remember that number, and then retrieve it when you need