Re: Miscompiled crtbegin in large model?

Peter Bigot <[email protected]>
Newsgroups gmane.comp.hardware.texas-instruments.msp430.gcc.user
Message-ID <CAPOJ94PDkXvtu9W7fRZCcBZpo9Oi+XVHW-hY6LGCrCfQNGC2aA@mail.gmail.com>
Unlike your previous question, this is purely an msp430-elf-gcc issue so
isn't something I would normally respond to.  Both TI and RH have people
monitoring this list, and I expect them to reply on-list with advice,
though perhaps not until the holidays are over.

Since I'm here, though, I expect that issues with a pure upstream build
should be raised on the official gcc or binutils mailing lists.  I
recommend first trying it with the pre-built toolchains available from TI,
as there may be changes that have not yet been integrated upstream.

Peter


On Fri, Dec 27, 2013 at 8:05 AM, Lorenzo Marcantonio <
[email protected]> wrote:

> 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
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
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

_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.