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] | |
Here is an updated patch.
-Doug
2010-02-02 Doug Kwan <dougkwan@google.com>
* Makefile.am (HFILES): Add arm-reloc-property.h.
(DEFFILES): New.
(TARGETSOURCES): Add arm-reloc-property.cc
(ALL_TARGETOBJS): Add arm-reloc-property.$(OBJEXT)
(libgold_a_SOURCES): $(DEFFILES)
* Makefile.in: Regenerate.
* arm-reloc-property.cc: New file.
* arm-reloc-property.h: New file.
* arm-reloc.def: New file.
* arm.cc: Update comments.
(arm-reloc-property.h): New included header.
(arm_reloc_property_table): New global variable.
(Target_arm::do_select_as_default_target): New method definition.
* configure.tgt (armeb*-*-*,armbe*-*-*,arm*-*-*): Add
arm-reloc-property to targ_extra_obj.
* parameters.cc (set_parameters_target): Call
Target::select_as_default_target().
* target.h (Target::select_as_default_target): New method definition.
(Target::do_select_as_default_target): Same.
2010/2/2 Doug Kwan (Ãö®¶¼w) <dougkwan@google.com>:
> 2010/2/2 Ian Lance Taylor <iant@google.com>:
>
>
>> I don't like the fact that we will pay in linker startup time for
>> every linker which includes the ARM target, even if we are not
>> linking ARM. This is problematic because by default the linker
>> includes support for all targets. Can we arrange for this to only be
>> constructed when the ARM target is being used?
>
> We can initialize this went we set the default target. That should be
> MT-safe, right?
>
>
>> Do we ever actually destroy a Tree_node structure? If not, there is
>> no reason to have a destructor.
>
> We do. trees are temporary. We can keep them in the
> Arm_reloc_property object but currently we have no further use. So I
> delete a tree at the end of Arm_reloc_property's constructor.
>
>> If you keep this, s/for(/for (/ and s/<this/< this/
>>
>>
>>> + ~Arm_reloc_property_table()
>>> + {
>>> + for (size_t code = 0; code < Property_table_size; ++code)
>>> + delete this->table_[code];
>>> + }
>>
>> Do we ever actually destroy an Arm_reloc_property_table?
>>
>
> No. We can remove it.
>
>> This is a cute idea. Can you think of a way to make it a bit more
>> general so that it is easier for other targets to use it?
>
> We can have a general way for all target but this is done in way so
> that a part of arm-reloc.def is almost identical to a relocation code
> table in the ARM ELF file format document. That is intentional, I
> want it to be very easy to verify manually that the information in
> arm-reloc.def is correct. Maybe we can use S-expression as the
> common description language but there will still be quite a bit of
> target-specific code in the analysis. I'm open to suggestions.
>
>> You need to arrange to add arm-reloc-property.$(OBJEXT) to targetobjs
>> in gold/configure.ac when using --enable-target=arm. Look at how we
>> set ${targ_obj}.\$(OBJEXT), where targ_obj is set in configure.tgt.
>
> ok. Will send an updated patch.
>
> The reason I want to do this is to make some parts of the ARM backend
> more data driven. I remove code from arm.cc by adding more code
> elsewhere :)
>
> -Doug
>
Attachment:
patch-reloc-property.txt
Description: Text document
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |