Re: ARM: Fix generation of older veneers

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Mar 24, 2009 at 04:28:58PM +0100, Christophe LYON wrote:
> Hi Daniel,
>
>> This caused changes to the order of veneers (I do not really
>> understand why, but I've had this problem before).  It also
>
> stub offset are computed via bfd_hash_traverse, so I guess the hash_table 
> is filled differently after your patch, leading to a different order of 
> veneers. But why only such a small subset of the tests are impacted, I 
> don't know.

Oh, there's a hash table traverse in there - that would explain it
indeed.  Maybe there's some way we can stabilize the traversal order?
While I'm on the subject, this is true of all hash table traversals in
BFD.  Should we allow traversing a symbol hash table (at least, an ELF
hash table) in some sorted order - and would it be infinitely painful
to get right?

>> Any comments on this patch?
>>
>
> For the change in arm_allocate_glue_section_space, maybe I would have  
> move the BFD_ASSERT calls upper, so as to avoid checks against NULL in  
> the case size==0; I think it would be easier to read, but it's probably a 
> matter of taste.
>
> It looks OK for me.

Thanks for looking at it.  Those checks are actually necessary in our
local binutils tree, because we do not allocate erratum sections if
the erratum is disabled - no point cluttering up the map.

I have a followup patch to this that we're just testing today, since
it causes some interworking warnings as written.

-- 
Daniel Jacobowitz
CodeSourcery