Re: [openrisc] Urgent: bug in newest gcc...

[Simon Srot <simons@opencores.org>]

Chris Ziomkowski wrote:
> 
> gdb is failing with the version of gcc I checked out from
> cvs on Monday. I have tracked this down to the following
> problem. The code below is generated by running this version
> of gcc on the file dhry.c in or1ksim/testbench/dhrystone with
> the options:
> 
> or32-rtems-gcc -mhard-div -S -DOR1K dhry.c
> 
> I have left out the unimportant sections. The issue is with the
> frame register, r2, and it can be found immediately. The program
> starts up by calling main:
> -------------------------------------
> proc _main
>         .global _main
> _main:
> 
>         # 00111110011100000000000000000000
>         # gpr_save_area 4 vars 192 current_function_outgoing_args_size 0
>         l.addi          r1,r1,-204
>         l.addi          r2,r1,204
>         l.sw            4(r1),r2
>         l.sw            0(r1),r9
>         l.sw            8(r1),r10
>         l.jal           ___main
>         l.nop                   # nop delay slot
>         l.movhi         r3,hi(_Next_Ptr_Glob)    # move immediate (high)
>         l.ori   r3,r3,lo(_Next_Ptr_Glob)         # move immediate (low)
> 
> Space is allocated on the stack for 204 bytes, the stack
> pointer r1 is moved down, and the frame pointer r2 is set to
> the original stack position. The current frame, the current
> link register, and r10 are saved.
> 
> 1) Question: What is r10? Why is it being saved? It has yet
> to be used by anything. The documentation doesn't list it as
> anything special, and the ___main function doesn't use it...
> This is secondary to my immediate concern, however.

r10 is callee-saved register and have to be saved, because it is used in
_main
function.

> 
> We now jump to ___main which is defined as follows:
> --------------------------------------
> proc ___main
>         .global ___main
> ___main:
> 
>         # 00100000000000000000000000000000
>         # gpr_save_area 0 vars 0 current_function_outgoing_args_size 0
>         l.addi          r1,r1,-4
>         l.addi          r2,r1,4
>         l.sw            0(r1),r2
> L8:
>         l.lwz           r2,0(r1)
>         l.jalr          r9
>         l.addi          r1,r1,4
> endproc ___main
> 
> The prologue code for this function does the same thing. It adds
> space for 4 bytes (to store the previous frame), and then resets
> the frame register to the current stack location.
> 
> Since this function does nothing, it immediately exits. But the
> frame register (r1) is not reset to the original value! Instead,
> it is reset to the current value which was stored!
> 
> My guess is that the two instructions:
> 
>         l.addi          FRAME,STACK,#Bytes
>         l.sw            0(STACK),FRAME
> 
> in the prologue have been misordered, and what was meant was:
> 
>         l.sw            0(STACK),FRAME
>         l.addi          FRAME,STACK,#Bytes
> 

Correct, this is definitely a bug. I've put a new version on CVS.

> However, I can not find the location in the gcc source
> code where this occurs.
> 
> 2) Can someone point me to the location in gcc where this
> is being done so that I can fix the problem?

All the things regarding the gcc for or32 are in directory
or1k/gcc/gcc/config/or32/.
This bug was in function_prologue in or32.c. So this is the only file
that you have to update.

> 
> gdb is ignoring breakpoints because the frame register
> doesn't match after a function call. This used to work
> on the gcc version a few weeks ago, and I can't do anything
> until this is fixed.
> 
> Thanks,
> 
> Chris
> chris@asics.ws
> 
> _______________________________________________________
> www.asics.ws - Solutions for your ASIC needs

Regards,
        Simon
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml