Miscompiled crtbegin in large model?

Got the 'blinking led' working on the 5529... tried to test the thing 
with the large model (-mlarge to every msp430-elf-gcc invocation).

Well, nothing happened. It hangs before main. Exactly in frame_dummy, from
crtbegin.o (built from the mess in libgcc/crtstuff.c). I dumped the files from
the compiler build (found in lib/gcc/msp430-elf/4.9.0/430x/large) so it
shouldn't be something from my test program...

The source code has this fragment:

  if (__register_frame_info)
    __register_frame_info (__EH_FRAME_BEGIN__, &object);

In small model the object code is like this:

0000009e <frame_dummy>:
  9e:   3e 40 00 00     mov     #0,     r14     ;
                        a0: R_MSP430_16_BYTE    __register_frame_info
  a2:   0e 93           cmp     #0,     r14     ;r3 As==00
  a4:   00 24           jz      $+2             ;abs 0xa6
                        a4: R_MSP430_10_PCREL   .L32
  a6:   3c 40 00 00     mov     #0,     r12     ;
                        a8: R_MSP430_16_BYTE    .eh_frame
  aa:   3d 40 00 00     mov     #0,     r13     ;
                        ac: R_MSP430_16_BYTE    .bss+0x4
  ae:   8e 12           call    r14             ;

000000b0 <.L32>:

__register_frame_info is a weak external, which is undefined, so the linker
'locates' it to 0. The result is

00004524 <frame_dummy>:
    4524:       3e 40 00 00     mov     #0,     r14     ; <<< HERE IS LOCATED
    4528:       0e 93           cmp     #0,     r14     ;r3 As==00
    452a:       05 24           jz      $+12            ;abs 0x4536
    452c:       3c 40 04 44     mov     #17412, r12     ;#0x4404
    4530:       3d 40 82 24     mov     #9346,  r13     ;#0x2482
    4534:       8e 12           call    r14             ;

00004536 <.L32>:

Here zero is obviously zero, so the call is skipped (as intended:D)

When linking the large model crtbegin.o, the generated code is really different:

0000015e <frame_dummy>:
 15e:   8c 00 00 00     mova    #0,     r12     ;
                        15e: R_MSP430X_ABS20_ADR_SRC    .eh_frame
 162:   8d 00 00 00     mova    #0,     r13     ;
                        162: R_MSP430X_ABS20_ADR_SRC    .bss+0x6
 166:   b0 13 00 00     calla   #0              ;0x00000
                        166: R_MSP430X_ABS20_ADR_DST    __register_frame_info

Where is the condition check? Obviously after location the result is this:

000045fe <frame_dummy>:                                                                     
    45fe:       8c 00 08 44     mova    #17416, r12     ;0x04408
    4602:       8d 00 f2 24     mova    #9458,  r13     ;0x024f2
    4606:       b0 13 00 00     calla   #0              ;0x00000 << HERE IS LOCATED

That calla #0 doesn't seem very legal to me...

So... is this expected, it's a known bug or needs to be reported? (and where) I
know that 20-bit support is beta (I built it from trunk...) so I'm not worrying
too much.

Suggestions appreciated

-- 
Lorenzo Marcantonio
Logos Srl

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk