GCC Bugzilla Bug 36047

bigeasy@ayoka:~/cc$ echo 'int main(void) { return 0; }' > file.c
bigeasy@ayoka:~/cc$ m68k-linux-gnu-gcc -o file file.c -static -pg
/tmp/ccw33VYP.o: In function `main':
file.c:(.text+0x6): relocation truncated to fit: R_68K_PC16 against `.data'
collect2: ld returned 1 exit status

It works fine with a small binary (without -static).
I don't really know what the label is used for. I patched my gcc with:
|--- a/gcc/config/m68k/linux.h
|+++ b/gcc/config/m68k/linux.h
|@@ -143,7 +143,6 @@ along with GCC; see the file COPYING3.
| #undef FUNCTION_PROFILER
| #define FUNCTION_PROFILER(FILE, LABELNO) \
| {                                                                 \
|-  asm_fprintf (FILE, "\tlea (%LLP%d,%Rpc),%Ra1\n", (LABELNO));            \
|   if (flag_pic)                                                           \
|     fprintf (FILE, "\tbsr.l _mcount@PLTPC\n");                            \
|   else                                                                    \
|--- a/gcc/config/m68k/m68k.h
|+++ b/gcc/config/m68k/m68k.h
|@@ -576,7 +576,7 @@ extern enum reg_class regno_reg_class[];
| #define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) 0
|
| #define FUNCTION_PROFILER(FILE, LABELNO)  \
|-  asm_fprintf (FILE, "\tlea %LLP%d,%Ra0\n\tjsr mcount\n", (LABELNO))
|+  asm_fprintf (FILE, "\tjsr mcount\n", (LABELNO))
|
| #define EXIT_IGNORE_STACK 1
|

I'm not using glibc's mcount function but my own in which I unwind the stack in
order to obtain caller's address (that's the purpose of the label I guess).

I checked gcc-core-4.3.0.tar.bz2 and the two lea lines are unchanged so the bug
should be still there. 

Now how do we fix this? Removing the label or allowing larger distances?

Does anybody care about this bug?

Would you please attach a preprocessed testcase so one can reproduce the
problem.

Wasn't 

# echo 'int main(void) { return 0; }' > file.c

not enough or did you overlook that part? 

The -E output is pretty much the same, it is:

$ cat test.i 
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.c"
int main(void)
{
 return 0;
}


---
The -S output (I guess you meant that) would be:

$ m68k-linux-gnu-gcc -o test.S test.c -static -pg -S && cat test.S 
#NO_APP
        .file   "test.c"
        .text
        .align  2
        .globl  main
        .type   main, @function
main:
        link.w %fp,#0
        .data
        .align  2
.LP2:
        .long   0
        .text
        lea (.LP2,%pc),%a1
        jbsr _mcount
        clr.l %d0
        unlk %fp
        rts
        .size   main, .-main
        .ident  "GCC: (Sourcery G++ Lite 4.3-43) 4.3.2"
        .section        .note.GNU-stack,"",@progbits
---- 

And my rec for the fix was to get rid of the lea before the branch to the
_mcount call. However someone might need it, I'm not sure.

It appears that 'lea' serves some compatibility purpose.  The code is there
since 1995.

Recent GLIBC defines _mcount as
void
_mcount (void)
{
  mcount_internal ((u_long)
                   __builtin_extract_return_addr (__builtin_return_address
                                                  (1)),
                   (u_long)
                   __builtin_extract_return_addr (__builtin_return_address
                                                  (0)));
}
so the value of %a1 is unused.  Newlib and uClibc don't define _mcount for m68k
at all.

Andreas, I suggest simply removing the 'lea'; they seem to be no users for it.

Alternatively, for the !PIC case we may use 'lea <label>, %a1' (no pc-relative
relocation) and for the PIC case use a longer sequence, something like: 'move.l
#<label>@PC32, %a1\n add.l (-4, %pc), %a1'.

gcc@breakpoint.cc,

Would you please submit your patch to gcc-patches@gcc.gnu.org.  Only the
linux.h version of FUNCTION_PROFILER causes problems, you can leave the m68k.h
version as is.

Thanks.