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] Attributes section part 3.


This has been committed.  I put the enums in elfcpp/arm.h but did not
enclose them with a nested arm namespace to make things simpler.  Most
of them have an AEABI prefix and other have ARM specific names.  There
are still a few generic sounding enums like Tag_CPU_name which may
conflict with private tags used by another target in the future
though.  The loops we had talked about was extracted into a single
helper and the searching was changed to search for section type
SHT_ARM_ATTRIBUTES in the section headers from back to front.

-Doug

2009-12-10  Doug Kwan  <dougkwan@google.com>

elfcpp/ChangeLog
        * arm.h: New enums for EABI object attribute tags and values.

gold/ChangeLog
        * arm.cc (attributes.h): New include.
        (Arm_relobj::Arm_relobj): Initialize attributes_section_data_.
        (Arm_relobj::~Arm_relobj): Delete object pointed by
        attributes_section_data_.
        (Arm_relobj::attributes_section_data): New method definition.
        (Arm_relobj::attributes_section_data_): New data member declaration.
        (Arm_dynobj::Arm_dynobj): Initialize attributes_section_data_.
        (Arm_dynobj::~Arm_dynobj): Delete object pointed by
        attributes_section_data_.
        (Arm_dynobj::attributes_section_data): New method definition.
        (Arm_dynobj::attributes_section_data_): New data member declaration.
        (Target_arm::Target_arm): Initialize attributes_section_data_.  Change
        initialization value of may_use_blx_ to false.
        (Target_arm::using_thumb2, Target_arm::using_thumb_only,
        Target_arm::may_use_arm_nop, Target_arm::may_use_thumb2_nop): Use
        object attributes to compute results instead of hard-coding.
        (Target_arm::do_attribute_arg_type, Target_arm::do_attributes_order,
        Target_arm::get_secondary_compatible_arch,
        Target_arm::set_secondary_compatible_arch
        Target_arm::tag_cpu_arch_combine, Target_arm::aeabi_enum_name,
        Target_arm::tag_cpu_name_value, Target_arm::merge_object_attributes):
        New method declarations.
        (Target_arm::get_aeabi_object_attribute): New method definition.
        (Target_arm::attributes_section_data_): New data member declaration.
        (read_arm_attributes_section): New template definition.
        (Arm_relobj::do_read_symbols): Read attributes section if it exists.
        (Arm_dynobj::do_read_symbols): Ditto.
        (Target_arm::do_finalize_sections): Merge attributes sections from
        input.  Check for BLX use after attributes section merging.
        Fix __exidx_start and __exidx_end visibility.  Create an
        .ARM.attributes section if necessary.
        (Target_arm::get_secondary_compatible_arch,
        Target_arm::set_secondary_compatible_arch,
        Target_arm::tag_cpu_arch_combine, Target_arm::aeabi_enum_name,
        Target_arm::tag_cpu_name_value, Target_arm::merge_object_attributes,
        Target_arm::do_attribute_arg_type, Target_arm::do_attributes_order):
        New method definitions.


2009/12/9 Ian Lance Taylor <iant@google.com>:
> "Doug Kwan (Ãö®¶¼w)" <dougkwan@google.com> writes:
>
>> 2009/12/9 Ian Lance Taylor <iant@google.com>:
>>
>>> First, I wonder if these values should all be in elfcpp/arm.h.  I'm OK
>>> with it either way, but please consider moving them.
>>
>> If they are in elfcpp, they need to be protected by a nested namespace
>> like elfcpp::Arm because other targets my used conflict tags.
>
> That's OK with me if it's OK with you.  They would be in elfcpp/arm.h,
> presumably, in any case.
>
>
>>> This kind of loop can be expensive in a big C++ object.a  Do most
>>> objects have an attributes section?  If not, it may be worth doing a
>>> memmem, like the use just before find_eh_frame in
>>> Sized_relobj::do_read_symbols.
>>
>> I think we can assume all ARM objects we care have attributes
>> sections.  The AAELF document does not say anything about the position
>> of the section in the section headers.  gas seems to put them near the
>> end in the section headers so we may want to search from the end.
>> The document does specify the section type to be ARM_ATTRIBUTE and
>> name ".ARM.attributes".  Would it be more desirable if we just check
>> the section type instead of using memmem?
>
> Yes, if checking the section type is reliable, please check that
> rather than the section name.  And if gas tends to put the section
> near the end of the list, search from back to front.
>
>
>> Other suggestions were made also.  I will send out a new patch after
>> rewriting the loop.
>
> Send the new patch and go ahead and commit.
>
> Thanks.
>
> Ian
>

Attachment: patch-attr-3.txt
Description: Text document


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