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: [PATCH][GOLD] Add ARM relocation property table.


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]