Re: Long call support broke Thumb veneers

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jun 03, 2008 at 07:06:53PM +0200, Christophe LYON wrote:
>> Christophe, you removed handling of two relocation types from
>> bfd_elf32_arm_process_before_allocation, which is responsible for
>> inserting these stubs.  How do you intend they be handled?
>> record_arm_to_thumb_glue is now never called for them.
>>
>> In general, handling long call stubs differently from mode-changing
>> stubs seems like asking for trouble.
>>
>
> Well,
> While taking into account Paul's remarks, it seemed clearer to me to  
> handle mode-switching stubs in the same place as long calls (ie a call  
> which involves mode-switching is handled by the stubs I added, whatever  
> the distance).

What about the non-call (or pre-EABI, which may be call or not)
branch relocations?

            case R_ARM_PC24:
            case R_ARM_PLT32:
            case R_ARM_JUMP24:
            case R_ARM_THM_JUMP24:

I don't think it's a good idea to have two completely different code
paths which produce similar stubs.  And if you handle R_ARM_CALL but
not R_ARM_JUMP24, then you'll insert islands for normal calls but not
for sibling calls, which is unfortunate.

Minor formatting comments on your patch: in function definitions the
function name starts a new line, and there is almost always a space
before a left parenthesis (but not if the preceeding character is a
left parenthesis also).

> I checked with the code fragment you mentioned (using Code Sourcery  
> 2008q1-126 release), it seems OK to me but I am worrying about your  
> generic-hosted.ld linker script: indeed, the long call stubs are  
> generated before __cs3_interrupt_vector, and I suspect this is problem,  
> isn't it?

Yes, that's a problem.  Why are they placed there?  The manual says
that orphans are placed after output sections with the right flags,
not before them.

I guess you're not placing these sections as orphans since they need
to occur in potentially multiple places.  So, how are you placing
them, and 

Looks like you've put them before the section that requires them.
After would avoid this problem.  Would it cause other problems?
Should we document in the manual where to expect them - and is there a
way to avoid getting them in the middle of tables?

Here's the start of that linker script, as context for other readers.

  .text :
  {
    CREATE_OBJECT_SYMBOLS
    __cs3_region_start_ram = .;
    *(.cs3.region-head.ram)
    ASSERT (. == __cs3_region_start_ram, ".cs3.region-head.ram not permitted");
    __cs3_interrupt_vector = __cs3_interrupt_vector_arm;
    *(.cs3.interrupt_vector)
    /* Make sure we pulled in an interrupt vector.  */
    ASSERT (. != __cs3_interrupt_vector_arm, "No interrupt vector");

    _start = __cs3_reset_generic;
    __cs3_reset = __cs3_reset_generic;
    *(.cs3.reset)
    /* Make sure we pulled in some reset code.  */
    ASSERT (. != __cs3_reset, "No reset code");

    *(.text .text.* .gnu.linkonce.t.*)
    *(.plt)
    *(.gnu.warning)
    *(.glue_7t) *(.glue_7) *(.vfp11_veneer)

-- 
Daniel Jacobowitz
CodeSourcery