Miscompiled crtbegin in large model?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Miscompiled crtbegin in large model?

Lorenzo Marcantonio
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

Peter Bigot-4
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 <
[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

Lorenzo Marcantonio
On Sat, Dec 28, 2013 at 05:19:38AM -0600, Peter Bigot wrote:
> 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.

TI is still at 4.8 so large model simply isn't there :D Probably -mlarge
is not enough 'mature' for doing work... LTO does even crazier
things (even in small) like junking interrupt handlers unless you put them as extern
in the linker script... after all they are not called, so they are
"obviously" dead code :D

And the interrupt attributes warns for vectors after 31 (only a spurious
warning, the code works)

Anyway I opened a bug on the gcc report system; I even devised a two
liner which reproduces the issue, so at least they can look at it
easily.

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

nick clifton
Hi Lorenzo,
> Anyway I opened a bug on the gcc report system; I even devised a two
> liner which reproduces the issue, so at least they can look at it
> easily.

For which I thank you very much... :-)

I have a patch which fixes the problem - at least for the test case you
supplied.  I am running it through some local regressions tests before
submitting it to the FSF, but if you fancy having a go yourself, here it is:

Index: stor-layout.c
===================================================================
--- stor-layout.c       (revision 206241)
+++ stor-layout.c       (working copy)
@@ -2816,7 +2816,8 @@
                  enum machine_mode target_mode,
                  rtx *mmin, rtx *mmax)
  {
-  unsigned size = GET_MODE_BITSIZE (mode);
+  /* PR 59613: Use the precision of the mode, not its bitsize.  */
+  unsigned size = GET_MODE_PRECISION (mode);
    unsigned HOST_WIDE_INT min_val, max_val;

    gcc_assert (size <= HOST_BITS_PER_WIDE_INT);

In my defense I should point out that this is a bug in generic gcc code
and not the MSP430 backend.  Of course I also should have picked up this
problem a long time ago rather than letting it get out into the wilds.
Ho Hum.

Cheers
   Nick Clifton

PS.
   For anyone following this thread who wants to see the GCC bug report,
it can be found here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

Peter Bigot-4
This looks an awful lot like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 (at least from the
familiar diff).

Peter


On Mon, Dec 30, 2013 at 7:07 AM, nick clifton <[hidden email]> wrote:

> Hi Lorenzo,
> > Anyway I opened a bug on the gcc report system; I even devised a two
> > liner which reproduces the issue, so at least they can look at it
> > easily.
>
> For which I thank you very much... :-)
>
> I have a patch which fixes the problem - at least for the test case you
> supplied.  I am running it through some local regressions tests before
> submitting it to the FSF, but if you fancy having a go yourself, here it
> is:
>
> Index: stor-layout.c
> ===================================================================
> --- stor-layout.c       (revision 206241)
> +++ stor-layout.c       (working copy)
> @@ -2816,7 +2816,8 @@
>                   enum machine_mode target_mode,
>                   rtx *mmin, rtx *mmax)
>   {
> -  unsigned size = GET_MODE_BITSIZE (mode);
> +  /* PR 59613: Use the precision of the mode, not its bitsize.  */
> +  unsigned size = GET_MODE_PRECISION (mode);
>     unsigned HOST_WIDE_INT min_val, max_val;
>
>     gcc_assert (size <= HOST_BITS_PER_WIDE_INT);
>
> In my defense I should point out that this is a bug in generic gcc code
> and not the MSP430 backend.  Of course I also should have picked up this
> problem a long time ago rather than letting it get out into the wilds.
> Ho Hum.
>
> Cheers
>    Nick Clifton
>
> PS.
>    For anyone following this thread who wants to see the GCC bug report,
> it can be found here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

nick clifton
Hi Peter,

> This looks an awful lot like
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 (at least from the
> familiar diff).

Yes - I agree with you - it is the same bug.

Cheers
   Nick

PS. I wish that I had known about this PR before I started investigating
59613 - I could have saved myself a whole morning.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

nick clifton
In reply to this post by Lorenzo Marcantonio
Hi Lorenzo,

   I have now checked in the patch to the FSF mainline.

   Peter pointed out that he had already submitted the patch in a
different PR, but it had been ignored. :-(  This time we were lucky.

Cheers
   Nick


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Miscompiled crtbegin in large model?

Lorenzo Marcantonio
On Mon, Dec 30, 2013 at 05:39:20PM +0000, nick clifton wrote:
>   Peter pointed out that he had already submitted the patch in a different
> PR, but it had been ignored. :-(  This time we were lucky.

Beta stages are for this, after all:D

I searched the bug db before submitting but I would *never* tought that
the other one was related...

By the way, the LTO issues were actually a bug in the sample programs (a
variable touched in an ISR which was not volatile... the textbook
example). Also adding __attribute__((used)) to the ISR correctly force
inclusion without having to modify the linker script, if someone is
interested.

On another topic, I think that both CCS and IAR compilers are doing LTO
(or at least selective linking) aggressively by default, since otherwise
memory would be filled with unused code --- Texas 'libraries' are simply
C files containing lots of related function (instead of the typical
one-function-for-o used in libc); for example the HAL_UCS.c with
a conventional link pulls in control primitive for *all* the oscillators
(even if you only use the FLL...).

At least the MSPware libs are of good quality, even if it seems they are
using particular C constructs to 'steer' their compiler into good code
(maybe is an impression of mine); comments are strangely helpful:P


I think this should be noticed in the mspgcc docs, to avoid surprises to
migrating users.

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users