This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD][PATCH] Set SHF_LINK_ORDER flags of ARM EXIDX sections.
The input EXIDX sections are sorted by the ARM backend whether
SHF_LINK_ORDER flag is set or not. In the output, gold sets the
sh_link field of section headers of EXIDX sections correctly to their
respective text section but the SHF_LINK_ORDER flag is dropped for
some reason. The output is then passed to strip, which becomes
confused because of lack of SHF_LINK_ORDER flag and clears all the
sh_link field of EXIDX section headers.
Yes, the problem happens during linking of a relocatable kernel loadable module.
-Doug
在 2010年10月20日上午12:33，Cary Coutant <ccoutant@google.com> 寫道：
>> Gold does not handle SHF_LINK_ORDER flag in general, we drop the flag
>> when searching for an output section.
>
> The code you quoted is only dropping it for the purposes of looking
> for an already-existing matching output section, which is the right
> thing to do. As far as I can tell, if the first input section has
> SHF_LINK_ORDER set, then the output section should also have it set.
>
> All that said, the LINK_ORDER flag has no meaning at all for anything
> but ET_REL files. It's a signal to the linker that the input sections
> must be sorted in the same relative order as the corresponding
> sections indicated by the sh_link field. Any tool that's getting
> confused if LINK_ORDER isn't set in an ET_EXEC or ET_DYN file is doing
> something wrong -- probably just overzealously insisting on seeing a
> flag simply because it was there in their first sample output. If the
> tool is trying to verify that that section is actually sorted
> correctly, looking for the flag isn't a guarantee of that -- gold
> doesn't actually implement the ordering implied by the flag (but it
> also doesn't do any reordering that would require it to do so). It
> would be better for the tool to check the actual ordering of the
> section for consistency with the ordering of the corresponding
> section.
>
> Is the problem you've encountered with -r links?
>
> -cary
>