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.


"Doug Kwan (éæå)" <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


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