Re: ARM: Fix generation of older veneers

[Ramana Radhakrishnan <ramana dot r at gmail dot com>]

On Tue, Mar 24, 2009 at 4:41 PM, Daniel Jacobowitz <drow@false.org> wrote:
> 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.


Any updates on this patch ? I hit this bug while running the GCC
testsuite (with my local tree having
some other work that I was doing) . The patch seems to fix the issues
I was having with the veneers being zero'd out
but I wanted to check back if you had any other issues with this particular one.

cheers
Ramana


> --
> Daniel Jacobowitz
> CodeSourcery
>