[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

["baker at usgs dot gov" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #11 from Larry Baker <baker at usgs dot gov> 2012-08-12 21:24:31 UTC ---
Andreas,

I have patched the Code Sourcery gcc 4.6.1+ ColdFire cross-compiler to fix the
bugs I found for "-m68020 -fPIC -fstack-limit-symbol" and to implement
-fstack-limit-symbol for non-68020 processors.

The correct code is now generated for -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start.  The PIC offset table register, A5, is now
loaded before it is referenced by the stack check code:

Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
 junk
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> <visibility> <early_local_cleanups> <whole-program>
<inline>Assembling functions:
 junk
Execution times (seconds)
 tree gimplify         :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (25%) wall   
   0 kB ( 0%) ggc
 unaccounted todo      :   0.00 ( 0%) usr   0.01 (100%) sys   0.01 (25%) wall  
    0 kB ( 0%) ggc
 TOTAL                 :   0.00             0.01             0.04              
1090 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s
#NO_APP
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @function
junk:
    link.w %fp,#0
    lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
    move.l __stack_start@GOT(%a5),%d0
    addq.l #4,%d0
    cmp.l %sp,%d0
    traphi
    unlk %fp
    rts
    .size    junk, .-junk
    .ident    "GCC: (GNU) 4.6.1"
    .section    .note.GNU-stack,"",@progbits

This required patches to m68k.c and m68k.md.  I also moved the calculation of
current_function_static_stack_size and limit to account for the stack size
increase on ColdFire processors (use fsize_with_regs in place of
current_frame.size).

RTL is now defined to generate code for -fstack-limit-symbol for non-68020
processors:

Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=5208 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
 junk
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> <visibility> <early_local_cleanups> <whole-program>
<inline>Assembling functions:
 junk
Execution times (seconds)
 unaccounted todo      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (100%) wall  
    0 kB ( 0%) ggc
 TOTAL                 :   0.00             0.00             0.01              
1089 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s#NO_APP
    .file    "junk.c"
    .text
    .align    2
    .globl    junk
    .type    junk, @function
junk:
    link.w %fp,#0
    move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %a5
    lea (-6, %pc, %a5), %a5
    move.l __stack_start@GOT(%a5),%d0
    addq.l #4,%d0
    cmp.l %sp,%d0
    bls .+2
    trap #7
    unlk %fp
    rts
    .size    junk, .-junk
    .ident    "GCC: (GNU) 4.6.1"
    .section    .note.GNU-stack,"",@progbits

This required patches to m68k.md.  I implemented the "*conditional_trap"
pattern for non-68020 processors and renamed "*conditional_trap" to
"*conditional_trap_68020" for 68020 processors.

Compilation, linking, and conversion to uClinux Flat Binary format now works
for ColdFire processors (but does not for 32-bit 68020, which is okay):

Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: 2 bad relocs
collect2: ld returned 1 exit status

Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=5206 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c

Please review my patches, m68k.{c,md}.trunk.patch.  (I have to figure out how
to attach them.)  I do not understand, for example, how the "TARGET_68020" in
define_expand "ctrapsi4" works.  It seems not to be a problem to get to the
patterns for generating the correct conditional trap code for non-68020
processors.  (Does that mean they are not necessary?)  I have not tested real
code yet using the patched Code Sourcery gcc 4.6.1+ ColdFire cross-compiler.  I
am on vacation at the moment.  I will get back to that next week.

Larry Baker